Why Rust for safe systems programming:
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/

Can DLang be disabled for GC, or is it necessary to disable it? Of course, many people do not like betterC.

code that could activate the GC will fail to compile in code annotated with @nogc

On Wed, Jul 24, 2019 at 1:50 PM zoujiaqing via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Why Rust for safe systems programming: https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
>
> Can DLang be disabled for GC, or is it necessary to disable it? Of course, many people do not like betterC.

On Wednesday, 24 July 2019 at 04:45:48 UTC, Danni Coy wrote:
> code that could activate the GC will fail to compile in code annotated with @nogc
>
> On Wed, Jul 24, 2019 at 1:50 PM zoujiaqing via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> Why Rust for safe systems programming: https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
>>
>> Can DLang be disabled for GC, or is it necessary to disable it? Of course, many people do not like betterC.

Well, it still doesn't disable the GC since the runtime still loads it.

Also you can still use the GC in @nogc code if you use `assumeNoGC` so it's not entirely gone.

On Wednesday, 24 July 2019 at 06:22:01 UTC, bauss wrote:

>>> Can DLang be disabled for GC, or is it necessary to disable it? Of course, many people do not like betterC.
>
> Well, it still doesn't disable the GC since the runtime still loads it.
>
> Also you can still use the GC in @nogc code if you use `assumeNoGC` so it's not entirely gone.

Yeah, things like `@nogc` and `-betterC` are kludgy to me. I hope one day for an opt-in language where you just pay for what you use without any special attributes or compiler switches.

As mentioned in the article, one of the benefits of C, C++, and Rust is their "minimal and optional runtime".  I've tried to move D in that direction, but I've only had mild success.  I keep picking away at it, and welcome others to join in.

Mike

On Wednesday, 24 July 2019 at 03:45:45 UTC, zoujiaqing wrote:
> Why Rust for safe systems programming:
> https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
>
> Can DLang be disabled for GC, or is it necessary to disable it? Of course, many people do not like betterC.

"Rust provides the performance and control needed to write low-level systems, while empowering software developers to write robust, secure programs."

I have tried to write low level programming with Rust and this is the part where Rust is absolutely awful. Rust is fine for application programming in an existing OS but for low level stuff it is a dead end.

Low level programming, system programming, OS programming or whatever you want to call often requires another way of programming. Intrusive algorithms are common in order reduce memory fragmentation. Pointer tricks are common. Look at Linux, loads of pointers pointing around to different structures, often in a circular manner. Here Rust will be totally lost. You can do raw pointer programming with Rust but then the borrow checker is out of commission and you have to manually track the memory, then the point of Rust is pretty much gone.

I tried to write a few algorithms in Rust that I usually use in embedded system. It was incredible difficult, even more difficult and less verbose than C++. I gave up on Rust. I tried the same algorithms in D and it was very easy in comparison, even more easy than C++ and I'm not even good D programming.

I don't really care about the memory management in Rust, as memory management is very specialized in embedded systems anyway. What is for me much more important are the bounds checking.

On Wednesday, 24 July 2019 at 07:54:54 UTC, IGotD- wrote:
> On Wednesday, 24 July 2019 at 03:45:45 UTC, zoujiaqing wrote:
>> Why Rust for safe systems programming:
>> https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
>>
>> Can DLang be disabled for GC, or is it necessary to disable it? Of course, many people do not like betterC.
>
> "Rust provides the performance and control needed to write low-level systems, while empowering software developers to write robust, secure programs."
>
> I have tried to write low level programming with Rust and this is the part where Rust is absolutely awful. Rust is fine for application programming in an existing OS but for low level stuff it is a dead end.
>
> Low level programming, system programming, OS programming or whatever you want to call often requires another way of programming. Intrusive algorithms are common in order reduce memory fragmentation. Pointer tricks are common. Look at Linux, loads of pointers pointing around to different structures, often in a circular manner. Here Rust will be totally lost. You can do raw pointer programming with Rust but then the borrow checker is out of commission and you have to manually track the memory, then the point of Rust is pretty much gone.
>
> I tried to write a few algorithms in Rust that I usually use in embedded system. It was incredible difficult, even more difficult and less verbose than C++. I gave up on Rust. I tried the same algorithms in D and it was very easy in comparison, even more easy than C++ and I'm not even good D programming.
>
> I don't really care about the memory management in Rust, as memory management is very specialized in embedded systems anyway. What is for me much more important are the bounds checking.

If you are interested in low level programming in D, me and Edi Staniloiu
had a bachelor student port a linux network driver (virtio-net) in D ...
and it worked. The improvements were: (1) bounds checking and (2) using templates instead of void* thus making this particular driver @safer.

You can check out the implementation [1] and also the student's
talk at Dconf [2].

Cheers,
RazvanN

[1] https://github.com/alexandrumc/linux/tree/initial-poc
[2] https://www.youtube.com/watch?v=weRSwbZtKu0&list=PLIldXzSkPUXWORGtUrnTo2ylziTHR8_Sq&index=14

24.07.2019 10:54, IGotD- пишет:
> 
> "Rust provides the performance and control needed to write low-level systems, while empowering software developers to write robust, secure programs."
> 
> I have tried to write low level programming with Rust and this is the part where Rust is absolutely awful. Rust is fine for application programming in an existing OS but for low level stuff it is a dead end.
> 
> Low level programming, system programming, OS programming or whatever you want to call often requires another way of programming. Intrusive algorithms are common in order reduce memory fragmentation. Pointer tricks are common. Look at Linux, loads of pointers pointing around to different structures, often in a circular manner. Here Rust will be totally lost. You can do raw pointer programming with Rust but then the borrow checker is out of commission and you have to manually track the memory, then the point of Rust is pretty much gone.
> 
> I tried to write a few algorithms in Rust that I usually use in embedded system. It was incredible difficult, even more difficult and less verbose than C++. I gave up on Rust. I tried the same algorithms in D and it was very easy in comparison, even more easy than C++ and I'm not even good D programming.
> 
> I don't really care about the memory management in Rust, as memory management is very specialized in embedded systems anyway. What is for me much more important are the bounds checking.
> 

One of active user of Rust rewrite one of his bindings to C library from Rust to C again because:
```
Currently there is 11 THOUSAND lines of Rust in wlroots-rs. All of this code is just wrapper code, it doesn’t do anything but memory management. This isn’t just repeated code either, I defined a very complicated and ugly macro to try to make it easier.

This wrapper code doesn’t cover even half of the API surface of wlroots. It’s exhausting writing wlroots-rs code, memory management is constantly on my mind because that’s the whole purpose of the library. It’s a very boring problem and it’s always at odds with usability - see the motivation for the escape from callback hell described above.

To do all of this, and then go write Way Cooler, already a big undertaking, is too much for me to commit to. When the benefit at the end of the day is just so I don’t have to write C, that doesn’t really make it worth it. If I got this out of the box by simply linking to the library, like I can in C++, then it would be much more tenable.

I can always just use unsafe bindings to wlroots, just like I would with any other language. However, the entire point of Rust is that it’s safe. Doing that is not an option because at that point you lose the entire benefit of the language.
```

Everything has its price. Rust has both advantages and disadvantages, it isn't suitable everywhere and anytime. Also there is too much hype about Rust.

On Wednesday, 24 July 2019 at 06:22:01 UTC, bauss wrote:
> Well, it still doesn't disable the GC since the runtime still loads it.

Doesn't really matter, the important thing is that no collections are done if no GC allocations are made, and @nogc enforces this (in @safe code at least).

> Also you can still use the GC in @nogc code if you use `assumeNoGC` so it's not entirely gone.

That's not @safe. Anything can happen in @system code.

On Wednesday, 24 July 2019 at 07:54:54 UTC, IGotD- wrote:
> I tried to write a few algorithms in Rust that I usually use in embedded system. It was incredible difficult, even more difficult and less verbose than C++. I gave up on Rust. I tried the same algorithms in D and it was very easy in comparison, even more easy than C++ and I'm not even good D programming.

AFAIK, not all data structures can be safely expressed in rust, so you can't simply translate your code, but must redesign it in a rust-friendly way.

On Wednesday, 24 July 2019 at 06:51:36 UTC, Mike Franklin wrote:
> Yeah, things like `@nogc` and `-betterC` are kludgy to me. I hope one day for an opt-in language where you just pay for what you use without any special attributes or compiler switches.

@nogc serves a different purpose: it enforces restriction that you don't end up using a feature even if you accidentally try to.