Comment by vitaminCPP
19 hours ago
> +1009257 -4024
Bun is now over 1M lines of Rust code.
This is approaching the size of the Rust compiler itself; except that BunJs is mostly a JavaScript interpreter wrapper + a reimplementation of the NodeJS library (Rust STD wrapper).
I think BunJS is becoming the canary for software complexity management in the LLM era.
> mostly a JavaScript interpreter wrapper
Not accurate. Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code.
Don't forget the image rendering library!
Now that Bun can leverage Rust do you think some of this code will get disaggregated? Eg, Bun could use swc crates
It wouldn't have been that hard to do that from Zig if they'd wanted to. They don't, because they want to do everything themselves so that it works exactly the way they want (except the core JS engine for which this is infeasible—though even that has custom patches). After all, there are already plenty of libraries on npm for those other parts of the stack and they do work in Bun.
[dead]
Bun is not a JavaScript interpreter, it's "only" a reimplementation of the NodeJS library + various other libraries. Bun uses JavaScriptCore as its JS engine. So Bun itself does (or at least should do) no JavaScript parsing, interpreting or JITing.
EDIT: I misread, sorry! You said "JavaScript interpreter wrapper", which is correct.
No, it does parsing and a bunch more. The Bun founder says it best in this comment:
"Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code."
https://news.ycombinator.com/item?id=48140921
Bun is now almost twice the size of JavaScriptCore, too, by linecount after this.
This is the 'world class' engineering that Jarred claims he can't hire Americans to do, by the way https://x.com/jarredsumner/status/1969751721737077247. This company is parasitic to its literal (javascript) core.
That’s what they said - “JavaScript interpreter wrapper”.
You're right, sorry! I completely missed the word "wrapper" somehow.
1 reply →
I'm not sure if it's just the leading '+' or if there are other factors for phone number detection on iOS, but on mobile the line count changes are underlined and I can tap it to start a call, which, if it is because of the diff size, is something I find pretty amusing.
Apple has had a feature called Apple Data Detectors since the 90's that looks for different patterns in text and allows you to perform actions on them.
So if the text includes a phone number, email address, flight number, package tracking number, street address or other pattern in the data it is underlined and allows you to perform one or more actions.
The patterns it looks for and actions it takes are extensible by developers.
If you don't care for it, you can turn it off.
> +1009257 -4024
I think it just lines up with the typical size of a phone number and the '-' is interpreted as a separator. Just a simple regex probably.
Maybe it's the phone number of the vibe coding police?
91�
The leading “+” is not needed. Numbers with seven digits are automatically hyperlinked (possibly depends on locale).
123456
1234567
12345678
Interesting. Where I am, both six and eight digit phone numbers are valid, but seven digit ones are not, and yet that's the only one that gets linked for me. US assumptions bleeding through, I assume.
Interestingly, the entire line gets formatted once it reaches seven digits, +lines and -lines both, so I guess the -lines is just interpreted as a dash. But your eight digit string doesn't. Perhaps it's not interesting, though I've never really given it a second thought before.
1 reply →
The Bun codebase had a similar number of lines of code before the rewrite.
There's nothing unusual about a rewrite coming in with a similar LOC number.
I think the unusual thing is that it was written in a week. I highly doubt that they read and understood all 1M lines. But if it works and people use it, what does that mean for software? Should we still care about the code that’s written? Should we even look? I’ve always thought so, but maybe I’m just biased.
I think we should care way more about what the validation story is of code. The obvious question does it all work? I'm happy to not look at any code if we have good ways to validate what is there. The other thing I care about is the architectural structure of the code. Given its a port I don't think that would have changed.
I was going to comment this same thing.
I don't know enough about what Bun does... But Rust is so insanely complicated, it's hard for me to wrap my head around how Bun is equally complictated.
Complicated things can often be expressed very succinctly - the hard part is in understanding why the short program does what it is supposed to.
Simple things often take a lot of space, simply because there's a lot of similar but different simple things that each need to be written down.
Lines of code just isn't a good measure of "complicated".
They are complicated in different ways. The rust compiler doesn’t include redis, Postgres, and S3 clients for instance.
If anything, it's a little surprising that the Rust code isn't significantly larger because I tend to think of Rust as requiring somewhat more boilerplate than JS.
The code was using Zig before, not JS.
2 replies →
Not to mention how trigger happy LLMs can be when it comes to being overly verbose and adding unnecessary bits even with explicit direction not to do so.
1MLOC for a JavaScriptCore wrapper is a great example of what agents are capable of.
Code is cheap. Only the quality and maintenance is interesting. Those will be seen later on.
I would not be surprised if the next major step for them is to audit the code and trim the fat.
> I think BunJS is becoming the canary for software complexity management in the LLM era.
Yeah, Cursor did the same thing, bragging about how many lines of code they managed to produce for a semi-working browser, completely missing the idea where less code is better, not the other way around.
I think their point was that the project is complex, with the implicit assumption that the complexity is to a large degree inherent.
Even if it's mostly accidental, and the code is overengineered slop (which it is), the system being able to decompose a problem and deliver something is impressive in terms of stability: it wasn't sucked into rewriting everything from scratch every time it would run into issues, it didn't have infinite subagent recursion with a one-agent-per-line type workflow, etc.
[dead]
you can easy fix this by MAKE NO MISTAKES, DO NOT HALLUCINATE under your zig2rust.md skill agent flow /s