Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garbage collection without unsafe code

fitzgen.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Garbage collection without unsafe code

#51

Post by nitwit005 »

marcosscriven wrote: post #20
rurban wrote: post #6

Oh oh, who would have thought. A memory-safe rust at last. With no unsafe allowed, even type safe. Unless you forget about their type bugs: https://github.com/Speykious/cve-rs . So maybe eliminate type and concurrency unsafeties also then in the next decades or so.

I see you’ve been downvoted, but honestly this is news to me. I see that repo is two years old - are there flaws in Rust that aren’t edge cases that would make it not memory safe?

They're being downvoted for the snarkiness (https://news.ycombinator.com/newsguidelines.html)

Re: Garbage collection without unsafe code

#52

Post by bigbadfeline »

pjmlp wrote: post #28
quotemstr wrote: post #17

Earlier quoted context omitted.

If you want automated resource management, automate it. I'm really not convinced that Koka-style effects-for-everything are a win relative to just passing objects that own resources through parameters so they have actual values and explicit lifetimes.

I certainly do, which is why outside some hobby coding to try out new language features, as means to understand where Rust stands, I don't have any special use case where I would pick Rust instead of one of those languages. For me its ideal use case, are places where any form of automated resource management is either not technically possible, or it is a waste of time trying to change mindsets.

> I don't have any special use case where I would pick Rust instead of one of those languages.

Rust isn't a language for a special case, Rust is universal. Those other languages are for special cases, you're simply a special case developer.

Picking a different language for each special case is the primary problem Rust solves, it's the problem of being a jack of all trades and a master of none.

>> If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust.

Can you write the proof down for us please? I'm curious, how do you prove that "for many scenarios" A+B is better than B+A?

The OP is about doing A in safe Rust, which isn't even an option for many of those other languages which are, at the very least, bootstrapped from unsafe code.

Re: Garbage collection without unsafe code

#53

Post by rurban »

adastra22 wrote: post #37
rurban wrote: post #23

Earlier quoted context omitted.

Sure, besides those bugs, read the specs. unsafe blocks. Loud and clear. worse than in Java where the unsafeties were just in a hidden sun class.

I don’t know what your point is. Unsafe blocks in the stdlib isn’t a gotcha. It’s the whole point of unsafe: you provide a validated and ideally proveably correct implementation once, with a safe wrapper. It’s how everything is implemented under the hood. It’s like double entry accounting when you only have one pen and one writing hand. The system is broken if you ever write down only half of a transaction in one led…

So you are fine in calling a language "safe", when it has unsafe blocks, which the compiler skips to check? You have to that manually, and then you are back in C++ land. That's hilarious. You can call it somewhat safe, or mostly safe, but never safe.

Re: Garbage collection without unsafe code

#54

Post by kibwen »

pjmlp wrote: post #9
ltratt wrote: post #7

It would really be good if someone could provide an updated overview of all of the "GCs for Rust" created thus far -- for a while I tried to keep up with them, but there are just too many! When we wrote the Alloy paper, we took Manish's survey as a starting point, and covered as many GCs of different kinds as we could squeeze in [1]. But even then there was no way we could squeeze _everything_ in, and I've seen at le…

If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust. Hence all the Chapel, Swift, D, Linear Haskel, Ox, Idris2, Scala Capture Checking, Koka, and probably many others, efforts going on. This is also noticeable among rustaceans, otherwise ergonomics for all the .clone() a…

> it is better having automated resource management

Rust's ownership system is automated resource management. What you're asking for is dynamic lifetime determination, which Rust provides via types that opt out of the hierarchical single-ownership paradigm.

Re: Garbage collection without unsafe code

#55

Post by kibwen »

rurban wrote: post #41
aw1621107 wrote: post #35

Earlier quoted context omitted.

> They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining "safety", especially when the GC itself involves unsafe code.

Have you ever seen a GC system with memory unsafeties? I cannot remember any

You've made it clear from this thread that you have no idea what you're talking about. Please do not waste our time by commenting on this topic further.

Re: Garbage collection without unsafe code

#56

Post by sfink »

jandrewrogers wrote: post #38
quotemstr wrote: post #18

Earlier quoted context omitted.

Why do you like managing your own memory exactly? Modern GCs are quite good, so the domain in which you can beat their performance is narrow and will continue getting narrower as time goes on.

The software performance gap between modern GC code and non-GC code is still pretty large almost everywhere. GCs make entire classes of optimization effectively impossible. At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code. GCs are useful in the same way that Python is useful even though it is slow. Simplicity of use has intrinsic value but that is a trade…

I agree that GC code can be and usually is slower. But as a counterpoint: allocation can be very slow. Bump allocation is fast. If you know your lifetimes and can free all of your bump-allocated memory in one go, that's pretty much the best you can do. If not, then you can still bump-allocate, but copy away the live stuff while discarding the rest. You keep bump allocation, you may even improve locality by eliminating the fragmentation in your bump allocation arena. On the other hand, you've written a garbage collector and thus inherit the disadvantages of GC.

My point is that you can start out without a GC and do a series of sane and effective optimizations that end you up with a GC. Just as you can start with a GC and optimize by moving more and more of your allocations to non-GC memory and end up without a GC. Which endpoint is faster depends on the workload.

Re: Garbage collection without unsafe code

#57

Post by zozbot234 »

oersted wrote: post #48
zozbot234 wrote: post #39

Earlier quoted context omitted.

Logic bugs are not memory safety issues, they're logic bugs. They cannot result in undefined behavior for the program as a whole, at least in the absence of unsafe code.

As far as I understand, memory safety goes well beyond undefined behavior. It’s a loose term including common pointer manipulation, allocation/deallocation and data-race issues. Other than UB, using indexes instead of pointers can be exactly as error-prone and leads to the same kind of unexpected runtime crashes, memory corruption and security issues. It’s a false sense of security. If you inspect the OP implementati…

> it can panic in an equivalent way to a segmentation fault.

So, like bounds-checked array access? That's also a logic error. Common pointer manipulation (in the presence of discriminated union types), allocation/deallocation errors and data races (when involving array indexes, pointers or tagged data, not just simple valye types) can all lead to UB; bounds-checked array access on its own cannot.

Re: Garbage collection without unsafe code

#58

Post by aw1621107 »

rurban wrote: post #41
aw1621107 wrote: post #35

Earlier quoted context omitted.

> They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining "safety", especially when the GC itself involves unsafe code.

Have you ever seen a GC system with memory unsafeties? I cannot remember any

I think so, assuming I'm thinking of the same thing you are, but I think that's somewhat besides the point. What I'm trying to say is twofold:

- The presence of a GC doesn't guarantee memory safety since there are sources of memory unsafety that GCs don't/can't cover (i.e., escape hatches and/or FFI), not to mention the possibility of bugs in the GC implementation itself.

- The absence of a GC doesn't preclude memory safety since you can "just" refuse to compile anything which you can't prove to be memory-safe modulo escape hatches and/or axioms and/or FFI (and bugs, unfortunately). Formal verification toolchains for C (Frama-C, seL4's setup, etc.) and Ada/SPARK's stricter modes are good examples of this.

In the case of Rust:

- `unsafe` blocks (or at least their precursors) were added in 2011 [0].

- Rust's reference-counting GC was removed in 2014 [1].

That's why I think "ripped out their GC" is a bit of a non-sequitur for "got rid of the safeties". Rust wasn't entirely safe before the GC was removed because `unsafe` already existed. And even after the GC was removed, the entire point of Rust's infamous strictness is to reject programs for which safety can't be proved (modulo the same sources that existed before the GC was removed), so the removal of GC does not necessarily imply losing memory safety either.

[0]: https://github.com/rust-lang/rust/pull/1036

[1]: https://github.com/rust-lang/rust/pull/17666

Re: Garbage collection without unsafe code

#59

Post by sfink »

rurban wrote: post #53
adastra22 wrote: post #37

Earlier quoted context omitted.

I don’t know what your point is. Unsafe blocks in the stdlib isn’t a gotcha. It’s the whole point of unsafe: you provide a validated and ideally proveably correct implementation once, with a safe wrapper. It’s how everything is implemented under the hood. It’s like double entry accounting when you only have one pen and one writing hand. The system is broken if you ever write down only half of a transaction in one led…

So you are fine in calling a language "safe", when it has unsafe blocks, which the compiler skips to check? You have to that manually, and then you are back in C++ land. That's hilarious. You can call it somewhat safe, or mostly safe, but never safe.

Alternatively, you can have a fully safe language, and then to get certain things done you add fundamentally unsafe FFI[1]. Or you use IPC to a process written in an unsafe language. Again, you're "back in C++ land".

It seems like your complaint is that Rust is referred to as a safe language. Which is fine; it's more correct to use the phrase "in safe Rust" rather than assuming that "in Rust" fully implies "safe". That is true, but that's a crack in a sidewalk compared to the chasm of difference between Rust and C++. Why obsess over that crack?

Should we all refer to "Python without FFI or any extensions written in C or another unsafe language" instead of "Python", to avoid asserting that Python-as-it-is-used is a safe language?

[1] Assuming it's FFI to an unsafe language, and that's the main purpose of FFI.

Re: Garbage collection without unsafe code

#60

Post by pjmlp »

kibwen wrote: post #54
pjmlp wrote: post #9

Earlier quoted context omitted.

If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust. Hence all the Chapel, Swift, D, Linear Haskel, Ox, Idris2, Scala Capture Checking, Koka, and probably many others, efforts going on. This is also noticeable among rustaceans, otherwise ergonomics for all the .clone() a…

> it is better having automated resource management Rust's ownership system is automated resource management. What you're asking for is dynamic lifetime determination, which Rust provides via types that opt out of the hierarchical single-ownership paradigm.

Nope, because it has plenty of manual hand holding to keep the compiler happy.
Post reply on HN