Live data from Hacker News

Garbage collection without unsafe code

fitzgen.com

71–80 of 85 posts

Re: Garbage collection without unsafe code

#72
post #67
post #60

Earlier 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…

Rust requires the programmer to manually design data structures and code algorithms in a way that doesn't trigger borrower checker compile errors.

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

#73
post #61

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

Practitioners who don't have enough time to juggle multiple languages are on the wrong business.

Re: Garbage collection without unsafe code

#74
post #33

Frankly, 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…

> But don't hide complexity under the rug by using indexes instead of pointers, it's mostly the same thing.

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

#75
post #69

Earlier 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

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.

Re: Garbage collection without unsafe code

#76
post #24

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

Non-blocking IO is only one part to provide concurrency safety. Process locks are even worse. All locks are forbidden to avoid dead-locks.

Re: Garbage collection without unsafe code

#77
post #69

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

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.

Re: Garbage collection without unsafe code

#78
post #77

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

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

#79
post #77

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

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.

Re: Garbage collection without unsafe code

#80
post #79

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

Which ones?
Post reply on HN