A D vs. Rust example

[IGotD-]

On Thursday, 20 October 2022 at 13:37:07 UTC, Don Allen wrote:
>
> This is just one of multiple examples I personally encountered 
> where Rust's approach to memory- and thread-safety makes life 
> difficult for its users. On simple cost-benefit grounds, I can 
> see using Rust for writing OS drivers (or even an entire OS) or 
> for use in embedded systems, especially if there's a real-time 
> constraint; in other words, where a GC would be unsuitable. But 
> for ordinary applications on today's hardware? Use of Rust 
> instead of D, Go, Nim, etc. makes no sense to me.

Actually, Rust is even worse for embedded, OS, near hardware 
programming. The memory model just gets in the way of doing those 
things. Example of things in OS programming are often intrusive 
containers, pointers/references pointing in all directions and 
sometimes even to itself, multiple use of containers for the same 
object, chicken and egg problems. This is where the memory model 
of just Rust breaks down. Of course you have to use unsafe 
everywhere but as soon as you do that, things get ugly very 
quickly. For these tasks C++ is still the obvious choice. 
However, this is not normal programming and you have to do tricks 
that you never usually do in application programming.

In short Rust is a useless language for embedded and it would 
take forever to become productive. Also information how to do 
this in Rust is difficult to find as most of Rust programs are 
just normal applications and that is also what Rust was 
originally designed for. I've tried several languages in order to 
evaluate how it can deal with embedded programs (more advanced 
than just blinking a LED, real resource handling). I've evaluated 
Rust, D, Nim, Swift among others and Rust got the place at very 
bottom by a great margin. There were simply things I couldn't do 
in Rust and even if it possible it would have taken ages do 
figure out how to do it. The other languages were more easy, not 
perfect and you had do deal with some quirks but you understood 
why and how you could work around them.

Just like you I found out how the memory model isn't even zero 
cost with that you quickly have to resort to reference counting 
and with that RefCell (which is a runtime check) must be used as 
you suddenly have several possible paths of mutuable borrows.

For financial software I would run from Rust faster than a 
rabbit. It's just too complicated and other languages offer 
faster developing times with more convenient libraries.

I'm puzzled with the high popularity of Rust, like some kind of 
mass exorcism.