A D vs. Rust example

[Paulo Pinto]

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

Useless or not, it is becoming a thing,

https://www.autosar.org/news-events/details/autosar-investigates-how-the-programming-language-rust-could-be-applied-in-adaptive-platform-context/

https://opensource.googleblog.com/2022/10/announcing-kataos-and-sparrow.html

https://azure.microsoft.com/en-us/blog/delivering-consistency-and-transparency-for-cloud-hardware-security/

https://techcommunity.microsoft.com/t5/internet-of-things-blog/previewing-rust-on-azure-sphere/ba-p/3494988

https://github.com/orgs/esp-rs/projects/1

https://www.eenewseurope.com/en/arm-joins-the-rust-foundation/

https://www.phoronix.com/news/Rust-Is-Merged-Linux-6.1

I could keep posting links about Rust's rise on the embedded 
space, but I think you got the point.

Naturally I also agree that systems programming languages with GC 
should be used, but  unless we have a big name pushing them, 
affine type systems have won for low level systems coding.