Talk on what a systems programming language needs to replace C

[IGotD-]

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.