Following the anthropic acquisition, now bun is being ported to rust, with code agent, of course
2 Likes
I did somehow expect this, after Ladybird ported its js engine and after they published their performance improvement on their own Zig fork. I have mixed feelings about that.
1 Like
I suspect this has something to do with Rust being around longer and being nicer to automate with AI Agents.
4 Likes
Shit happens
8 Likes
the nr 1 comment says:
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 and feels like and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.
30 Likes
Bun’s move from Zig to Rust may improve maintainability and ecosystem alignment, but it will likely expose a noticeable performance gap where the original Zig implementation still wins in critical paths.
As discussed on Hacker News, if AI makes large-scale code migration cheap, many projects could eventually shift (or shift back) to Zig for performance, making it less about which language you start with and more about which one you end up optimizing in.
2 Likes
Lets hope they remember to start from the Gnu core utils as the source, instead of uutils/coreutils
1 Like
It’s not really a rewrite, the author of the branch is testing Bun on Rust !
Jarred 4 hours ago | next
I work on Bun and this is my branchThis 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 it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.
2 Likes
I think its pretty reasonable to expect them to at least try to do that after Ladybird successfully rewrote part of JS engine in rust using llms.
2 Likes
Yeah I can’t blame him for trying but given that they like to move fast, I’d be surprised if they ended up switching to Rust. At work, I use both languages + C/C++, and the difference is noticeable, my zig/C project takes a few ms to recompile, the C++ and Rust code is taking multiple orders of magnitude more.
Plus I think a lot of Rust’s safety are overblown. In Zig you can get very close to the effective safety provided by Rust, by leveraging the type system, comptime, unit tests, fuzzing, Smith fuzzig, the sanitizers integrations, the DebugAllocator, same with Io.
Whereas in Rust it’s considered safe to just leak memory, and ressources into oblivion. Which i’m pretty sure constitute a serious attack vector. Now in practice Rust is indeed safer out of the box, that’s 100% undeniable but I’m not sure what they would gain from Rust, except maybe safer vide-coding ?
Also when safety is a true concern, most code is still written in some form of ISO C standard or in Ada spark, or something that comes with a toolchain that can be mathematically proven
3 Likes
Perhaps they should use their AIs to fork Rust and work on compile times!
(Kidding, I understand this is one person’s experiment.)
1 Like
I have nearly no knowledge about the speed implications of the methods you mentioned on Zig programs, so take this with a grain of salt, but you shouldn’t forget that Rust not only promises memory safety, it promises memory safety and near-C speed at the same time.
But yes, sometimes that’s not what you need, and in this case, you can rightfully call Rust’s safety mechanisms overblown and just use C/C++ or Zig.
Yes, I guess, but that still doesn’t rule out the other (for some people substantial) gains from using it. Besides that, the only ways of leaking memory in Rust are Box::leak (which is pretty explicit) and cyclic reference-counted pointers (Rc/Arc), which - as I hope - at least a bit experienced Rust devs know of, aside from their visibility in the code. I guess there are resources that could be leaked, but I don’t know which ones you mean, but Rust provides the Drop trait (which can be used like Zig’s defer I guess?) and ownership which can make allocating, internal transfer as well as deallocating resources less error-prone (see Rust’s File type).
That’s true, even though Rust is gaining a bit of traction, there’s a Rust compiler toolchain for safety-critical scenarios called Ferrocene which has some certificates (I don’t know what they’re worth though), but maybe some simpler languages are a better option for part of this stuff.
1 Like
fun fact: as far as I know, because the Rust compiler needs to do so much work (Rust is complex) and is therefore slower, it’s pretty optimized already (with work continuosly happening, even though the easy wins are now mostly gone, like incremental compilation)
I think we should start rewrite rust uutils in zig.
(I know its originally written in C)
But aside from the joke it can be a good zig community project.
2 Likes
the thing that gets my biscuit buttered is that people keep on praising Rust for it’s memory safety like it’s some kind of innovation that wasn’t there before, or like it’s the absolute only way to get memory safety, which is simply not true, and moreover is painful to hear. Because I’d have more trust in something like Tiggerbeetle’s db than any new Rust rewrite. Simply because they use Nasa’s rule of 10 and they have some insanely solid architecture and testing infrastructure.
And Rust as a lot more going for it, it’s super ergonomic, the community is vibrant, there’s always a library or a binding to some random stuff, there’s a lot of solid doc, the ecosystem is mature, and because of it’s super type system and borrow checker you can feel extremely confident to hack something in any project quickly without the fear and second guessing that you have when the project is in C++ and you fear you may have introduced 33bugs in a 2 line diff.
But people are adamant that the only thing Rust has is memory safety, and that memory safety is so important, when safety is so so so so so much more than just memory. Anyway sorry for being off topic but for the past few years every time i have to open linkedin there’s like 10 post about the same bloody thing.
7 Likes
I completely agree, I guess in the first few months of learning Rust I’d have made the same mistake of reducing it down to its memory safety, but luckily I do know that Rust is great because of all the other stuff you mentioned, at least for projects where it makes sense.
I’m so glad I don’t have LinkedIn, I feel sorry for you
1 Like
Just for testing I just went on linkedin and after scrolling 6 posts There’s yet again another Rust evangelist praising it for catching 80% of bugs at compile time and being memory safe, I fucking hate linkedin.
3 Likes
You mean the 70% Microsoft study?
2 Likes
yeahhh ahaha so true. Like really this platform is 10% of my colleagues doing cool stuff, 30% random people thanking Microsoft learning, 40% AI doomers in 6months there won’t be any jobs, 10% people praising Rust memory safety, 10 % people pretending like C++ is just one edition away of not being completely garbage.
6 Likes
The precise thing that Rust is rightfully praised for is memory safety with heap and without GC. And that was novel in production languages.
It’s easy to be memory safe, just add GC. It’s easy to avoid GC, just give users malloc and free. The tricky thing is doing both at the same time.
19 Likes