12 comments

[ 0.24 ms ] story [ 35.9 ms ] thread
Just intuitively, this seems to be using a feature designed to guarantee safety in a way that doesn’t guarantee safety, which raises questions about what the point is.
Just use unsafe then you have all of the good points of rust, like being able to say you wrote it in rust with none of the downsides, like having to write safe code in rust, or that code being slow.
You can write slow unsafe Rust just fine.
I clicked on this hoping is was about physical garbage collection
I'm hoping for a future in which humankind looks back with embarrassment at this silly period in its history in which people used to think a leaky and bad abstractions like garbage collection was ever a good approach to deal with resource life-times.
Some problems are just fundamentally easier to solve using cyclic data structures whose lifetime exceeds the scope where they were created, which would be quite difficult to clean up properly in any other way.
Indeed. I also hope we stop using all of these "high-level" languages. So much overhead just so people don't have to learn how to write proper optimized machine code. It's super-trivial to write a website directly in that too, and it only takes a bit longer, but it is almost twice as fast.
I'm a big fan of high-level languages and abstractions. I'm just not a fan of bad abstractions.
Writing a GC in rust without just dropping the whole business into unsafe is really annoying.

Jason Orendorff has an implementation of a GC in rust called "cell-gc" that seemed like only one I've seen so far that seemed to "get" how to marry rust to the requirements of a GC implementation: https://github.com/jorendorff/cell-gc

Still has a lot of unsafe code and macro helpers, but it's laid out well and documented pretty well. Not sure if you've run across it yet.