Talk on what a systems programming language needs to replace C

[Paulo Pinto]

On Monday, 26 August 2019 at 10:37:29 UTC, Russel Winder wrote:
> 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.

Apparently ARM, Google, Apple and Microsoft think otherwise, 
given that:

- Android's GPGPU debugger is mostly written in Go

- The hypervisor used on ChromeOS and Google Cloud Computer, 
gVisor, is written in Go

- Fuchsia TCP/IP stack and volume management tooling is written 
in Go

- ChromeOS sandboxing is written in Rust

- Android since Treble uses Java and C++ for drivers, the 
classical Linux drivers are deemed legacy

- Apple's kernel and future driver stack is written in a mix of 
C++ and Swift

- Windows uses a mix of C++ and .NET, since Windows 8 kernel code 
has been being migrated to C++, with COM (UWP) increasing its 
focus as userspace API

- Fuchsia is written in a mix of C++, Dart and Rust, with the L4 
C bits being migrated to C++

- ARM mbed is written in C++

One thing that everyone seems to be missing from this talk, lost 
in the usual D vs Rust argumentations, is that the speaker has a 
responsability position at Intel, and it also relates to Intel's 
adoption of Rust.