5 ms·
Memory management is difficult, extremely difficult, to get correct in the way rust does. I don't think I've seen a leak or bad dereference in years. The only w
by duaneb 10y ago
Memory management is difficult, extremely difficult, to get correct in the way rust does. I don't think I've seen a leak or bad dereference in years. The only way it really manages this is by tying references into what amounts to a proof assistant. Every simpler method of which I can think either sacrifices capability (e.g. no references at all; only raii + copy on write) or it becomes a GC with all its wonderful trade offs.
GC isn't terrible, though. Azul has struck an amazing balance between latency and eagerness—even if you can't afford it the technology does exist. If you don't have latency, memory restrictions, or embedding requirements, rust may be overkill.
- the_duke 10y agoI think you meant -> 'extreymely difficult to get INcorrect in the way rust does'
- vardump 10y ago> If you don't have latency, memory restrictions, or embedding requirements Add power consumption to that list.
- quotemstr 10y ago> Memory management is difficult, extremely difficult, to get correct in the way rust does Memory management isn't hard --- you just need to pay attention to detail and not say "YOLO, let's abort on OOM" like the Rust stdlib does. Rust is an unacceptable language for anyone who cares about robustly responding to heap exhaustion.
- Turing_Machine 10y ago"Memory management isn't hard --- you just need to pay attention to detail" You're quite right. The problem is that every bit of attention you spend on that detail is attention that you're not spending on details that are actually solving your problem. I programmed in C for decades. I do not miss malloc() and free() in the least. (I still do use C when the situation warrants, but the situations where it is warranted are becoming rarer and rarer with each passing year).