3 ms·

Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected lan

by blub 4y ago

Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected languages start to become attractive - see golang competing with Rust in unexpected areas. Perhaps the only hard part is storing and passing references everywhere, which may mean that one has to act like an automaton and patiently type their lifetimes to the Rust compiler. Unfortunately the Rust programming community has settled exactly on this kind of reference usage.

kaba0 4y ago
Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety. Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for way too long, but I never really understood the desire to use it for CRUD apps and the like. Sure, to each their own, but it is just an arguably bad choice. Even OSs could be written in managed languages - it’s not like it hasn’t been done before and they can just as well have escape hatches like Rust’s unsafe (hell, they are likely even safer if they are only used to manipulate “external heap”)
- rstuart4133 4y ago
  All true, but I suspect the end goal Rust's type system wasn't to eliminate GC. It was "fearless concurrency". You can see this in languages that encourage multithreadeding and have a GC. In Go memory allocation is easy because of GC, but even so naively put working single threaded Go code in a multithreaded environment and it will likely segfault. GC doesn't solve the currency problem. I suspect it was just happy circumstance that a type system so strong it makes memory access compile time checkable is also strong enough to eliminate the overheads of GC. So they did that too. But the claim that all this tediousness is there to eliminate GC sort of misses the point - that's not the reason they introduced it. Rust's complex type system is a type of formal proof system that eliminates a lot of bugs at compile time. The "sum types" discussion above talks about another class of bugs it eliminates. Eliminating bugs at compile time is the point - not making memory allocation easier.
  - kaba0 4y ago
    Well, Rust doesn’t solve concurrency issues either, it can only prevent data races which is a tiny subset only. There are different kinds of race conditions as well, deadlocks, livelocks, etc which are generally unsolvable. And to be honest, Rust doesn’t have all that strong type system compared to Haskell/ML which introduced these concepts in the first place. Also, there are plenty of languages in the category of “managed, with a strong type system”.

by blub 4y ago

kaba0 4y ago

Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety. Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for way too long, but I never really understood the desire to use it for CRUD apps and the like. Sure, to each their own, but it is just an arguably bad choice. Even OSs could be written in managed languages - it’s not like it hasn’t been done before and they can just as well have escape hatches like Rust’s unsafe (hell, they are likely even safer if they are only used to manipulate “external heap”)

rstuart4133 4y ago
All true, but I suspect the end goal Rust's type system wasn't to eliminate GC. It was "fearless concurrency". You can see this in languages that encourage multithreadeding and have a GC. In Go memory allocation is easy because of GC, but even so naively put working single threaded Go code in a multithreaded environment and it will likely segfault. GC doesn't solve the currency problem. I suspect it was just happy circumstance that a type system so strong it makes memory access compile time checkable is also strong enough to eliminate the overheads of GC. So they did that too. But the claim that all this tediousness is there to eliminate GC sort of misses the point - that's not the reason they introduced it. Rust's complex type system is a type of formal proof system that eliminates a lot of bugs at compile time. The "sum types" discussion above talks about another class of bugs it eliminates. Eliminating bugs at compile time is the point - not making memory allocation easier.
- kaba0 4y ago
  Well, Rust doesn’t solve concurrency issues either, it can only prevent data races which is a tiny subset only. There are different kinds of race conditions as well, deadlocks, livelocks, etc which are generally unsolvable. And to be honest, Rust doesn’t have all that strong type system compared to Haskell/ML which introduced these concepts in the first place. Also, there are plenty of languages in the category of “managed, with a strong type system”.