Is this really the state of "software engineering" today? :/
Rewrite Bun in Rust has been merged
521–530 of 822 posts
Re: Rewrite Bun in Rust has been merged
#522What does this mean for bun add-ons like opencode's opentui? Did FFI also somehow get ported or will that have to be updated? https://github.com/anomalyco/opentui
Re: Rewrite Bun in Rust has been merged
#523We should be greatful for this. This is the one public case study on how large-scale llm-driven code generation actually works out. With node and deno there are reasonable alternatives for everyone who don't want to use bun anymore.
Is it, really? I can't imagine how much money in tokens was spent to get something like this + Jarred's and the teams salaries to review/manage this.
Re: Rewrite Bun in Rust has been merged
#524Earlier quoted context omitted.
"We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely."
People conflate “high chance of X” with “X will happen” all the time. See elections, for example.
Re: Rewrite Bun in Rust has been merged
#525Why would you replace an existing codebase like this instead of forking the repo instead and then making the changes?
Git has this branch concept. It's being used correctly here, IMHO.
Re: Rewrite Bun in Rust has been merged
#526Earlier quoted context omitted.
> 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? Nobody said that the problem is not knowing rust. The problem is changing the whole stack of a project overnight. This requires significant effort to get familiar with, even if a contributor have all the experience in the world with the new stack. > Don't mix conc…
I think most maintainers would rather you not contribute to their project if your contribution comes with the idea in your head that you're now a stakeholder who has some share in the project's technical direction.
If you want to maintain sole ownership of something that >800 people contributed to, that reflects on you. People will judge you. Most maintainers would feel obligated to concede some control. But LLMs have intentionally aimed to devalue programming, so this transition is totally consistent with the new ownership. And it may be wildly successful, because they've got an unlimited supply of tokens for the foreseeable future.
But I'd say the opposite: Most maintainers would feel blessed to have a lot of contributors so invested that they felt a need to have a say in the direction of the project.
Re: Rewrite Bun in Rust has been merged
#527Earlier quoted context omitted.
How is that different (in this sense) to any "slower" rewrites or other significant changes?
The difference is exactly the speed. Slowly transitioning from one thing to another gives the opportunity to contributors to get involved in the process.
Just because some set of hypothetical contributors want a slow-moving target and the maintainers want to be on Rust now, I'm supposed to be mad at the maintainers? Why?
Re: Rewrite Bun in Rust has been merged
#528Earlier 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…
Re: Rewrite Bun in Rust has been merged
#529Earlier quoted context omitted.
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…
>This is the same in COBOL-to-Java ports 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, whi…
If it were just a marketing stunt you wouldn't have a fraction of a percent of the test suite passing with the remaining bugs being realistically very fixable, and everything written in languages with type systems that give far more guarantees than what COBOL is possible.
You're being extremely negative about this whole endeavour without looking at the evidence that this effort is going far more smoothly than expected, and maps with many people's experience with using LLMs for tasks like these.
Re: Rewrite Bun in Rust has been merged
#530Earlier quoted context omitted.
It's really simple. 9 days ago this is how the migration was described: > I work on Bun and this is my branch > This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. > I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to…
Stop thinking about '9 days' like it means the same thing in an era where machines can generate thousands of lines of code in a few hours. There is no way a human rewrite like this wouldn't be roughly at the same stage with a 9 day delta. In that case, some of these accusations would be reasonable to make. But that is not the case here.