A D vs. Rust example

[Don Allen]

On Monday, 24 October 2022 at 20:04:00 UTC, Dukc wrote:
> On Thursday, 20 October 2022 at 13:37:07 UTC, Don Allen wrote:
>> ````
>> use std::cell::RefCell;
>>
>> fn main() {
>>     let foo = RefCell::new(5);
>>     let bar = || {
>>         *foo.borrow_mut() = 17;
>>     };
>>     let baz = || {
>>         *foo.borrow_mut() = 42;
>>     };
>>     bar();
>>     println!("{}", foo.borrow());
>>     baz();
>>     println!("{}", foo.borrow());
>>     }
>> ````
>
> Yes, I believe this shows maybe the biggest weakness of Rust.

I'd disagree about "biggest". My use of closures would get me a 
summons from the Rust Unidiomatic Police. In other words, my 
guess is that not many run across the problem I did.

A more serious weakness, in my opinion, is the difficulty of 
dealing with global state. Statics must be initialized, but the 
initializer must be known at compile-time. So if you want to 
define a global that you need to initialize with a value only 
known at run-time and will never change again, you must define it 
as mutable, with all the issues that raises. And its type will 
need to be Option<the type you really want> and the 
compile-time-known initializer will have to be None. You then 
mutate it to be Some(what-you-want) at run-time. References to 
this will have to be in an "unsafe" block, even though the 
situation would be perfectly safe if immutable statics could be 
initialized at runtime (I think they may be trying to fix this 
with something available only in the nightly version, but I am 
not positive).

Then there's the problem I've mentioned earlier -- Rust considers 
everything to be multi-threaded, even if it isn't. And it imposes 
restrictions on the programmer that are only needed in 
multi-threaded situations, such as considering mutable statics to 
be unsafe. Even if the mutable static is wrapped in a mutex, you 
still need to use unsafe blocks to refer to it.

> I could live with a language having a syntax like that (still 
> better than C++, at least the old standards), but it does slows 
> down working compared to most other new-generation languages.
>
> Too bad. Rust's error handling seems so advanced. I'm not 
> talking only about the ability to be safe without a 
> stop-the-world GC,

Not all GCs are stop-the-world. And, in my opinion, the 
negativity about garbage collectors is exaggerated. There's an 
awful lot of software out there written in gc-ed languages, e.g., 
Python, Go, Javascript, that we all use every day, even on our 
phones, and that performs adequately or more than adequately.

> but about it's ability to detect other errors too. A good 
> example is it's UTF-8 string type. Not only it is guaranteed to 
> point to valid memory, it is statically guaranteed to point to 
> valid UTF-8! A D programmer needs to rely on contract 
> programming instead. Although I think that placing a few 
> asserts is still be a good idea even in Rust.

Yes, there are a lot of positive things to say about Rust. But 
for me, the insistence on no GC disqualifies it from use in 
situations where a GC-ed language would do the job, because of 
the cost in programming difficulty that that insistence imposes, 
e.g., lifetime hell and frustrating battles with the 
borrow-checker. And that difficulty is compounded by the 
multi-threaded assumption and the handling of statics.

>
> Disclaimer: the above is likely to be humbug because I have no 
> usage experience of Rust, only studied it's docs.