3 ms·

> Also, Bolt runs on the JVM and thus has a garbage collector No, Bolt targets LLVM IR As for your other points, whilst there are escape hatches in Rust that

> Also, Bolt runs on the JVM and thus has a garbage collector No, Bolt targets LLVM IR As for your other points, whilst there are escape hatches in Rust that do let you do it, it's not in the core ownership type system. That's what is being compared - the type systems. The escape hatches mean you lose some of the guarantees the type system gives you - Bolt's approach still gives you the guarantees. That's the difference.

aliceryhl 6y ago
What guarantee does Bolt provide around mutable aliased references that Rust's `&Cell` doesn't?
whyever 6y ago
I'm not sure what you mean by bypassing the type system. The types mentioned are part of the type system. Some of them move checks from compile time to run time. `unsafe` could be seen as an escape hatch, but as far as I understand that wasn't part of the discussion?
comex 6y ago
> No, Bolt targets LLVM IR Oops! That's a pretty embarrassing mistake for me to make, especially while I'm criticizing your own portrayal of Rust as mistaken. When I was searching through the paper to figure out how Bolt used garbage collection or reference counting, I saw the mention of the JVM and got mixed up. Never mind that the paper does talk extensively about LLVM IR -_- However… I believe the bulk of my point about garbage collection is nonetheless accurate. To avoid making further errors, I went and built Bolt and used it to compile some test programs (based on master branch; let me know if I should be looking elsewhere). Based on that, it seems that the current implementation simply never frees memory at all. (That explains why garbage collection wasn't mentioned in the paper...) This is reasonable enough for a prototype – Rust did the same once! – but it's effectively simulating the semantics of a garbage collected environment, where you can just load a pointer from somewhere and then dereference it whenever you want. You don't have to prevent other code from freeing the pointer, either dynamically by incrementing a reference count, or statically by forbidding mutable aliasing. Do you expect a production system based on Bolt's semantics would use garbage collection, or some other memory management technique? If the answer is garbage collection, then indeed, being able to just load a pointer is a meaningful benefit that garbage collected environments have. But of course, garbage collection also has its costs, and the reason Rust's borrow checker is so restrictive is specifically to avoid garbage collection. If the answer is some other system, you should explain what mechanism would be used to prevent use-after-free and how that would affect performance. (I suppose different types could use different mechanisms. I'm focusing on the case where class A points to class B which points to class C, and A's pointer to B uses a `local` (i.e. aliasing mutable) capability.) > As for your other points, whilst there are escape hatches in Rust that do let you do it, it's not in the core ownership type system. That's what is being compared - the type systems. > The escape hatches mean you lose some of the guarantees the type system gives you - Bolt's approach still gives you the guarantees. That's the difference. It depends what you mean by "lose some of the guarantees". Do you mean: 1. You can use the APIs to violate type system guarantees? All of the APIs I mentioned are safe interfaces. In other words, as long as the implementation is correct, they are impossible to misuse; you can't use them to violate memory safety or other type system guarantees. 2. The implementations of the APIs, if buggy, can violate type system guarantees? They implementations do use `unsafe` internally, so if they're incorrect they could violate memory safety. But if the same functionality were instead exposed as language features, you would still have to trust the compiler to implement them correctly. Rust's philosophy is that this is not necessarily an improvement. On the contrary, as the philosophy goes, if you can implement a feature entirely as a library, it should be a library rather than a language feature. 3. The APIs have a cruder interface and thus cannot provide the same kinds of guarantees in the first place that a builtin language feature could? If this is what you mean, it's more valid, but it depends on the feature. Personally, I think ergonomics are a bigger issue here than guarantees per se.

aliceryhl 6y ago

What guarantee does Bolt provide around mutable aliased references that Rust's `&Cell` doesn't?

whyever 6y ago

I'm not sure what you mean by bypassing the type system. The types mentioned are part of the type system. Some of them move checks from compile time to run time. `unsafe` could be seen as an escape hatch, but as far as I understand that wasn't part of the discussion?

comex 6y ago

> No, Bolt targets LLVM IR Oops! That's a pretty embarrassing mistake for me to make, especially while I'm criticizing your own portrayal of Rust as mistaken. When I was searching through the paper to figure out how Bolt used garbage collection or reference counting, I saw the mention of the JVM and got mixed up. Never mind that the paper does talk extensively about LLVM IR -_- However… I believe the bulk of my point about garbage collection is nonetheless accurate. To avoid making further errors, I went and built Bolt and used it to compile some test programs (based on master branch; let me know if I should be looking elsewhere). Based on that, it seems that the current implementation simply never frees memory at all. (That explains why garbage collection wasn't mentioned in the paper...) This is reasonable enough for a prototype – Rust did the same once! – but it's effectively simulating the semantics of a garbage collected environment, where you can just load a pointer from somewhere and then dereference it whenever you want. You don't have to prevent other code from freeing the pointer, either dynamically by incrementing a reference count, or statically by forbidding mutable aliasing. Do you expect a production system based on Bolt's semantics would use garbage collection, or some other memory management technique? If the answer is garbage collection, then indeed, being able to just load a pointer is a meaningful benefit that garbage collected environments have. But of course, garbage collection also has its costs, and the reason Rust's borrow checker is so restrictive is specifically to avoid garbage collection. If the answer is some other system, you should explain what mechanism would be used to prevent use-after-free and how that would affect performance. (I suppose different types could use different mechanisms. I'm focusing on the case where class A points to class B which points to class C, and A's pointer to B uses a `local` (i.e. aliasing mutable) capability.) > As for your other points, whilst there are escape hatches in Rust that do let you do it, it's not in the core ownership type system. That's what is being compared - the type systems. > The escape hatches mean you lose some of the guarantees the type system gives you - Bolt's approach still gives you the guarantees. That's the difference. It depends what you mean by "lose some of the guarantees". Do you mean: 1. You can use the APIs to violate type system guarantees? All of the APIs I mentioned are safe interfaces. In other words, as long as the implementation is correct, they are impossible to misuse; you can't use them to violate memory safety or other type system guarantees. 2. The implementations of the APIs, if buggy, can violate type system guarantees? They implementations do use `unsafe` internally, so if they're incorrect they could violate memory safety. But if the same functionality were instead exposed as language features, you would still have to trust the compiler to implement them correctly. Rust's philosophy is that this is not necessarily an improvement. On the contrary, as the philosophy goes, if you can implement a feature entirely as a library, it should be a library rather than a language feature. 3. The APIs have a cruder interface and thus cannot provide the same kinds of guarantees in the first place that a builtin language feature could? If this is what you mean, it's more valid, but it depends on the feature. Personally, I think ergonomics are a bigger issue here than guarantees per se.