31–40 of 85 posts
Earlier quoted context omitted.
Given your nick, one of the points of 2026 roadmap is exactly trying to make Rust more Swift like, or any other language with RC as automatic resource mechanism for that matter, removing the .clone() pain. Or the experiements Niko Matsakis is doing with Dada.
> Given your nick Weirdly, I picked this screen name about a decade before Swift the language (and several years before Swift the singer) debuted
I really like rust because it does NOT have garbage collection. Can someone smarter than me help me understand the benefits of having GC in rust specifically? Does it enable things that are more difficult in "non GC" rust?
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.
Of course, many GCs have indeed gotten better in their own right, but not using the GC at all remains the most potent optimization.
Either use unsafe and think about using raw pointers carefully, respecting the soundness rules, or truly redesign it using idiomatic Rust constructs. But don't hide complexity under the rug by using indexes instead of pointers, it's mostly the same thing.
I really enjoyed the write-up though, I learned a lot from it, not to discount that.
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?
If the repo is what I think it is, the underlying bug is over a decade old [0]. From what I understand the devs have known how to solve it for pretty much this entire time, but their desired solution is blocked on some rather large refactorings elsewhere in the compiler.
> are there flaws in Rust that aren’t edge cases that would make it not memory safe?
cve-rs is probably the most well-known one, but it's definitely not the only one [1]. That being said, I think there's a not-unreasonable argument to be made that cve-rs counts as an edge case since (as far as I know) there's no publicly-known examples of code that has "organically" run into this.
On a more practical note, I think if you're worried about memory safety in Rust code type system holes are vanishingly unlikely to be the cause compared to more "normal" things like mistakes in-around `unsafe` blocks.
[0]: https://github.com/rust-lang/rust/issues/25860
[1]: https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...
Earlier quoted context omitted.
> There are unsafe blocks all over the stdlib Physics is unsafe. Something, somewhere needs to provide the safe core. > And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged. Is your position that blocking IO can't be compatible with concurrency safety? That's a strange claim. Can you explain?
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.
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.
I really like rust because it does NOT have garbage collection. Can someone smarter than me help me understand the benefits of having GC in rust specifically? Does it enable things that are more difficult in "non GC" rust?
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.
Earlier quoted context omitted.
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?
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.
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 ledger: you always need to record both the flow in and flow out on both ledgers. Writing either one of them is an unsafe operation. But you can only write one thing at a time. So write them in pairs in an unsafe {} block, and reuse that block safely.
I really like rust because it does NOT have garbage collection. Can someone smarter than me help me understand the benefits of having GC in rust specifically? Does it enable things that are more difficult in "non GC" rust?
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.
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 tradeoff against other objectives.
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…
Earlier quoted context omitted.
The existence of a soundness bug in the typechecker doesn’t refute the value of soundness as a language design contract. If anything it’s the opposite: issues demonstrated by cve-rs are _language bugs_ and are _fixable_ in principle. “Safe Rust should be memory-safe” is a well-defined, falsifiable contract that the compiler can be measured against. Meanwhile memory unsafety is a feature of the semantics of C++ and so…
The language design contract is unsafe by default. In memory, types and concurrency. What are you talking about? There are unsafe blocks all over the stdlib. And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged.
False. The language design safe by default, something that you can confirm super easily doing just the Rust tutorials and compare the same with C or C++.
Read the repo well:
cve-rs implements the following bugs in safe Rust:
Use after free
Buffer overflow
Segmentation fault
> There are unsafe blocks all over the stdlib
Unsafe blocks is not the same that unsafe code. Are marked areas that are required to do escape automated checks, and there, you are at the level of a C/C++ programmer (where in that languages ALL THE CODE IS MARKED UNSAFE).
If you complaint against that, is the same as complaint against ALL THE CODE writer on C/C++.
---
One thing important to understand about Rust: Rust is a system language and SHOULD be able to implement everyting including, Buffer overflow, Use after free , Segmentation fault and such. You should be able to implement a terrible OS, malware, faulty drivers, etc, minimally because that is required to test safe programs!
(example: Deterministic Simulation Testing https://turso.tech/blog/introducing-limbo-a-complete-rewrite...).
But what Rust gives is that not assume that you want to do it for most programs.