Talk on what a systems programming language needs to replace C

[Paulo Pinto]

On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
> On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via 
> Digitalmars-d wrote: […]
>> 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.
>
> But isn't that at the core of problem? C is a fairly good 
> portable assembler and so there are no controls, and no support 
> for ideas such as RAII unless the programmer implements it 
> themselves. Use C and all the things such as buffer overflow 
> are programmer problems.
>
> If systems programmers want to escape from problems of portable 
> assembly language programs such as buffer overrun, then they 
> need to eschew C and portable assemblers and create a new 
> language for systems programming. Whether Rust, Go, or 
> DasBetterC are it is highly unlikely if the language people 
> want is a superset of C.
>
> I worry that the whole project of putting all the problems of C 
> into Rust to make is a C superset ruins Rust and fails to make 
> Rust a replacement for C

Unless they are targeting PDP-11 class CPUs, like PICs, I doubt 
most C developers will understand how the auto-vectorizer and 
optimizer opportunities due to UB opportunities have decided to 
generate a specific set of Assembly code.

The portable Assembly myth of C is long gone in the age of 
multi-core, pipelined, out-of-order execution units, with NUMA, 
vector units and GPGPUs.