Garbage collection without unsafe code
71–80 of 85 posts
Re: Garbage collection without unsafe code
#72Earlier quoted context omitted.
Nope, because it has plenty of manual hand holding to keep the compiler happy.
Manual memory management requires the programmer to insert calls to free at specific points in the program. That's manual static lifetime determination. A traditional garbage collector uses runtime analysis to determine when it's safe to call free. That's automatic dynamic lifetime determination. What Rust does is automatic static lifetime determination. Designing your data structures such that they're acyclic is not…
There is nothing automatic out of it.
Write Rust code, compile error if done incorrectly, manually fix the data structure or algorithm root cause, loop.
Re: Garbage collection without unsafe code
#73Earlier quoted context omitted.
When every problem looks like a nail... The proof is the amount of research that is ongoing for plenty of people that don't consider Rust as it stands today, the ultimate answer in programming languages, including people like Niko Matsakis. Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?
> Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap? I don't deny the existence of special cases or the value of looking for better ergonomics even at the expense of university. However, at the moment Rust is the best option for practitioners who don't have enough time to juggle multiple languages.
Re: Garbage collection without unsafe code
#74Frankly, it always feels a bit wrong to me to get around Rust's strictness for pointers by just replacing them with IDs/indexes/offsets into some collection. You can still have many of the same memory-safety issues as with pointers, except that now they become logic bugs that are undetectable by the compiler. Either use unsafe and think about using raw pointers carefully, respecting the soundness rules, or truly rede…
I think the simple fact that pointers are not guaranteed aligned/valid even if they are in range of a particular slice/collection etc. actually makes it very different
Re: Garbage collection without unsafe code
#75Earlier quoted context omitted.
The perfectly safe platonic ideal you are implying cannot exist. Rust is a safe language because it bounds the unsafely to the minimal, clearly demarcated area where it can be reviewed and proven (outside the bounds of the type system) to hold. That is not "back in C++ land."
The perfectly safe ideal does exist and is called safe. Calling unsafe safe is not even Sophism, it is mere lying
Re: Garbage collection without unsafe code
#76Earlier quoted context omitted.
Sure, but then they shout all over how safe they are. They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. No, that's common knowledge. I fixed concurrency safety by forbidding blocking IO. Others also. Maybe there are other ways, but never heard of other ways.
Huh? It doesn't follow that forbidding blocking IO is either necessary or sufficient for concurrency safety, at least under any definition of "safety" I can imagine. What do you mean? You mean async-not-blocking-event-loop stuff? That's not the only way to do more than one IO at a time.
Re: Garbage collection without unsafe code
#77Earlier quoted context omitted.
The perfectly safe ideal does exist and is called safe. Calling unsafe safe is not even Sophism, it is mere lying
Real machines and reality aren't built out of safe primitives. Safe constructs have to be built out of unsafe components. That's just how computers work.
"C programmers think memory management is too important to be left to the computer. Lisp programmers think memory management is too important to be left to the user." Ellis and Stroustrup, The Annotated C++ Reference Manual.
Re: Garbage collection without unsafe code
#78Earlier quoted context omitted.
Real machines and reality aren't built out of safe primitives. Safe constructs have to be built out of unsafe components. That's just how computers work.
Sure, that's why safe languages forbid users to use unsafe things. "C programmers think memory management is too important to be left to the computer. Lisp programmers think memory management is too important to be left to the user." Ellis and Stroustrup, The Annotated C++ Reference Manual.
In the mean time, in the messy world of writing software today, one does frequently enough come across the need for new safety primitives. Things that are provably correct but which the type system of your language does not support. In these instances, unsafe lets you lower down into systems code to build and safely wrap these new components.
Re: Garbage collection without unsafe code
#79Earlier quoted context omitted.
Sure, that's why safe languages forbid users to use unsafe things. "C programmers think memory management is too important to be left to the computer. Lisp programmers think memory management is too important to be left to the user." Ellis and Stroustrup, The Annotated C++ Reference Manual.
You need a systems programming language to write safe systems. That's what Rust is. Maybe there's room for a higher-level 100% safe language. Rust would be a good language to write it in. In the mean time, in the messy world of writing software today, one does frequently enough come across the need for new safety primitives. Things that are provably correct but which the type system of your language does not support.…
But there exist safe systems programming languages. Safe systems were done in these languages. Just nobody cared, so they died or have no market share.
Re: Garbage collection without unsafe code
#80Earlier quoted context omitted.
You need a systems programming language to write safe systems. That's what Rust is. Maybe there's room for a higher-level 100% safe language. Rust would be a good language to write it in. In the mean time, in the messy world of writing software today, one does frequently enough come across the need for new safety primitives. Things that are provably correct but which the type system of your language does not support.…
Yes, Rust is a good systems programming language. Just not safe. Safer than most others, yes. Good enough, yes. But there exist safe systems programming languages. Safe systems were done in these languages. Just nobody cared, so they died or have no market share.