[legerdemain]

From 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 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.

[Jarred]

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

[gobdovan]

If this experiment ends up resulting in a real migration path, I think that would be completely awesome. Maybe it means we have a chance to revive older projects such as ngspice [0], but with modern affordances and better safety properties.

From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair?

[0] https://ngspice.sourceforge.io/

[therealpygon]

I hear your suggestion without feeling the need to remark the far too common Linux/Deveoper response of “but if you just do all this other stuff and run it this special way and install 15 dependencies and compile XYZ lib from source then clearly it works fine and you’re mistaken”.

That’s exactly the type of thing that is needed is to optimize projects for modern compatibility, portability and safety when other modernization efforts or forks don’t exist.

That said, I suspect this rewrite went so quickly and so optimally because it had the benefit of (effectively) 100% test coverage already in place in a really well defined system. Most open source project spawn from efforts of a single developer who frequently never waste time writing tests for a little side project. Later as it grows, they rarely stop and go back to implement testing. So if you’re truly working with an old dead project, there is a really good chance there are zero tests to be found. That is far more difficult to reach the same completeness unless the goal is simply to port all of those same problems to a new language and hope type safety fixes them.

(Not specific to ngspice, just mean generally.)

[eternal_braid]

You can instruct an LLM to improve the test coverage.

[pryelluw]

You are absolutely correct!

[tracker1]

I've found Rust to be pretty enjoyable to work with in terms of Agent assisted development. Easier still if you have something you're trying to port or recreate in Rust for various reasons. There are definitely some rougher edges around a few things as you get more general purpose in terms of app targets. Some of the DB engines can use some work or may be missing interfaces you use in other supported languages/platforms... There's a somewhat limited set of UI options, and no clear winner.

Lifetimes can get pretty hard in very complex code bases... even if other aspects of burrow checking may be more common, this is where I've had and seen the biggest gaps in understanding in practice. That said, you can usually do inefficient things to work around these issues with the opportunity to come back later. Often inefficient Rust with lots of clone operations is still faster, smaller, lighter than the same services in Java or C# as an example.

[sheepscreek]

UPDATE: This would make for an excellent case study if you don’t mind sharing the details. I am very curious about the number of agents, hours it took, and models used (did you use Mythos?).

This would not have been possible 5 years ago. LLMs are going to push us into the space age. Both Anthropic and OpenAI have committed to spending 10s of billions of dollars on training alone for the year. I am equally excited and terrified at the pace of progress!

[inglor]

Rust is really fun to work with and the compiler is great, just make sure the rewrite takes compile times into account since larger projects often have to be organized in a way that makes compilation reasonably fast.

[ignoramous]

  how long does it take to compile?

  @jarredsumner: It's basically the same as in zig using our faster zig compiler. If we were using the upstream zig compiler, rust port would compile faster.

https://x.com/jarredsumner/status/2053050239423312035

[jorams]

This is at least partially disingenuous. Zig is working on, and has already shipped for some situations, a faster compiler. Bun runs on an outdated version of Zig that doesn't include it.

[laurencerowe]

In my experience Bun in Zig compiles more slowly than Deno in Rust.

[hiccuphippo]

Single compiles for sure. Where Zig is optimizing compilation is in the incremental compiler, which I've seen compile the compiler itself in an instant after a single line change. Of course, that kind of speed is probably not interesting to some people if the AI is writing tons of lines of code before they go to the compilation step.

[laurencerowe]

I found making single line changes in Bun’s zig code led to very long compiles compared to doing the same in Rust code. It was a while ago though and maybe I was doing something wrong.

[cdud3]

Probably a very long time ago then. Try again with Zig 0.16. It's amazing how fast recompiles can be.

[cpeterso]

What coding model are you using for the rewrite? Opus for everything? A prerelease model like Mythos?

[folderquestion]

Just an aside, is there any way to know how many of those 16,000 compiler errors are independent. I mean, could it be that just by changing say 500 lines of code all those errors disappear?

Perhaps 16,000 could just measure cascade breakage, for example one lifetime mismatch can cause errors in every function that tries to use that reference.

Rust reference lifetime bookkeeping is a difficult task for LLMs. The LLM has to maintain, across multiple functions and structs, which references outlive which. Furthermore compiler messages are highly contextual and lifetime patterns are sparse in the training set.

[nhatcher]

That's a post I am eagerly waiting to read.

Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law.

I am a Rust developper myself but I really love Zig and Bun. I am just overly curious of all this.

[nextaccountic]

> Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law.

Even LLMs themselves can't accurately estimate this (though this may be out of distribution stuff)

[yen223]

LLMs have no conception of time, unless you explicitly feed in timestamps to the context

[0x457]

It doesn't stop LLMs provide "this feature set will require 4 months to finish" (and then finishing it one hour)

[yen223]

Sorry yeah, I meant to say LLMs have no concept of time, so time estimates they give are almost always hallucinations

[bw86]

Scotty from Star Trek does approve!

[Aeolun]

This does not surprise me in the least. Several Claudes are very good at splitting up and working through them all.

[sysguest]

> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things.

haven't used zig...(only used rust)

but zig doesn't solve those problems?

[nyrikki]

Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers.

I am of the opinion that it is horses for courses and not a universal better proposition.

Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc…

While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case.

1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior.

2) defer[0] allows you to collocate the the freeing of resources with code.

That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case.

I was working on some eBPF code in C and did really miss zig.

For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth.

[0] https://zig.guide/language-basics/defer/

[IshKebab]

Fwiw you don't need unsafe for graphs or linked lists in Rust. At least not directly - these things can be abstracted. The petgraph crate is the most popular for graphs. I'm not sure about linked lists because linked lists are the wrong choice 99.9% of the time.

I've written hundreds of thousands of lines of Rust and outside of FFI, I've written I think one line of unsafe Rust.

[awesome_dude]

Show code

[program_whiz]

I think he meant "show me a true linked list / node graph in rust that isn't unsafe". The reason being its not possible using c-style pointer following (or without just putting everything auto-pointers). What you've shown is exactly the tradeoff they were referring to. In rust, the answer is: make sure lifetime of all memory is explicitly managed, then use integers for the 'links' between nodes.

His point was that for his programming, he wants to be able to make real pointers and real linked lists with memory unsafe, which Rust makes difficult or opaque. For example with linked list, you could simulate (to avoid unsafe), by either boxing everything (so all refs are actually smart pointers), or you can use a container with scoped memory lifetime, and have integers in an array that are the "next" pointer. In addition to extra complexity, the "integers as edges" doesn't actually solve the complexity, it just means you can't get a bad memory error (you can still have 'pointers' that point to the wrong index if you're rolling your own).

Same with your graph code. Using a COO representation for a graph does in theory make it "memory safe" (albeit more clumsy to use if you are doing pointer-following logic), and it also introduces other subtle bugs if your logic is wrong (e.g. you have edge 100 but actually those nodes were removed, so now you're pointing at the wrong node).

I think the point (which I agree with for things like linked list, graph, compiler) is that depending on your usecase, the "safety" guarantees of rust are just making it harder to write the simplest most understandable code. Now instead of: `Node* next` I have lifetimes, integer references, two collections (nodes and edges) to keep in sync, smart pointers, etc. Previously my complexity was to make sure `next != null`, now its a ton of boilerplate and abstractions, performance hits, or more subtle bugs (like 'next' indices getting out of sync with the array of 'nodes').

If there was a way to explicitly track the lifetime of an arbitrary graph/tree of pointers at compile time, we wouldn't need garbage collection -- its not solvable at compile time, and the complexity has to live somewhere.

[IshKebab]

Err https://github.com/petgraph/petgraph

What are you asking for exactly?

[efficax]

zig is unmanaged memory. But rust also allows memory leaks, and they're not uncommon in large, complex programs. So this rewrite will not necessarily control for that.

[X0Refraction]

What language doesn't allow memory leaks?

[dmytrish]

There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).

[ethanpailes]

In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.

[tardedmeme]

Rust allows reference-counting cycles, right?

[efficax]

I suppose all languages allow them, depending on how you define a memory leak. Garbage collected languages generally prevent them, since you never have to explicitly free memory, but if there are reference cycles, that memory can never be freed automatically. Rust has the same problem, but since rust uses lifetimes to understand when to drop things, many people expect that this will mean there can be no memory leaks, but leaks are not considered a correctness or safety issue (oom is a panic and panic is safe!). Not only explicitly possible (through Box::leak) but also possible by mistake (again, usually through reference cycles).

[xigoi]

> but if there are reference cycles, that memory can never be freed automatically.

Many garbage collection algorithms can deal with cycles.

[SuperV1234]

Zig doesn't even have RAII...

[reactordev]

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.

[shakow]

And a function call is just a fancy JMP, still it's generally acknowledged to be better to have all the bookkeeping automated.

[rcxdude]

Does defer in zig track the objects lifetime directly, or is it like the various other 'context' features in other languages where it only really works for lifetimes of function-local variables and leaves you on your own when things get more complicated? (which, IMO, is precisely when RAII becomes most useful. It does seem like most of these languages only consider the 'forgetting to cleanup on an early return from a function' case)

[nly]

Constructors and destructors are also just function calls in C++

And you can't forget to type defer

[SuperV1234]

It's not a good thing. The reasoning is extremely simple and I don't understand how can anyone oppose it: there are some operations that you don't want to forget BY DEFAULT.

If I open a file, eventually I want to close it. If I allocate some memory, eventually I want to deallocate it.

Any programming language design that intentionally puts the onus BY DEFAULT on the user to *not forget to manually do something* is honestly asinine.

Defer has a place (I do use defer in C++, in fact you can implement it with RAII, proving that RAII is strictly more powerful/more flexible), but the default should be the safest and most straightforward option.

Also "magic-sauce that does a lot for you" is just false. It's literally a function call injected at the end of a scope.

[bnolsen]

One of the core design principles of zig is no implied behavior.

[fooker]

How is defer not magic sauce?

[zephen]

Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor.

The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.

[josephg]

Nope! Zig is like C in this regard. There’s no borrow checker. Managing memory is your responsibility.

It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.

[dnautics]

It's not.. but im pretty sure it could be. could probably even take this (WIP) idea and bolt on a formal verifier pretty easily.

https://github.com/ityonemo/clr

[josephg]

It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust knows when it can Drop). And rust can put noalias everywhere in emitted code. And you'd probably have worse error messages than the rust compiler emits.

Its an interesting idea. But if you want static memory safety in a low level systems language, its probably much easier to just use rust.

[dnautics]

> I suppose you could work around that by adding lifetime annotations in zig comments.

you can make a no-op function that gets compiled out but survives AIR

> rust knows when it can Drop.

and its possible to cause problems if you aren't aware where rust picks to dropp.

> And rust can put noalias everywhere in emitted code.

zig has noalias and it should be posssible to do alias tracking as a refinement.

> But if you want static memory safety in a low level systems language, its probably much easier to just use rust.

don't use that attitude to suck oxygen out of the air. rust comes with its own baggage, so "just using rust because its the only choice" keeps you in a local minimum.

[pjmlp]

Those tools exit in C tooling as well, now that many ignore them is another matter.

MSVC has a debug allocator since at least Visual Studio 5.

[baranul]

It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is.

Zig is still under development and beta. Stability, crashes, and leaks should not be surprising, and even expected. To stick with a beta language, usually companies and developers are philosophically and/or financially aligned with the language. An example is JangaFX and Odin, where they not only have committed to using the language (despite being beta) in their products, but have directly hired GingerBill.

Team Bun appears to have "alignment and relationship issues" with Zig, to the point they have decided to extensively explore their options. Now Bun is rewritten in Rust. They are seeing if Rust solves their requirements. As with any relationship, if one ignores or takes a partner for granted, don't be surprised if they want a divorce or jump to someone else.

[smj-edison]

You might want to check their Codeberg then, because they've moved all their development over there...

[baranul]

Zig very much could of moved all of their GitHub issues over to Codeberg, to be resolved, but chose not to do so. Thus left thousands of issues unsolved and stranded.

This maneuver was arguably obfuscated by the anti-LLM stance and finger pointing at Microsoft, but nevertheless, many still have noticed. Zig, for a long time, had been falling behind and doing poorly on their open to close ratio for resolving issues. It should be embarrassing to leave so many issues open.

Even if not accepting new GitHub issues, they have demonstrated an inability to resolve existing issues, except at an extremely slow pace. Considering there are just about no new issues on their GitHub repo, it is understandable if there are those that find the pace to close and amount of issues unacceptable or questionable, in addition to the clearly bad open to close ratio.

[smj-edison]

Did you read their migration post? They are thinking about it as COW, so they're using both issue trackers right now, but as soon as the update an issue it jumps straight to the Codeberg issue tracker. It's an unconventional way of doing it, but it's no conspiracy.

[Eufrat]

I think given the current mood of things, it would be prudent to not make such strong assertions on anything. Trust is in increasingly short supply these days.

[minimaxir]

Nothing Jarred said is an assertion other than "There’ll be a blog post with more details."

[dakj12iH]

"I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive."

These are two assertions. There could have been a prior secret rewrite that took much longer than six days and this is a marketing stunt for Anthropic. In case people still don't get it, Jarred works for Anthropic and Bun belongs to Anthropic.

[preommr]

Those are not assertions of anything meaningful. We have no idea what his expectations were. Maybe he expected it to be absolute crap, and it was only kind of crap. None of it means that it's actually viable. My fat uncle trying to beat Bolt's time could exceed my expectations by improving from 30s to 20s, doesn't mean it's ever going to be a reality.

> In case people still don't get it, Jarred works for Anthropic and Bun belongs to Anthropic.

In case people still don't get it, Jarred works for Anthropic and Bun belongs to Antrhopic. This means that people that have an ax to grind against anthropic (admittedly a reasonable position), will take the most antagonistic position they possibly can because of personal bias.

[thrwaway55]

I disagree. This is the same sort of marketing strategy as Mythos.Wow it out performed so much we have to tell you in the future. If he wasn't aligned financially with the outcome I'd agree but he's not

[lelanthran]

Peter Naur: Programming as Theory Building

Bun: Hold my beer

[4aksh19]

"No one has the intention of building a wall" - Walter Ulbricht, chairman of the central committee, a couple of months before the Berlin Wall was built.

The AI companies and their associates are beginning to surpass that level of denials and lies.

[christopherwxyz]

It’s disrespectful to immediately jump to adversarial conclusions from a simple desire to refactor and poor netiquette.

[yrjrjjrjjtjjr]

The right to be suspicious of the motives of powerful people is infinitely more important than protecting their feelings from being hurt by suspicion.

[johncolanduoni]

Powerful people figured out how to make suspicion work for them long ago. You have every right to be unconditionally suspicious, but it’s not a good way of accomplishing any change. Also their feelings are not hurt by what you or I think, they don’t care.

[irishcoffee]

> Powerful people figured out how to make suspicion work for them long ago. You have every right to be unconditionally suspicious, but it’s not a good way of accomplishing any change.

How does one accomplish change? Even being a martyr doesn't get traction. As far as I can tell, you need to already be powerful. Nobody lets you into that group if you're not aligned with said group.

Protests (at least in their current form) don't work. Trying to assassinate someone doesn't move the needle (also not the play, I don't support murder), vocal grassroots leaders are no longer relevant at all, if they ever were.

How does one accomplish any change?

[johncolanduoni]

Not by trading the same suspicions on the internet with fellow true believers over and over again, I think the past 10 years have proven that pretty conclusively. Maybe people should try some of the things previous social movements did, seemed to work pretty well even against a much more uniform media environment and a stronger hostile social consensus.

Protests don’t immediately solve everything, but I think looking at 2026 and concluding they don’t move the needle at all is a weird take. There are recent examples of protest movements (especially long-term ones) working all over the world.

[airstrike]

Become mighty rich too first, and then accomplish change.

[klausa]

> Also their feelings are not hurt by what you or I think, they don’t care.

I would have agreed with this like 15 years ago, but the very existence of Twitter (and the acquisition saga) proves this to not be true.

[johncolanduoni]

Dario Amodei is not Elon Musk. Most powerful people do not internalize the emotions of others (though obviously some do). If you think powerful people are disproportionately sociopaths, you either agree with me or are not using the word correctly.

[root_axis]

> Also their feelings are not hurt by what you or I think, they don’t care.

Definitely not true, they tend to care more than most.

[johncolanduoni]

They generally care about what powerful/influential people think. I’m not powerful or influential, but I guess maybe the person I was talking to is. If so I apologize for the miscommunication.

[christopherwxyz]

Protecting software creators, engineers, builders, and their work, regardless of their tools, is infinitely more important. Full stop.

[otterley]

This isn’t about rights. It’s about not being a jerk. Assume positive intent unless you have direct evidence to the contrary.

[dandellion]

Four days ago there was no intention to rewrite, now it's a simple desire to refactor. It's not adversarial conclusion, it's pointing out the clear hypocrisy.

[johncolanduoni]

Running an experiment, the experiment being more successful than you thought, and then deciding to put more effort into a bigger experiment is not hypocrisy. It’s engineering. If you think some of the objective facts they’re putting out (like test coverage and performance) are lies, go and prove it instead of appealing to emotion.

[baranul]

Especially if given near unlimited tokens to burn through, because any level of success fuels the LLM hype machine, which brings ROI.

> It’s engineering.

Significantly, but not totally. The marketing value can't be ignored.

[johncolanduoni]

What do you think one would have to pay to have flesh-and-blood engineers get a cross-language port of a codebase of over half a million lines with a broad test suite to over 99% conformance? I think it would be astronomically high, especially given that for this specific project your hiring pool is going to be limited to people who can get up to speed with Zig and JavaScriptCore right away (or you’re going to have to pay them for low output for a while as you train them). Also it would be literally impossible to do in 6 days no matter how much money you paid, so unless they’re lying about that it’s still something that couldn’t have been done prior for any price.

More handwaving about the LLM hype machine is incredibly boring and enough of it is spewed everywhere that whatever social good it was going to accomplish must have already happened by now. If you want to inject reality into the situation, talk about reality (like Anthropic is at least pretending to).

[dandellion]

Running an experiment and deciding based on the results is not hypocrisy, it's engineering, 100%.

Saying you have no intention of doing something then doing it is not engineering, it's being dishonest. He could have said "well decide when we see the results", why didn't he?

[johncolanduoni]

If he wasn’t willing to change his mind after he saw the results, then why would he do it at all? Can you explain the false motivation that you think he communicated in the original kerfuffle about this?

[BatmanAoD]

Why are you conflating "no intention of doing a rewrite" with his actual wording, "we haven’t committed to rewriting"? The latter does not at all indicate that there would definitely not be a rewrite.

[awwaiid]

Maybe he didn't think it would work. Maybe even if it does "work" they'll keep the zig version anyway. Maybe further study is needed beyond existing compiling/test-suite. Intentions and perspectives change over time, even only a few days, without dishonesty.

I'm guessing that if I said it ... that we have no intention of re-writing in rust ... that what I mean is "we have no intention of spending the extreme cost it would take to rewrite". When I discover the cost model is completely different that changes things.

[renticulous]

This attempt is like shooting for the stars. Most of us software developers are plumbers and we just need to reach to the moon.

[christopherwxyz]

Being able to change your mind is a excellent exercise in free will.

[dandellion]

Totally.

Saying you don't intend to do something and then doing it is free will.

It's also lying. They are not mutually exclusive.

[y3ahd0g]

"People cannot change their mind!

One must stick to old assertions forever!

Giant foot is gonna squish us!"

...this forum is as bad as a single backwater sub Reddit.

I am so sick of emotionally frail software engineers. I don't know why I keep bothering floating back here every once in a while to see what is up.

Same old rustled jimmies over technology evolution like back during the emacs and vi! tabs vs spaces! Sysv init vs systemd!

Super hero power scaling message boards are more engaging than this site.

AI save us from these needlessly economically empowered labor exploiting non-contributor script kiddies. Such an unserious community.

[dandellion]

Okay, that's such a shallow take I'm going to try and explain it to you like you're 5 years old:

Changing your mind is okay, for example if someone said it was impossible to do the migration with current LLMs and it turns out they did it in four days, that person can and should admit they were wrong. That's not what he did though. What he did is say he had no intention of doing it, and then did it. That is lying. If he was testing and he didn't know if the change was going to be worth it, he could have said for example:

"This branch is a test, it's not a given it will work so until we see the results we won't decide if we'll be migrating or not."

He didn't say anything like that though, he basically said:

"We have no intention to migrate."

Why did he said the latter and not the former? Because he wasn't being honest, he was just trying to get people off his back, and so he didn't say what he was doing, the best for his own interest. We have a saying in my country: "it's easier to catch a liar than someone who's lame".

Also, before you come and say but he said he had no "intention" not that he wasn't gonna do it. A five year old might think that's a valid argument, but this person is an adult and we're all adults here, so it's not, it's equivocation and it's a logical fallacy.

> I am so sick of emotionally frail software engineers.

Then don't look in the mirror, you're probably being the biggest crybaby in this thread so far.

[erkat]

If experienced (in open source and corporate politics) developers would bet on Polymarket if the rewrite is going to be ultimately merged, which side would you bet on?

What would the emerging odds be? My guess is 19/20 in favor of ditching Zig.

I have followed many initial denials on a wide range of topics, not only rewrites, over the years. Like clockwork, most of them were lies.

[geysersam]

I don't think there's much chance it gets merged.

Even if it passed the full test suite there are a ton of software qualities that are not captured by tests and I think it's unlikely the AI made the right trade-off in every such case.

* We haven't seen the benchmarks yet.

* It hasn't seen wide usage. Zig Bun has had tons of bugs ironed out, Rust Bun has a different set of bugs to iron out.

* The developers know the zig codebase well, they don't know the rust code base.

[christopherwxyz]

I don't think most serious developers have time to watch prediction markets.

[Cthulhu_]

Not to mention invoking a major historical event, appeal to emotion move.

[dzonga]

you know this whole exercise is both a marketing exercise and a way to make noise.

would the world come to a standstill tomorrow if every Bun instance out there ran on Node.js ?

they know their A.I can't sell without the noise that it's now on the edge of the frontier. this is hype.

zig adopting a strict 'no LLM' policy affects the LLM vendors.

[baranul]

A good point. The business and marketing aspect of this situation can not be overlooked. The rewrite in Rust was a clear marketing opportunity, to maintain the LLM hype, that team Bun warmly embraced.

[geodel]

At this point one should just say Anthropic team. I can't think of a Bun team since Anthropic bought Bun.

Jared, the hacker is now replaced by Jared, the millionaire soon to be billionaire as Anthropic valuation keeps going up.

[sdevonoes]

Exactly. Always asks “who benefits from this?” . The answer in this case is: AI vendors, not us.

[aleksiy123]

It’s also just a useful exercise in general, especially for getting feedback for models and harnesses.

I’ve been thinking about setting up a non trivial project to use as a benchmark for any plugins and/or harness changes I make.

Having a prebuilt verification suite is great. You can use it to asses things like token usage, time, across different harnesses, models, plugins.

[johncolanduoni]

I don’t think the Zig project adopting a strict ‘no LLM’ policy affects the LLM vendors at all. How many developers are working on the Zig project itself that will (maybe) now not buy a Claude subscription? I can buy that this is a marketing stunt, but nobody at the top cares if a relatively small open source project doesn’t allow AI contributions.

[baranul]

I don't know about that. Zig's bdfl got significant mainstream press attention for his anti-LLM stance. Definitely enough attention for various LLM vendors to notice.

[johncolanduoni]

Based on their actions, I don’t think the LLM vendors take anti-AI sentiment very seriously. If anything they court it, though I think it’s more likely they’re just high on their own supply. I doubt the Zig statement had any effect on the thoughts of the people who actually sign contracts with Anthropic, who are mostly not engineers.

The marketing opportunity here is in promoting Claude Code, not giving a smackdown to Andrew Kelley (who vanishingly few people who throw around millions of dollars on AI contracts have heard of).

[tracerbulletx]

If you think Claude needs manufactured hype at this point to sell it you're delusional.

[claude_delusion]

Anthropic literally has an astroturfing program:

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

[rcxdude]

I would expect from 'astroturfing' that they were in some way paying people to recommend it. This just seems to be advice on how to recommend it for people who already want to recommend it.

[geodel]

Manufactured hype is just marketing. And companies losing money and looking to get listed very soon absolutely need it.

[not_paid_by_yt]

it does tho is the thing, like if someone is fine with using a non-SOTA model then no, but those people are probably happy with deepseek or something cheap like that, if you feel you need to be on the absolutely frontier of commercially available that's OpenAI right now, they need to convince those people they are not too far behind if they are still only using Opus or enroll them onto Mythos.

[wiseowise]

That’s how marketing works.

[sdevonoes]

If you think they can survive without hype, you are the naive one

[logicprog]

Looks like he did the maintainability performance and test suite checks and made his decision :)

[jazzypants]

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.

[nvme0n1p1]

Bun was VC funded and acquired by Anthropic. He's spending company money, not his own money.

[jazzypants]

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?

[nvme0n1p1]

6 days is also nothing when you're doing R&D on your company's dime. He could have spent a month trying a dozen different things and thrown away all the code at the end. As long as he ends that month with a clear picture of where to steer the company over the next 5 years, it's time well spent.

[nozzlegear]

Had my former employers been so lenient with how I spend company time, I might still be an office worker instead of self-employed!

[throw1234567891]

Not even the company is spending money. It’s their employee working on a rework of the code owned by the company that owns the infrastructure on which the rework is done. And that company is still yet to turn profit. This work is subsidised by everyone who pays for Claude.

[skybrian]

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.

[jazzypants]

Fair enough. I didn't say anything about a "final call". It just feels like there is a middle ground between that and telling people they are overreacting.

[fragmede]

Yeah but with no guarantee that it was going to work, why should he have?

[jazzypants]

Yeah, but he obviously had enough confidence in this project to keep the agents working at it, didn't he? Given infinite time and money, if you prompt an LLM about something enough times, it will eventually work.

Insert something about monkeys, typewriters, and Shakespeare here.

[furyofantares]

He was 2 days into a project that ended up taking 6. You're being extremely unreasonable.

[throw1234567891]

But you didn’t have to sit and type. Assuming that you look at what it did, why not?

[zephen]

But he was just working along and someone else outed his branch, right? Dude doesn't owe you any sort of explanation.

[raincole]

Yeah, that means it's an extremely successful experiment so far.

[lioeters]

Also a few days before that:

> I expect OSS to go the opposite direction: no human contribution allowed. Slop will be a nostalgic relic of 2025 & 2026.

We should have seen this coming after they got acquired by Anthropic, but it's still disappointing. I'm not against large language models as a technology, just thoroughly disgusted how these "AI" companies rose to power, eating the software industry and the rest of society. It's creating a very unhealthy dependency.

Think a few steps ahead and start preparing a slop-free software stack and community. That includes Zig and its ecosystem. Even if we (and future generations) don't manage to live entirely without slop, it's more important than ever to ensure a sustainable computing culture, free as in freedom.

[tempaccount5050]

Software companies have been about automating human labor since the invention of computers. It's the whole damn point. Why do you think finance used to be (sometimes still is) the head of the IT dept? Because we automated accounting away. Then typists. Then secretaries. Then drafting. Etc etc.

[wiseowise]

> It's the whole damn point.

Believe it or not, for some of us it’s not “the whole damn point”.

[tempaccount5050]

Whether or not you want to admit that is up to you. If you're selling automation or efficiency gains, you're removing human labor.

[gravypod]

My first "job" in computing, where someone else paid me for code, was in a research context where we were modeling radio propagation. Nothing about that was removing human labor. It in face eventually called for a bunch of humans to interact with each other. See: https://www.hamsci.org/basic-project/2017-total-solar-eclips...

I don't think it is fair to claim computers are about putting people out of jobs.

[tempaccount5050]

I think it is. Before computers you would have had to write all that down on paper logs. By using code, you saved yourself time. If it wasn't less labor, you wouldn't have done it that way.

[Georgelemental]

Human labor could do the math by hand

[wiseowise]

I'm improving error prone systems to make the world more efficient, not to replace people.

[ori_b]

The purpose of a system is what it does. If people constantly use your device to turn kittens into pulp, you have built a kitten grinder, even if the label you slapped on the side says "coffee beans only".

[wiseowise]

Nonsense. By your logic anything pointy is a killer machine, because people constantly use them to kill.

[ori_b]

If that's constantly the thing your device is constantly used for... yes?

[skeledrew]

Why else would one create software, if not to do something that a human does/did?

[matt_kantor]

A few off the top of my head:

- Video games

- Medical device firmware

- Synthesizers

- Detailed universe-scale physics simulations

- Mars rover control software

- The Linux kernel

[skeledrew]

- Video games - only feasible because of computers.

- Medical device firmware - hardware control layer for medical devices, which are used to aid in medical procedures.

- Synthesizers - help to make music.

- Detailed universe-scale physics simulations - help to make certain physics problems more tractable.

- Mars rover control software - helps to remote control rovers.

- The Linux kernel - control layer that sits between firmware and actual applications, pretty much just a common shared library so apps don't have to each ship with a full stack.

I don't really see your point here. None of these examples counter the argument that software is created to automate human labour as much as is practical.

Video games are an interesting category since they're entirely enabled by software: I can't imagine anyone driving a video game manually (note I don't consider things like Chess, etc software to be video games in this context; more things like FPS, racing, etc). I do remember as a kid I thought that there were actually little people doing the stuff in video games though.

[tempaccount5050]

This list is funny.

All of these things existed in pre computer form.

A scheduler used to be a person putting punch cards into a machine.

[moring]

To do things that a human could have done in theory, but did not do because it would have been too expensive.

[nly]

To do new things no number of humans can do

[grim_io]

No one is taking away programming as a hobby from you :)

[sdevonoes]

There are software components out there that are the backbone of our industry, and they are not governed by multibillion dollar companies. Linux, postgres, HTTP, TCP/IP, qemu,…

It’s not that anthropic/google/openai/etc are unavoidable

[tomnipotent]

> they are not governed by multibillion dollar companies

Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion dollar companies. Red Hat and IBM are responsible for 40-60% of contributions to Qemu.

[dakiol]

The way I understood op is that we don't necessarily have to pay to use linux or postgres (when self hosting, for example). But we have to pay to use claude code... which sucks big time (also, open source models are behind private models)

[tomnipotent]

Claude Code isn't OSS, so I fail to see the connection. You're paying for compute, not access to code. I'm personally more than happy to pay for access to that compute.

[raj1298]

The usual model for OSS projects is that initially they are written for free. Then an inner circle forms and exploits the second generation of idealists who write entire large features without ever getting the same rights.

Some of the inner circle move to corporations to increase their power and are joined by corporate developers (sometimes their bosses) to take over the project.

A lot of corporate OSS development are entirely unnecessary rewrites or simple things like release management. So I'd put the number of useful code by employees much lower.

But governed, hell yeah, I agree. The corporations crack the whip and oppress real contributors.

[tomnipotent]

This is a nice fantasy, but that's all it is. Most of the code used by corporations is also mostly contributed to by other corporations. Contributions by volunteers is the exception for most of the projects in this context. I also don't think this is a bad thing.

[shmichael]

So you argue we discriminate based on who/what wrote the code, instead of what's in it?

Let's take this to a different domain, self driving cars. Would you equally argue for human driving? I'm pretty sure over time it will become clear to everyone that machines will be able to outperform humans consistently at this task, to the degree that human driving will become illegal. But for now the press likes to focus on any failure of machine driving, taking for granted human drivers are the largest or second largest cause of premature death in many countries.

Coding (in many ways, but not all) is a more open ended and versatile task than driving, so it's natural that current iterations seem untrustworthy, but ignoring the trajectory is erring on conservatism, and doesn't seem to me to be grounded in any sound reasoning.

[foxes]

How could it possibly be open source if it requires proprietary models developed by a few companies to writs the code.

Seems like that would make open source entirely controlled by open ai, anthropic et al.

[brabel]

Open source and open weight models are already really good. I don’t think anyone really depends on the big AI companies anymore, if they go away, the open source models seem to be already sufficiently good to take the torch and will continue to improve thanks to research. They may require money to train , but the cost of that is already covered quite well and if these model became the mainstream way to use AI , more money from governments and research institutions would be poured into them.

That is actually a very plausible scenario!

[andy_ppp]

It isn’t really slop anymore and it will keep improving.

[faangguyindia]

He works at claude, he has unlimited tokens. He can do anything, he is using mythos.

[not_paid_by_yt]

what one has to do when corporate does not not them use GPT-5.5

[scotty79]

I think such re-implementations will be a huge asset to the process of software developments in the future.

[des429]

What's your point

[righthand]

To demonstrate engineers may not be as skilled and knowledgeable as they appear. To make such a comment then turn around and make an announcement days later indicates that the engineers are not skilled in the tools they’re using or even possibly the domain they’re working in.

[nerdsniper]

The quote doesn’t provide warrant for this claim. The developer did a great job investigating the applicability of a new tool and it appears the investigation yielded fruit.

Your kind of negativity is pathological.

[antonvs]

Being an expert software developer - which Jarred Sumner indisputably is, having created Bun - doesn't automatically make you an expert on predicting the improvements in software development performance that LLMs enable. All of us - experts and amateurs alike - are in the process of figuring that out, in real time, around the world, right now.

Underestimating how quickly a non-trivial project will come together is an almost unheard of phenomenon. It used to invariably be the other way around, to the point that there are laws about it, like Hofstadter's Law, which says that projects always take longer than anticipated, even when accounting for the law itself. Or Fred Brooks' work, which puts limits on how much the development of software projects can be sped up.

The sane takeaway here is that if what's being reported is true (keeping in mind it's coming from a newly minted Anthropic employee), it implies an astonishing, unheard of improvement in software development speed, at least for certain kinds of tasks, enabled by LLMs.

To somehow twist that into "experts may not be as skilled and knowledgeable as they appear" or "not skilled in the tools they’re using" makes me think of the Charles Babbage quote, "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such [an opinion]."

[esquivalience]

I totally disagree with this! I think it's very important for experts to be able to adapt to their opinions based on evidence.