I love Bun & Zig and this feels a bit like my parent are getting a divorce. I thought it was a bit strange that Bun did not sponsor the Zig foundation while others much smaller companies have.
[deleted]
Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
561–570 of 754 posts
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#562I'm a full time Zig developer, and I see this as an absolute win. I know Jarred has said in the past he feels Zig makes him more productive, but I also think it's fair to say Bun was programmed in a way that's quite cavalier towards buffer overruns. I think Jarred and the Oven team will have significantly better luck with Rust. Some commenters have remarked they only heard of Zig because of Bun, therefore this is bad…
I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none.
Even now:
bun (zig) [1] 119 open / 885 closed
deno (rust) [2] 0 open / 1 closed
I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job.
[1] https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
[2] https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#563Earlier quoted context omitted.
When something is expensive specifically because a country is poor and everything is harder to buy, that expense isn't making inequality worse.
I am talking about have nots at a nation scale here. At level of British empire.
I'm not sure what that means. Every country has electricity and any country can get GPUs if it wants them.
(And the profit from selling GPUs isn't haves versus have nots, it's a couple companies versus the entire world.)
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#564Earlier quoted context omitted.
The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable
> The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance . I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you mi…
> That code is also hyper-optimized for performance. I sincerely doubt you are going to match the performance easily with any random rewrite.
Hyper optimized for '70s era fortran not gonna be all that optimized on modern CPUs.
I bet that just compiler optimizations that LLVM could do with clean code gonna be faster
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#5656 days of work to do this. Even if it doesn't end up becoming meaningful, it shows just how tokens and work done will be linked now and in the future. It's going to be hard to compete with someone or a company that has more compute. They will just be able to do things you can't.
There are not many companies that live off taking full test suite made over decades and just generating code off it.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#566Presumably 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.
For most use cases I can’t imagine why you’d make the effort to move off C and not just go all the way to Rust.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#567Earlier quoted context omitted.
Zig doesn't even have RAII...
which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.
Constructors and destructors are also just function calls in C++
And you can't forget to type defer
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#568Has anybody thought through the legal aspects of this, regarding code ownership? As far as I understand the situation in the US (sorry, no idea where he is located), output from LLMs, once published, is essentially in the Public Domain, since there isn't any human who owns it. However, in some sense, this is also a machine-assisted translation from one computer language into another, so one could argue that the owner…
AI rewrite one of the Microsoft source code leaks to Rust and publish it as open source on GitHub. We will soon find out what the answer is.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#569Earlier quoted context omitted.
Wow, amazing work. Pretty impressive that it is faster than the Go version already.
Thank you! It's much faster in single file benchmarks (3 to 5x) https://tsz.dev/benchmarks/micro I have optimizations planned for large projects that I'm still flushing out.
Regarding the architecture documentation you have up on tsz.dev, one thing that jumped out to me was the use of the per node typed side pools. A semi-recent talk[0] had benchmarked this and found it to be a deoptimisation: he couldn't explain it, but an audience member suggested it is likely because an AST is not generally very type-homogenous in its visit order. After a CallExpr node the next node to visit is probably not a CallExpr but more probably an Identifier etc, so storing the node "extra data" in separate pools makes them more likely to be cold in cache rather than hot.
In Nova JavaScript engine[1] I've done exactly as you've done and split objects into typed side pools (I call them "(typed) heap vectors") but in a JavaScript engine my _hypothesis_ is that the visitation patterns are much more amenable to this: an Array, Set, or Map is more likely to be homogeneous than heterogeneous, and therefore a loop over the contents is likely going to hit the same side pool for each entry.
[0]: https://www.youtube.com/watch?v=s_1OG9GwyOw [1]: https://trynova.dev/