https://youtu.be/l9hM0h6IQDo

On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar wrote:
> https://youtu.be/l9hM0h6IQDo

What he doesn't mention is that compared to other languages many of the algorithms and programming models will not work in Rust and you have rethink them often making them more complicated and slower. Therefore I think Rust is a bad fit for "system programming".

The entire talk is about evangelizing Rust contrary to what he says. He also says he constantly have to add more stuff into the language in order to make work better as a systems programming language which kind of contradicts the idea that Rust is suitable for system programming.

There are other languages that can do anything C can without any changes to the language.

On Monday, 26 August 2019 at 06:51:33 UTC, IGotD- wrote:
> On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar wrote:
>> https://youtu.be/l9hM0h6IQDo
>
>
> The entire talk is about evangelizing Rust contrary to what he says. He also says he constantly have to add more stuff into the language in order to make work better as a systems programming language which kind of contradicts the idea that Rust is suitable for system programming.
>

I ignored the evangelizing bits.

What I took from the talk is that there are two things:

a) The compelling feature is the Rust automatic memory management /memory safety without GC and runtime - that can motivate systems programmers to move from C.

b) Parity with C - this is where Rust lacks and needs enhancements.

Comparing with D, perhaps D excels at b) but lacks a compelling memory management solution that would motivate systems programmers.

Regards

26.08.2019 12:30, Dibyendu Majumdar пишет:
> 
> I ignored the evangelizing bits.
> 
> What I took from the talk is that there are two things:
> 
> a) The compelling feature is the Rust automatic memory management /memory safety without GC and runtime - that can motivate systems programmers to move from C.
Many people don't agree to you because very often low-level Rust code uses unsafe block very much. This definitely isn't as good as you say.

> 
> b) Parity with C - this is where Rust lacks and needs enhancements.
> 
> Comparing with D, perhaps D excels at b) but lacks a compelling memory management solution that would motivate systems programmers.
> 
> Regards
> 

On Monday, 26 August 2019 at 10:23:38 UTC, drug wrote:

>> a) The compelling feature is the Rust automatic memory management /memory safety without GC and runtime - that can motivate systems programmers to move from C.

> Many people don't agree to you because very often low-level Rust code uses unsafe block very much. This definitely isn't as good as you say.
>

Hi, just for clarity I am not saying this: I just summarised the main points in the talk.

Regards

On Mon, 2019-08-26 at 06:51 +0000, IGotD- via Digitalmars-d wrote:
> On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar wrote:
> > https://youtu.be/l9hM0h6IQDo
> 
> What he doesn't mention is that compared to other languages many of the algorithms and programming models will not work in Rust and you have rethink them often making them more complicated and slower. Therefore I think Rust is a bad fit for "system programming".

Given that the person's goal is to make Rust a superset of C, I do not see how you make the above inference. What algorithms and programming models are possible in C that are not possible in Rust?

I suspect if there are N programmers in the world, there are 3N+10 definitions of "systems programming". Go developers have changed their mind on the definition a few times over the years.

> The entire talk is about evangelizing Rust contrary to what he says. He also says he constantly have to add more stuff into the language in order to make work better as a systems programming language which kind of contradicts the idea that Rust is suitable for system programming.

I disagree. He clearly states he isn't evangelising Rust but hopes that people feel evangelised for Rust due to the talk, which is weird. The entire talk is about transforming Rust to be a superset of C.

> There are other languages that can do anything C can without any changes to the language.

And Rust is already one of those.

Given there is C and people feel it is time to move on to a better language, and we have D, C++, Rust, and Go as the obvious candidates, there is a problem none of these are actually candidates for the job of replacing C. Even Go, which is supposed explicitly to be C for the 2010s.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Mon, 2019-08-26 at 09:30 +0000, Dibyendu Majumdar via Digitalmars-d wrote: […]
> a) The compelling feature is the Rust automatic memory management /memory safety without GC and runtime - that can motivate systems programmers to move from C.

It would be nice if this were the case, but Rust is two systems, the safe and unsafe systems, and you have to build a lot of infrastructure to use safe code over unsafe code.

> b) Parity with C - this is where Rust lacks and needs enhancements.

But why is the purpose to make Rust a superset of C. Why can't we challenge that C is the ideal language for "systems programming" except that it has problems such as buffer overflow. OK so C is a portable assembly language focussed on PDP-8 and PDP-11 hacked to work on VAX-11, but why can't we start afresh? So Rust and Go are trying to do that, but are they failing in the goal. Go I'd say yes since it has become a Web programming language, and that is not "systems programming" nor the only thinkg that C needed replacing for. Rust has a problem because of the unsafe mode needed for systems level work.

> Comparing with D, perhaps D excels at b) but lacks a compelling memory management solution that would motivate systems programmers.

As I understand it, D, like, Go, requires a runtime system over and above the C runtime system.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Mon, 2019-08-26 at 13:23 +0300, drug via Digitalmars-d wrote:
> […]
> Many people don't agree to you because very often low-level Rust code
> uses unsafe block very much. This definitely isn't as good as you say.
> 
[…]

The safe/unsafe modes are the failing of Rust, even though it is necessary. In order to do safe "systems programming", there has to be a very well designed and test unsafe layer.

This is also true of applications programming using C linkage libraries, but in most cases the needed unsafe wrappers can be generated automatically and they work very well.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 26 August 2019 at 10:44:59 UTC, Russel Winder wrote:

> But why is the purpose to make Rust a superset of C. Why can't we challenge that C is the ideal language for "systems programming" except that it has problems such as buffer overflow. OK so C is a portable assembly language focussed on PDP-8 and PDP-11 hacked to work on VAX-11, but why can't we start afresh?

Personally I think neither Rust nor D can replace C.
C is a high level assembler. A replacement needs to be a better high level assembler rather than a language that has many abstractions.
The particular quality of C is that you can mentally see how your code translates to machine code. Languages with lot of scaffolding destroy this property.

On Monday, 26 August 2019 at 10:37:29 UTC, Russel Winder wrote:
>
> Given that the person's goal is to make Rust a superset of C, I do not see how you make the above inference. What algorithms and programming models are possible in C that are not possible in Rust?

These are typically, intrusive lists, structures that points to each others (circular references), custom allocators. "Impossible" was a little bit the wrong word that I used. Difficult would be the word or "not worth it". Some of the algorithms can be done but those I've seen require a huge amount of boiler plate for something C would just need a few lines. Circular references is something Rust cannot deal with, unless you explicitly use pointers or RC objects. RC objects are not always welcome in systems programming and raw pointers requires you to do your own memory management so Rust loses its point. I just think the way you program Rust doesn't fit systems programming and it is not worth the extra hazzle. The amount of unsafe hatches you would open in Rust would contradict its grand "safe" selling point.

> Given there is C and people feel it is time to move on to a better language, and we have D, C++, Rust, and Go as the obvious candidates, there is a problem none of these are actually candidates for the job of replacing C. Even Go, which is supposed explicitly to be C for the 2010s.

The speaker is right about one thing and that is that a systems programming language must not have a runtime dependency, or the runtime is completely OS independent. With this definition this includes C, C++, D (-betterC only) and Rust. As far as I know Go is runtime dependent and does not qualify for this definition.