Presumably the biggest loser in all this is Zig, I only know of the language because of Bun. But the timescale still gives me pause… just because AI lets us convert a codebase in 6 days doesn’t mean it’s wise. There are surely a lot of downstream implications! It’s always felt a little like Bun is making up a plan as it goes along (and maybe that’s unfair), this seems to underline the point.
Zig is a great low-level language. It's much better than C, while not being so much larger as e.g. Rust or C++. AFAICT Zig does well in embedded development, and should continue to do so. Note that Zig is not even 1.0 yet.
Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
71–80 of 754 posts
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#72Earlier quoted context omitted.
Looks like he did the maintainability performance and test suite checks and made his decision :)
Honestly, I fully support the rewrite to Rust, but he should have just owned this from the start. I'm sure he knew in the back of his mind how dedicated he was to that branch as he had already spent the equivalent of thousands of dollars in tokens by that point.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#73I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better
Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?
While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases.
C++ already prevents many of those scenarios, at least for those folks that don't use it as a plain Better C, and actually make use of the standard library in hardned mode. When not, naturally is as bad as C.
Also to note that the tools that Zig offers to prevent that, are also available in C and C++, but people have to actually use them, e.g. I was using Purify back in 2000's.
Then there is the whole point that Zig is not yet 1.0, and who knows what will still change until then.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#74From 4 days ago: https://news.ycombinator.com/item?id=48019226 > 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 get i…
The AI companies and their associates are beginning to surpass that level of denials and lies.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#75Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow.
Also want to note that writing the code using LLM doesn't remove the need to have a vision for the design and tradeoffs you make as you build a project. So Jarred and his team are the right kind of people to be able to leverage LLMs to write huge amounts of code.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#76Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#77Earlier quoted context omitted.
Honestly, I fully support the rewrite to Rust, but he should have just owned this from the start. I'm sure he knew in the back of his mind how dedicated he was to that branch as he had already spent the equivalent of thousands of dollars in tokens by that point.
Bun was VC funded and acquired by Anthropic. He's spending company money, not his own money.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#78Earlier quoted context omitted.
Honestly, I fully support the rewrite to Rust, but he should have just owned this from the start. I'm sure he knew in the back of his mind how dedicated he was to that branch as he had already spent the equivalent of thousands of dollars in tokens by that point.
Announcing the decision a week earlier wouldn't help anyone. Maybe he expected it to work (though he didn't say that), but there's no reason to make a final call before seeing that it did work.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#79Earlier quoted context omitted.
Bun was VC funded and acquired by Anthropic. He's spending company money, not his own money.
That's why I said "the equivalent of". Additionally, time and cognitive effort are not free. The work spent on this branch was work that was not spent on other branches. Does that make sense?
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#80Earlier quoted context omitted.
> Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.
It's not hallucination, it's a basic extrapolation. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" is the same statement as "using Zig resulted in Bun having an extremely high amount of crashes/memory bugs". It is then natural to ask whether their position is "using Zig results in an extremely high amount of crashes/bugs" in general.