August 26, 2019
On Monday, 26 August 2019 at 10:55:34 UTC, Dibyendu Majumdar 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.

C++ has already replaced C in systems programming. I experienced this shift about 10 years ago and after most of my near HW projects have been done in C++. There is nothing C++ cannot do that C can. Speed wise C++ is very close C and offers more possibilities. You have to know what you can use and what side effects some features have. Systems programming in C++ is a bit different compared if you would write an application.
August 26, 2019
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.
August 26, 2019
On Monday, 26 August 2019 at 12:31:23 UTC, Paulo Pinto wrote:

>
> 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.

The reason I highlighted this talk was because of who/which organization it came from. Josh is also a Kernel hacker if I am not mistaken.

Regarding your argument that Go is a systems language - I guess Google using it doesn't count, but Go is used for writing databases etc. But not sure you could use Go everywhere that C can be used. Go has a built-in scheduler, and GC etc.
August 26, 2019
On Monday, 26 August 2019 at 14:12:37 UTC, Dibyendu Majumdar wrote:
> On Monday, 26 August 2019 at 12:31:23 UTC, Paulo Pinto wrote:
>
>>
>> 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.
>
> The reason I highlighted this talk was because of who/which organization it came from. Josh is also a Kernel hacker if I am not mistaken.
>
> Regarding your argument that Go is a systems language - I guess Google using it doesn't count, but Go is used for writing databases etc. But not sure you could use Go everywhere that C can be used. Go has a built-in scheduler, and GC etc.

Regarding Go as systems language, here is some literature, from one of its influences


http://www.projectoberon.com


http://www.ocp.inf.ethz.ch/wiki/Documentation/Front

And related hardware,

https://pcper.com/tag/oberonstation/

And a surviving vendor,


https://www.astrobe.com

I can also cite a multitude of other languages.

In fact, D also has a built-in scheduler and GC.

As you might imagine, I belong to the crowd that would rather see a better GC (thanks very much for all improvements by the way), than betterC or trying to copy Rust, just because it is getting all the love by the FAANG.

August 26, 2019
On Monday, 26 August 2019 at 16:24:30 UTC, Paulo Pinto wrote:
>
> As you might imagine, I belong to the crowd that would rather see a better GC (thanks very much for all improvements by the way), than betterC or trying to copy Rust, just because it is getting all the love by the FAANG.

There is a lot of Rust click bait in this forum and some "look Rust can do this and that, we must have it too". I think that D should follow its own path and should not trying to ape Rust in every fashion.

A better GC is always welcome and we should really focus on that rather trying to be Rust with its memory management and other quirks.
August 26, 2019
On Mon, Aug 26, 2019 at 09:48:45PM +0000, IGotD- via Digitalmars-d wrote:
> On Monday, 26 August 2019 at 16:24:30 UTC, Paulo Pinto wrote:
> > 
> > As you might imagine, I belong to the crowd that would rather see a better GC (thanks very much for all improvements by the way), than betterC or trying to copy Rust, just because it is getting all the love by the FAANG.
> 
> There is a lot of Rust click bait in this forum and some "look Rust can do this and that, we must have it too". I think that D should follow its own path and should not trying to ape Rust in every fashion.

+1.


> A better GC is always welcome and we should really focus on that rather trying to be Rust with its memory management and other quirks.

+1.


T

-- 
MASM = Mana Ada Sistem, Man!
August 27, 2019
27.08.2019 0:48, IGotD- пишет:
> 
> There is a lot of Rust click bait in this forum and some "look Rust can do this and that, we must have it too". I think that D should follow its own path and should not trying to ape Rust in every fashion.
> 
Totally agree

> A better GC is always welcome and we should really focus on that rather trying to be Rust with its memory management and other quirks.
More over I'm satisfied with current GC in D because I use it for simplicity not performance. For latter I use manual memory handling.
August 27, 2019
On 8/26/2019 3:37 AM, Russel Winder wrote:
> 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.

I've translated a lot of C code into betterC, and it isn't hard and do not find myself missing anything about C in the process.

August 27, 2019
On 8/26/2019 4:00 AM, IGotD- wrote:
> 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.

C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.

August 27, 2019
On 8/26/2019 3:44 AM, Russel Winder wrote:
> As I understand it, D, like, Go, requires a runtime system over and above the
> C runtime system.

DasBetterC does not. That was the point of DasBetterC.