721–730 of 920 posts
Earlier quoted context omitted.
Fun fact, unsafe does not let you turn off the borrow checker in Rust: https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...
"Fun fact", it lets you largely circumvent the borrow checker by creating arbitrary lifetimes: https://news.ycombinator.com/item?id=48974824
Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people miss…
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…
That's just it, using Zig required more rigorous engineering than the Bun team were capable of.
Earlier quoted context omitted.
> True, but unsafe let's you conjure up any lifetime you want The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those: fn get_str (s: *const String) -> &'a str { unsafe { &*s } } https://doc.rust-lang.org/nomicon/unbounded-lifetimes.html > if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker Yo…
What's the point of using Rust in the first place when you disable the compiler feature that protects you the most?
As for the actual unloaded question, "What's the point of unsafe in Rust?" it is to contain and make it easier to identify sources of UB.
Earlier quoted context omitted.
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…
> You can just do that, and then Zig is really no less robust than Rust. That's just it, using Zig required more rigorous engineering than the Bun team were capable of.
Earlier quoted context omitted.
I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Earlier quoted context omitted.
If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like. A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free
I like your fair-mindedness but for folks who are anti-LLM-anything, your argument is not the point. Evidence: see the amount of nonsense in the postgres rewritten in Rust story - https://news.ycombinator.com/item?id=48841676 where there are two contradictory claims made: "postgres is so stable I will never trust a rewrite." "covering 100% of postgres regression suite doesn't guarantee you have replicated every behav…
I think this deserves a real response.
First, an analogy. I drive along a cliff with no guardrail. How do I not drive off the cliff? By knowing how to drive. Sometimes people mess up and drive off the cliff
In practice people are operating Postgres as a machine, more than an abstract spec. Minor releases exist, but the changes are made by people operating the machine and who have a fear of making the machine break.
There are also performance characteristics that are part of an informal spec. While you can definitely write regression tests on performance, theres loads of value in stability of internals because people who have problems look into the machine and discuss it.
The internals might change, but there’s a lot of friction. So… you can have a lot of informal knowledge about.
If everyone working on a software stack is bathing in this informal knowledge, then the decision making is based on that. Things like what is meant to be in a minor or major release is understood. And people make those judgement calls.
After all, even if you have regression tests if you’re making changes you’ll need to write new tests! How do you know your new tests are right? That the new behavior is right?
PG is the entire machine. Fortunately we have version numbers, migration strategies, etc. But “here’s a new binary that passes the test suite and… maybe changes everything not covered by tests maybe doesn’t”. Why bother suffering when there are totally reasonable gradual rewrite strategies?
And of course… every bug in the world… got through despite a test suite! What software out there doesn’t have bugs?
And if the behavioral difference in the rewrite does affect people… I guess that’s something right? “Oh this isn’t a bug because it wasn’t covered in regression tests” is not that tenable.
Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people miss…
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…
Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.
Earlier quoted context omitted.
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…
> You can just do that, and then Zig is really no less robust than Rust. That's just it, using Zig required more rigorous engineering than the Bun team were capable of.
Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people miss…
> 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.
Garbage collection is a method to make programming easier, not to make the resulting program better.
Earlier quoted context omitted.
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…
> You can just do that, and then Zig is really no less robust than Rust. That's just it, using Zig required more rigorous engineering than the Bun team were capable of.