511–520 of 822 posts
> +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.
This kind of frivolous nonsense disqualifies bun from ever being a serious option to me. I'm not building any kind of software used in a professional setting on 1M lines of unreviewed code.
Earlier quoted context omitted.
> For who? What you say is true for everyone who doesn't know Rust (before Zig), and not true for everyone else, same as it always is been, for every single FOSS project out there. Even if you are fluent in rust, it is going to require significant efforts to contribute to a new 1M LoC codebase. > Open source literally isn't about you, let people run their projects as they so wish, them making choices they think are b…
> Even if you are fluent in rust, it is going to require significant efforts to contribute to a new 1M LoC codebase. Of course, but this is true for any project or any language, can hardly be disrespectful of me to chose Clojure just because you don't happen to know it? That sounds crazy to me. > Contributors are the most valuable assets of an open source project You're talking about something else. Open source is li…
Well in this case Jarred and Bun can run their project their way, and since they're not made for me, they can just happen to be available to someone else like Claude code and they can stay in their happy read-only land.
> Don't spoil that by acting so entitled about how they should maintain and develop their project.
Are you sure you even understand what entitled means?
Earlier quoted context omitted.
Ignoring things like whether the Rust that was output could be deemed qualitatively good, whether the resulting line count is appropriate, how much the codebase was ready or primed for this kind of exercise going in, and so on, is it fair to say that a 622 line artefact created up front is a relatively small cost for a potential increase in consistency or quality of output when the output is ~1M LoC? It seems like th…
This is effectively a very expensive and resource-intensive machine translation. As such, there is no increase in consistency or quality of output.
Earlier quoted context omitted.
Google and Facebook workers just made a lot of cash and mostly made everyone's life harder by Leetcode and bad interview process, they didn't threaten and actively work to put millions of SE on the street.
> they didn't threaten and actively work to put millions of SE on the street Programmers in the 90s weren't less evil or had a stronger moral compass. They simply didn't have the opportunity to reduce the need for their fellow developers on a massive scale. They (we) would have, had we had the chance. They (we) did it to tons of other industries. And we collectively patted ourselves on the back, saying that automatio…
Nah. The fact that such opportunity wasn't available attracted a different sort of person.
Earlier quoted context omitted.
if half of your files in a million line codebase are unsafe that doesn't tell you much any more. Presumably the point of a Rust rewrite is that you actually make use of Rust's safety features in a coherent way. But given the whole "let AI rewrite this for me" stunt nature of this project that was not going to happen because that would require well, actual thinking and a re-design. So now you have Zig disguised as Rus…
And? This is absolutely the correct and standardized way to do mechanical rewrites: you do a rewrite that maps directly to the original source so you can rely on the original correctness guarantees and bug-for-bug compatibility and log issues, and then you go into the next phase where you begin to use idiomatic constructs. This is the same in COBOL-to-Java ports that have been done in banking and insurance for the pa…
it isn't, because those guys didn't think a naive 1-1 machine translation would give them the benefits of Java, which somehow the people involved in this rust rewriting seem to think they've already gained despite the virtually identical code.
If the whole point genuinely would have been to do a purely mechanical translation they could and should have written a transpiler, which would have had significantly higher correctness guarantees than this given that it'd be deterministic, but of course that would have defeated the PR purpose of this whole thing, which just looks like a marketing for Anthropic frankly
Earlier quoted context omitted.
> you can trust the models to write and review the code You definitely cannot!
You can trust them to flag some things during review that may or may not be relevant. But just like with human review and unit testing, you cannot guarantee the absence of bugs after an LLM code review. It's just another set of (virtual) eyeballs.
So the geniuses in the datacenter prefer to rewrite the full codebase in another language instead of maintaining and improving its own fork or contributing to make the current language better. Impressive to rewrite 1MLOC in a week yes, but this is more of a job of a million monkey programmers crammed in a datacenter than a bunch geniuses. And I would know, since I'm a monkey programmer who is in danger now... Or mayb…
About 9 days ago, Jarred wrote that it was far from certain that this would merge and that it was an overreaction. Ironic.
Model open source leadership. Imagine the meltdown if Linus says Linux kernel is not going to be rewritten and then one day wakes up and merges full machine-assisted rewrite in Rust.
This kind of frivolous nonsense disqualifies bun from ever being a serious option to me. I'm not building any kind of software used in a professional setting on 1M lines of unreviewed code.
Odd take. Bun was not option for me because or Zig. There was no security. Issue tracker has 3000 issues about segfaults. Now I might actually reconsider.