Zadness re bun

I feel some sadness about Bun moving on. I really, really did not enjoy Rust but maybe I was too hasty. Or is this more about the power of infinite Claude tokens? I could fire up a frontier model and port my various projects to idiomatic Rust in a few hours, would that be some kind of capitulation?

I understand Zig’s official position re: ai, as well as the recent discussions about llm usage and ziggit.dev specifically. It’s a heated topic, I totally get it and I do not judge. Somewhat out-of-step, though, esp in a news cycle where we have celebrity software engineers showing off great results with agents. How much should we care about such things? FYI I hit the 5h LLM limit most days and I feel like I’m doing both the quickest and best work of my career. I’m just a faceless person here in this forum but my software has been happily used by many millions of people.

I definitely think it would be a mistake to assert that the Bun rewrite “won’t work” somehow. It will work. It already works, mostly, and it will continue to work better as they throw more tokens at it.

What can we learn from this moment? Sorry for the rant, just expressing some feelings.

2 Likes

They are pondering a move for their own unique reasons, so I would not let it guide you one way or another


Congrats, that is hopefully a nice feeling for you

2 Likes

Since Bun was aquired by Anthropic this whole “rewrite” feels like ongoing advertisement for Anthropic’s LLMs. “Oh look now we can rewrite from Zig to Rust using our amazing technology!”

Sadly your post also feels like veiled Anthropic ad

How do you know that? Maybe they will hit some kind of problem they won’t be easily solvable? Maybe “throwing more tokens” can’t solve any class of problem?

12 Likes

I am new to this forum, but I was previously a volunteer moderator on a very active Discourse forum - now there was a thankless task! - and there we would merge related topics rather aggressively. What is the approach in these parts, as this could belong under the following topic instead?
https://ziggit.dev/t/bun-is-being-ported-from-zig-to-rust/

2 Likes

I think it’s valid for this to be a separate thread because, at the time of the previous thread, Jarred was still steadfastly denying that they are for real rewriting Bun in Rust. (A lesson to take what he says with a grain of salt.)

3 Likes

Talk is indeed cheap!

1 Like
  1. You can’t stop people from misusing your stuff
  2. You shouldn’t feel bad when they move on to misuse other people’s stuff
5 Likes

It’s probably the correct direction for them if they’re going all in on LLMs. Static guarantees are nice, especially so when you’re having LLMs write code for you. I’m still interested to see what an LLM conversion from zig to rust will end up looking like. I suspect it will be a mess, but I guess we’ll see.

1 Like

Going all the way down through the huge Hacker News thread on this topic, I loved this comment:

5 Likes

For sure.

The comment also says

It’s true corporate sponsors are a big help with language development, but not at the expense of conceptual integrity.

Which I also agree with

2 Likes

If AI can actually program really well (given enough tokens) then the language being used is irrelevant. It could program in assembly, or even some form of bytecode only it understands.

3 Likes

And yet Anthropic acquired Bun instead porting Claude Code away from JavaScript.

That being said, a language with a strict compiler can provide another level of fast feedback to an LLM running in a coding harness like Claude Code, so I wouldn’t be so quick to assume that the language used doesn’t matter.

4 Likes

10 Likes

I heard recently that one should learn from mistakes, but not from failures—the thinking is, if you didn’t screw up but things went wrong, changing course is not correct, even if the result is feeling bad.

It’s hard to see how Bun porting to Rust is anybody on this thread’s mistake, so I don’t think learning from this moment is wise.

6 Likes

uh, nothing TBH.

2 Likes

I have a simple perspective that maybe other people share but I haven’t seen it yet.

First there’s nothing to learn from this as this decision is entirely driven by the business context.

With Anthropic acquiring them and their strong push by leadership to use LLMs for everything it makes sense to rewrite their repo from Zig. Since Zig is the worst language for LLMs to generate code of, of course this is because zig is not stable yet, there’s not as much zig code comparatively yada yada.

The reason they chose Rust is also simple, if you want “standard” fast languages you would choose between C, C++ and Rust. From those 3 Rust has the best ecosystem, it has the best momentum and it IMO has the best LLM generated code because the borrow checker just prevents a lot of issues it would otherwise generate.

So it makes sense for an AI company to move out of Zig to Rust but does it make sense for the rest of us?

4 Likes

Ha! I appreciate this. Key to life, never lose your sense of humor…

I don’t believe in this take. LLM manipulate language. Language have been evolved for thousands of year to express complex ideas. LLM have read gazillion of all kind of text. That’s why they seem so smart is that they have a very good representation of concepts. Forcing them to write just assembly is really gutting them down.

Source: I was doing LLM before it was cool

1 Like

I think you nailed an excellent point here.

If CC is cobbled together with JavaScript .. then wouldn’t the sensible business AND engineering decision be to just rewrite the damn thing in something leaner and safer ? A relatively simple operation for a competent LLM you might think, if you agreed that LLMs were up to the job.

But no - let’s keep the JS hairball, then spend money we don’t have to purchase a JS runtime, then rewrite that runtime from one language to another so it can execute the exact same flakey-as-all-hell interpreted script.

Such a business decision would only make sense to an MBA

6 Likes

Regarding AI usage, I’ve had some success with generating Zig code with LLM, even if they favor what I call the “C++ style”:

const x = try allocator.alloc(u8, 2);
defer allocator.free(x);

But they are quite good for writing idiomatic Zig bindings to C library, which isn’t smth I enjoy doing, but also I hate writing C in Zig.

About memory leaks and segfault, I feel there are ways to improve things in Zig, and this won’t only help LLM but also teams with junior devs.