Problem is fanboys like YOU.

Sounds like responsible open source software development to me. That's what pre-releases are for.

It was always a risky proposition to use Zig, unless those persons were philosophically committed to help the language develop or die-hard fans. If not, them jumping to some other language, should not be so big of a surprise.

They may come to the conclusion that Zig is incapable of delivering on its promises or is deficient at satisfying their requirements.

I've really enjoyed Bun the past year or so, but the acquisition by Anthropic, Bun's codebase and documentation increasingly becoming AI slop, and this impulsive complete rewrite - all of it has ruined it for me and I'm actively moving off of Bun. I don't feel comfortable relying on it any longer.

[0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

https://news.ycombinator.com/item?id=48094745

Yes, it says that those people are spoiled rotten brats and the community needs to start calling it out to improve itself.

They aren't contributors. They aren't employees. They aren't paying customers. Bun is not a web standard. They benefit from a free product that they chose to opt into over the standard ecosystem.

And for some reason they feel they have a right to know every decision and experiment everyone who does work on that project is making apriori. And, God forbid, if somebody even so much as starts working on something in an off branch that doesn't affect them in any way without getting their approval, they're going throw an absolute hissy fit.

And to criticize the person actually doing their job for feeling slighted that hundreds of people have verbally accosted them over it, because one feels they don't recognize an "implied responsibility" to those folk, is silly.

I'll also push back, though. The majority of the community doesn't seem to be doing anything.

What I said is that "they know that LLMs are not the right tool for this" is not the answer, as CC is already vibecoded so it'd be very weird to believe you can't vibecode a port of CC.

The actual answer is, of course, the whole discussion is just making a hill out of a mole. Bun is not committed to a Rust rewriting, vibed or not.

As for social structures in creating software... the social structures around creating software shouldn't be a goal... software serves to scratch an itch or serve a purpose... and that purpose can even be social or entertainment... but the creation of the software itself doesn't need to serve any other purpose and if it can be done via automation, or partly automation, all the better.

As to going into hunter/gatherer mode... have you tried? My brother isn't even online and regularly hunts and fishes... so did my dad. They weren't wealthy people and still managed to get by. A lot of people do and did through history... because most people wouldn't be willing to do it... I realize that some countries and regions are more populated... but there's plenty of space in the US to achieve this kind of lifestyle.

For that matter, there's absolutely very little standing in your way if YOU want to take on the goals of creating cleaner energy or pairing with "responsible" data centers.

But I really think you're just virtue signaling and grand standing in order to try to shame others because you feel guilty for things you aren't actually responsible for.

Who is to say that it’s wrong?

Has anyone made any cross language benchmarks for LLMs? I wonder if rust's conceptual complexity makes it harder for LLMs to write? If all you care about is working software, which language is best for LLMs? Python, because there's more example code? Go or Java, because they're simpler languages? Ruby because its terse? Rust because of the compiler? I'd love to see a comparison!

Sorry if I’m being pedantic, but I’m not aware of Bun having made any statements about AI assisted coding before.

I don't think the tone was the problem.

--------

[1] And align with the project's direction. This part is of course much more subjective so could very easily be an honest misunderstanding of the situation.

Linking is also slow, and the extreme amounts of metadata produced for LLVM almost serves as a benchmark for LLVM's throughput, but that's all in an effort to produce faster, better binaries in the end.

On godbolt.org, Hello World compiles and runs in about 250ms. Zig's Hello World compiles and runs in 600ms. Of course Zig is still an unfinished language so optimisations like these are probably hardly a priority, but when it comes to lines of code per second, the difference isn't as big as people make it out to be.

What will make the most difference is how many crates the rewrite will pull in. The PORTING.md file specifies "No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`" for the second phase, which should definitely get rid of the excessive compile time many people associate with Rust projects.

but also telling a LLM to do a line-by-line translation and giving it a file _is guaranteed to never truly be a line-by-line translation_ due to how LLMs work. But thats fine you don't tell it to do line-by-line to actually make it work line by line but to try to "convince" it to not do any of the things which are the opposite (like moving things largely around, completely rewriting components based on it "guessing" what it is supposed to do etc.). Or in other words it makes the result more likely to be behavior (incl. logic bug) compatible even through it doesn't do line-by-line. And that then allow you to fuzz the behavior for discrepancies in the initial step before doing any larger refactoring which may include bug fixes.

Through tbh. I would prefer if any zip -> terrible rust part where done with a deterministic, reproducible, debug-able program instead of a LLM. The LLM then can be used to support incremental refactoring. But the initial "bad" transpilation is so much code that using an LLM there seems like an horror story, wrt. subtle hallucinations and similarr.

But none of these properties are what let you perform a successful port. The port is going to rely entirely on oracle testing.

https://xkcd.com/286/

Especially for memory management the right and wrong abstractions in Rust can lead to a factor of 5 or 10 extra amount of difficulty. The right memory management abstraction and your code can be a straight line port (or even cleaner!), the wrong one and you're going to just be spending a lot of tokens to have a machine spin around in circles trying to untie itself

GC'd languages don't have this problem, though obviously you can still generate stupid amount of pain for yourself by doing something wrong

You can delete your social media accounts and just keep working on what you want to, for one. Nobody is forcing you to use social media.

So the practical delta is around half an hour to three quarters of an hour per day, or multiple hours per week. That directly affects flow state and experimentation speed. over the span of a month that's 2 full days worth of work waiting for the compiler. Or if you take my company's evaluation of the average engineer's hour cost it's roughly 2550 per month or almost 30k per year, obviously it's a bit exaggerated, you don't spend a full year refactoring and working like that, but even a tenth of that is still a big lump of money if you scale it to a few teams.

Now it needs to be taken with a huge pinch of salts because Rust provides other benefits that offsets the fact that it's painfully slow to compile, but still worth noting

So it's definitely a faster feedback loop and honestly completely bearable, but it's not 200ms.

Here, I just did a quick test with claude.

1. "make a simple tcp echo server that uses rust"

compiles and runs - took a few seconds to generate.

2. "make a simple tcp echo server that uses zig"

result: compile error, took literal minutes of spinning and thinking to generate

response: "ziglang.org isn't in the allowed domains. Let me check if there's another way, or just verify the code compiles conceptually and present it clean."

/opt/homebrew/Cellar/zig/0.15.2/lib/zig/std/Io/Writer.zig:1200:9: error: ambiguous format string; specify {f} to call format method, or {any} to skip it @compileError("ambiguous format string; specify {f} to call format method, or {any} to skip it"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3. "make a simple tcp echo server that uses zig 0.16"

result: compile error:

zig build-exe main.zig main.zig:30:21: error: no field named 'io' in struct 'process.Init.Minimal' const io = init.io; ^~

4. "make a simple tcp echo server that uses zig 0.15"

result: compile error

zig build-exe main.zig /nix/store/as1zlvrrwwh69ii56xg6yd7f6xyjx8mv-zig-0.15.2/lib/std/Io/Writer.zig:1200:9: error: ambiguous format string; specify {f} to call format method, or {any} to skip it @compileError("ambiguous format string; specify {f} to call format method, or {any} to skip it");

Rust took seconds and just works. Zig examples took minutes and don't work out of the box. The DX & velocity isn't even close.

What you are talking about used to be a pain point, but is now pretty much gone.

Rust can be a real superpower for AI-assisted dev work, because the compiler outputs very good errors, and the type system catches most safety bugs.

We are all software engineers on here (or at least many of us are), we all know how project management and prioritisation works right? We can't work on everything all at once.

So the next step will be that bun will be directly re-written from scratch at every iteration, the repository will only contains the specs for the LLMs.

Caching locally the generated code will be authorized for some transition period, but as it’s obviously very dangerous to let people tweak what exactly computers are doing, forbidding such a practice using safe secure boot mandatory mode is already planed. Only nazi pedophiles would do otherwise anyway, thus the enactment of the companion law is an obvious go to.

[1] https://news.ycombinator.com/item?id=47997947

with superpowers, i see a lot of specs -> impl plan -> execute plan

But pointing your AI at an entire codebase to transpile pretty much entirely by itself? Yeah vibe coding is a fitting term.

Even if you wrote it a small essay on how to Rust. That improves the situation but doesn't change the core autonomy/hope of the task.

> (programming, neologism) A method of programming in which a developer generates code by repeatedly prompting a large language model.

https://en.wiktionary.org/wiki/vibe_coding

As much as I find the word "vibe" generally annoying (in all contexts), I actually really like "vibe coding" as "LLM did everything and I didn't even look at it". It's a succinct, useful way to describe that mode of doing things. Diluting it down to "LLM-assisted coding" makes it useless.

  The goal of Phase A is a **draft** `.rs` next to the `.zig`
  that captures the logic faithfully — it does **not** need to compile. Phase B
  makes it compile crate-by-crate.

Programming languages, in contrast, are constructed and vary much more in their designs. They are formal languages, making them closer to math than spoken language. LLMs being able to describe concepts more thoroughly and precisely through more expressive semantics obviously makes some languages more suitable than others.

The type system of a language is just one aspect of it that allows the language to provide guarantees to the LLM (and the user) about correctness of the code it's writing.

I am not speaking about specific types in specific programs. I am talking about the ability to describe complex constraints that LLMs (and humans) end up using to make writing correct code easier and more productive. Some programming languages absolutely are more effective at this than others, and that's always been true even before LLMs.

LLMs promote a decoupling of mental models and the actual codebase.

As much as some may want to believe, just reviewing what the LLM outputs is not equivalent to thinking about implementation details, motivations, exactly how and why things are, and how and why they work the way they do, and then writing it yourself. The process itself is what instills that knowledge in you.

Sucks for people who were invested in contributing to Bun and don't like working with AI tools to be sure, but I think the writing was on the wall for them pretty much immediately post-acquisition. You must admit, it's hard to predict that 100% of source lines will be written by AI if you're not walking the walk!

(Though I don't know if this particular patch series would get accepted on its own merits.)

Couldn't you say exactly the same about bun?

Both appear to be[1][2]. FreeBSD doesn't have a formal policy yet, but they appear to be leaning towards admitting some degree of LLM contribution.

[1]: https://docs.kernel.org/process/coding-assistants.html

[2]: https://forums.freebsd.org/threads/will-freebsd-adopt-a-no-a...

PostgreSQL, a famously slow and rock solid project, accepts LLM-based contributions. But they are held to the same high standard, if you cannot explain the patch you submitted it likely get rejected.

Zig is famous for taking the former path! Anyone using Zig for a few years knows every release breaks things, and they are still making huge changes which I would classify as “moving fast”, like the recent IO changes!

You can be against a particular technology without being "anti-technology".

See DRM/surveillance/bad self driving implementations.

Just because a thing exists doesn’t mean you have to use it for everything. You don’t use asbestos blanket? Why are you so against asbestos?

Among them:

- much easier to iterate on (due to the language being simpler and compilation much faster)

- native C/C++ interops (Zig can compile C and C++ and mix it with Zig) which is crucial for a node-replacement runtime that runs an open source JS engine

- fewer dependencies and trivial static linking

I guess that now that they've been acquired by Anthropic there's this combination of having both in-house Rust talent, AI which does better on Rust, and the funding and resources necessary to undertake such a migration.

So the difference is not in writing new stuff but in maintaining the existing codebase. Rust's rigidity makes it potentially harder to break stuff compared to Zig's general flexibility. As a project grows and matures, different types of contributors naturally come in and it's unreasonable to expect everyone to learn about historical footguns that may have accumulated.

I think there are even longer term plays that Anthropic should be looking at, in this space, but it seems like they've decided rust is the right thing, so fair play. I would be (am!) thinking about making an LLM optimized high level language that you can generate / train on intensively because you control the language spec.

something JS-adjacent could certainly be more known than an obscure language but are that many people using drop-in node replacements?

The same applies to vibe coding: the best "vibe coder" will paradoxically be the person with enough knowledge and curiosity to understand programming, how computer works and the subject at hand; one that could write the whole thing from scratch so they have enough judgement to review generated code.

Of course the vast majority will be mediocre vibe coders, and even worse programmers; at least that's the direction we're going.

How is it an incorrect interpretation? Jared is indeed pitching/suggesting/predicting that human contribution will not be allowed in the near future, i.e. banned.

High-level languages can certainly yield inefficient code when compiled, or maybe different code among different compilers, but they're always meant to allow their users to know exactly what to expect from what they put together in their programs. I've always considered this a hard fact, I simply cannot wrap my head around working in a way that forces me to abandon this basic assumption.

So it is not, by your own admission, "exactly, literally the same".