A D vs. Rust example

[Don Allen]

On Thursday, 20 October 2022 at 14:26:07 UTC, IGotD- wrote:
> 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.

Thank you for your evaluation of Rust for embedded work based on 
actual experience, which I don't have. I think the lesson of both 
yours and my experience is that you have to actually try it, get 
your hands dirty, to understand whether Rust is suitable for both 
your problem domain and your programming style. You will learn 
nothing from reading the hype (Exhibit A: the "affectionately 
named" Book; was this written by a 12-year-old?). I mention the 
programming style because, for example, someone who had spent 
their programming life writing C would likely not have 
encountered the closure issue I did. If all the functions are at 
top level and everything they need is passed to them as 
arguments, no problem.

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

People (alarmingly frequently) mindlessly jump on band-wagons. 
We're seeing it in today's politics, but I'll stop right there 
before destroying this forum :-)