DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
41% Positive
Analyzed from 1350 words in the discussion.
Trending Topics
#compiler#reference#garbage#rust#every#collection#memory#code#object#right
Discussion (24 Comments)Read Original on HackerNews
That's a strange thing to assert, having acknowledged the existence of generational GC.
> Reference counting also has its own running cost, paid on every copy of a pointer you make and every time you drop one.
isn’t 100% true. It’s not necessarily on every copy or drop. Compilers can (and do) elide reference count updates if they can proof they aren’t needed, and can even skip allocating room for reference counts if they can proof it isn’t needed (example: a local object that doesn’t escape its scope)
I also find it a miss that the article doesn’t discuss memory usage. A garbage-collected program needs more memory to match the performance of the equivalent manually managed language.
https://dl.acm.org/doi/10.1145/1094811.1094836 says you need to give it 5 times the memory, but that’s from 2005 and likely outdated.
Also every single graphics application that uses Metal or DirectX, relies on reference counting as GC algorithm.
Oh shit…
How do you "optimize" the GC away after you wrote your entire database server in a language that uses it?
But the most naive example any language supports is simple object pooling.
Then more fancy, zero allocations tasks in C# https://github.com/cysharp/unitask
(Even though, no, that's not typical. That's a tiny minority of them.)
I disagree with this. The sentence implies that this work is done in order to make the compiler happy, where my experience is that it forces the programmer to actually get it right.
I had an "aha moment" when I was frustrated at failing to express my intent to the compiler, and suddenly realised that the reason I couldn't "just say the magic words" was that my object ownership design was inherently flawed. I had to make large changes not to make the compiler happy, but to actually have a coherent design.
So no, it's not about what "the compiler can verify". That's like saying "my lawyer won't let me do this". No, your lawyer is your employee, not your boss. They're just saying that if you do this, then you may go to prison. It's not the same thing.
("unsafe" is the Rust way to go "thank you, legal department, but I'm making a business decision to take this risk. Your concern has been noted")
Let’s say you have two ways of doing the same thing: both work, both are legit and neither introduce GC bugs. The only difference between the two is that one can be verified by the compiler while the other can’t, so you are stuck with solution no. 1 although both would work.
To phrase it differently: the code that gets verified by the compiler is safe, but is all safe code verifiable by the compiler?
I’m not implying that’s the case, but that’s what I feel the author is saying.
Right. And this reduces to the halting problem, so in theory the compiler cannot know that all safe code is safe.
In practice, I'm saying that not just syntactically, but in your code's design, the compiler is more likely to be right. It's a bit like Chesterton's fence. You can bypass the lifetime checks if you just have the confidence to say "yes, I'll use `unsafe` here and it's fine because these reasons". As you're writing your "SAFETY" comment, you may very well find yourself not so confident anymore. And indeed, often this compiler-induced "stop and think" prevented you steaming ahead with a bug.
Now, the borrow checker is not perfect. I don't know how far away from "all but NP-complete cases" it is. My experience is that it's almost always right, and I've only had to put a seemingly needless "drop" statement to placate it. But they're working on it. A new one is coming: https://daily.dev/posts/rust-s-new-borrow-checker-is-coming-...
And once again this old blog post of mine comes to mind: https://blog.habets.se/2020/12/Bypassing-safety-check-for-ob...
In any case "by arranging your program in a way the compiler can verify" I think is not accurate, because the overlap between "correct" and "compiler can verify" is nearly complete, though yes the latter is a strict subset of the former. In other words I don't write Rust to make the compiler be able to verify it, but to make it correct. And nearly always that means the compiler can verify it too.
I've also had the converse experience, where I know full well that the structure I'm trying to impose is correct and quite efficient, but its part of the space that rust doesn't cover.
Rust is great. It's a noble attempt to bring a degree of correctness to a problem space that suffers from a great deal of slop. But to pretend that the model is complete, or that the design decisions that were made are perfect in every way, is just wrong. That the rust compiler and runtime can't support my construct isn't really an absolute value judgement on that idea in the first place. The rust compiler isn't really an oracle that tells you whether something is right or not in an arbitrary value system.
I'd say GC is always the fastest to free objects within the main code path. Literally zero instructions.
It was very clear that I was not talking about the active parts of the garbage collection.
Java pioneered this garbage collection stuff because you had cycles of references. You don't need to have cycles. WeakRef is a much better thing now. All you need is reference counting, and you don't need any garbage collection at all. When the reference count reaches 0, you destroy the object and free up its memory. It's far more predictable than GC, too.
And GC isn't "the fastest" to free objects, it has to walk a graph. The fastest is actually arena allocation and then just dropping the whole thing. But that's exactly what owning an entire container of objects can do. If you have a doubly linked list, for example, A[n] -> A[n+1] but also A[n+1] -> A[n] but neither of those should be a strong reference to prevent reclaiming. Instead, the container of that doubly linked list should be the one having a strong reference to its items.