Comment by BearOso
8 days ago
> Rust does this automatically.
A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.
You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.
Ownership is automatic. You don't have to explicitly drop things when they go out of scope. (although the responsibility for that is split between the compiler and the library code).
Lifetimes are not automatic, but also have no effect on memory allocation. They are purely a static analysis path and you can make a functioning rust compiler that completely ignores lifetimes.
> You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated. Ownership is
That's a semantic distinction which does not matter in the point OP is making. And contrasting rust static approach to general GC.
It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?
Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types).
Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.
True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.
14 replies →
Yeah but if you have tried writing unsafe Rust, you notice that you are obligating yourself to write code that is much stricter than C.
E.g. in C you can write code and say "don't call it outside the situation that this function was written for" and then blame [0] future users of the API.
In Rust you need to actually make sure that your code works, i.e. your safe interface is not unsafe.
[0] The blame game is not a technical solution to a technical problem...
Borrow-checking the dereference of a stale pointer won't be worth much, though.
3 replies →
You don't need to rehash the same old argument. Runtime memory management is forgiving but also inferior in a lot of ways to compiled stuff that works with memory deterministically.
Garbage collection is a method to make programming easier, not to make the resulting program better.