It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this appears to have been a massive success, which is absolutely remarkable.
Rewriting Bun in Rust
421–430 of 560 posts
Re: Rewriting Bun in Rust
#422I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…
Ehh, I think this take needs a grain of salt. There's a few significant facts here: - They had an existing functional Zig implementation - They had an existing test suite for the Zip implementation - They had a separate JavaScript compliance test suite with ~ 1 million tests - The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architec…
Every single SaaS app will be completely rewritten in the next couple years. Fair warning. If you aren't on that train you won't have a job.
Re: Rewriting Bun in Rust
#423To add more context around lifetime errors and TigerBeetle's particular style guide: >Many projects opt to answer these kinds of questions through a style guide. TigerBeetle's TigerStyle is an example in Zig and Google's 31,000 word C++ style guide is another. The challenge with style guides is enforcement. TigerStyle[1] is a bit more than just a style guide. The key rule for this discussion, uplifted straight from o…
By all accounts, TigerBeetle has been a tremendous success, congratulations! My understanding is that it has a deliberately fixed scope, which makes me wonder: how applicable would TigerStyle be in more general-purpose applications? If the system needs to, say, ingest arbitrary JSON documents ranging from 100 bytes to 100 GB, how would TigerStyle fare?
What matklad said as a footnote deserves a little more attention!
A huge benefit is having to think and be explicit about the limits up front. To take your example of arbitrary sized JSON and flip it around: how would you do it normally?
Maybe, you'd allocate a buffer to hold your entire object when it comes in - but now you'll end up crashing when you get a large document that exceeds your available memory.
Maybe you can do things in a fixed amount of memory, using streaming or chunking - which would be pretty simple to turn to static allocation!
Static allocation forces understanding of those limits upfront.
Re: Rewriting Bun in Rust
#424To add more context around lifetime errors and TigerBeetle's particular style guide: >Many projects opt to answer these kinds of questions through a style guide. TigerBeetle's TigerStyle is an example in Zig and Google's 31,000 word C++ style guide is another. The challenge with style guides is enforcement. TigerStyle[1] is a bit more than just a style guide. The key rule for this discussion, uplifted straight from o…
By all accounts, TigerBeetle has been a tremendous success, congratulations! My understanding is that it has a deliberately fixed scope, which makes me wonder: how applicable would TigerStyle be in more general-purpose applications? If the system needs to, say, ingest arbitrary JSON documents ranging from 100 bytes to 100 GB, how would TigerStyle fare?
Some thoughts on this here: https://matklad.github.io/2025/12/23/static-allocation-compi...
Re: Rewriting Bun in Rust
#425Earlier quoted context omitted.
> Why do you think it is not slow? The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means. > I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable f…
Compiling my C code with gcc happens in a single eye blink. Changing the format to .cpp and compiling with g++ takes 5 eye blinks. I've never used rust and I can't imagine blinking more than 6 times while waiting for my code to compile.
And you wouldn't need to, because the Rust compiler is "slow" relative to compilers like Go. Relative to Clang and g++, the Rust compiler is fast.
Re: Rewriting Bun in Rust
#426This makes me sad :( I've always really liked Zig, and Bun was pretty much the only big thing I could point at and say "that was done in Zig"
Re: Rewriting Bun in Rust
#427Earlier quoted context omitted.
yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them. experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so…
> gpt3->4o->sonnet4->opus4.6->fable While there are a lot of resources being poured into improving and integrating tooling and use cases and increasing model sizes, the leap between the models you notes are not as much as you think it is. It's the same tech that's scalable to a certain limit of diminishing return. It's a recurrent pattern in technology. > yes, I assume we will have the 'replicator' from Star Trek, an…
> It's the same tech that's scalable to a certain limit of diminishing return.
of course, my point was that gpt3->4o was smaller jump than opus 4.6->fable
Re: Rewriting Bun in Rust
#428Earlier quoted context omitted.
the elastic demand will be consumed by ai jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers. as programmers are not the resource, the program is the resource, programmers were the means of production of said resource. stated differently: in a world where you dont need programmers to make programs, ther…
You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs. A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in th…
Yes ai + programmer are the resource.
Ai won't work on it's own until we get agi.
Re: Rewriting Bun in Rust
#429It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…
Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world.
PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future.
AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.
Assessed from the perspective of "technology in a vacuum", of course. it's a success. He did the thing that transformed the thing from one kind of stuff to another kind of stuff. It still does all the things it did before, and in many cases with better stats than it did before.
Assessed from the human angle, and especially the angle of Bun as a community, I would bet money that this rewrite -- executed by nobody for nobody, built and maintained by machines, maintainable only by machines -- has killed the entire project.
Maintainable only by machines, because anybody with any knowledge, experience, or investment into Bun as a platform, or who contributed patches themselves, or whoever had a question about how it works and went "Hmm, I'm gonna go into the codebase and take a look at how that happens", they all got slapped in the face and summarily kicked out of the tent with the rewrite.
Re: Rewriting Bun in Rust
#430This makes me sad :( I've always really liked Zig, and Bun was pretty much the only big thing I could point at and say "that was done in Zig"
TigerBeetle has you covered then.