bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?
zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?
I bet they'll ultimately reverse course on this, or the there will be a bun / zig fork becomes the de facto bun. Despite what the influencers say, I'm convinced you cannot vibe code a conversion this big. It will need a ton of human intervention. And for brand narrative reasons, Anthropic won't commit to such a path.
It depends on how thorough the test infrastructure is I think. Something like curl with its immaculate tests could probably get autonomously ported if you threw infinite tokens at it because you have deterministically defined what finished looks like. But I think you are likely right in this case.
> bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?
Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language. This is a nightmare scenario for most companies, and will motivate similar sized companies/project to pick another language that will not require this than to risk using Zig. Also, Zig’s flippant attitude about Bun’s request (among other viewpoints) only further adds to why bigger projects would want to stay away from Zig.
> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language.
That is not the fact of matter. The fact is it got bought by Anthropic. And in larger scheme of things Bun is one example Claude capabilities of translation. And even if doesn't work, it just a part of Claude desktop stack so still have millions of installs.
Not really, if it doesn’t work then it will hurt their flagship desktop app’s stability, which would negatively affect their placing in an already cutthroat AI arms. Claude Code is the few business asset that Claude has the least moat compared to other providers( even open source). They can’t afford to be sloppy and use a buggy JS engine.
Huh, I don't know which world you live in. In my world trillion dollars companies regularly release absolute crap of the software that hardly affects their industry usage or popularity.
In case anyone is not following the AI tool's biggest growth is in enterprises. And usability, quality or stability is measured very differently there compared to individual users. In my last 20 years of experience of using enterprise software and tools being third rate is never any issue.
I don't remember where it was said first, but I think the problem was not "AI drama" or that zig doesn't have "a good solution". It was more a mismatch between Bun's & Zig's goals. Bun wants to move fast & break things, even more now after getting acquired, but Zig punishes that. Zig requires you to handle everything carefully, there's no GC or big runtime to let you "break things", zig will let you just segfault.
Companies like TigerBeetle can and will benefit from zig's model.
But this goes to my second point; it seems like Zig wasn’t open to any compromise about the solution that Bun submitted and one they built in house. Is it the Zig culture to reject a pull request like that wholesale? It’s really odd for them to have such a flippant attitude and not to even try offer ways that they could use the pull request or things that they need to tweak to make it more inline with what they want. Companies want to use languages that have a understanding committee, and are willing to work together to create solutions, not just say “No, this isn’t what we want, and we are building a similar system anyway so don’t even bother to try again”. It just looks unprofessional.
A large, complex, unasked for PR is pretty likely pointless to throw at any serious project. (Well, it's pointless if your goal is to merge something.)
Working together is a two-way process. To land a big change, the bun people probably needed to have been working/coordinating with the zig people throughout. E.g., zig outright cannot accept PRs that break the language in unplanned ways and any conflicts with the roadmap would need to be resolved.
I would assume the bun people know all this. That makes it more of a publicity stunt than a serious attempt to contribute to zig, and we should probably all treat it that way.
Of course, and it is expected that large pull requests/RFCs are iterated on. I will not believe Bun seriously asked for a pull request to be merged with absolutely no expectation of back and forth discussion. But this isn’t what happened. The whole reason everyone thought it was rejected by Zig because Bun used LLM to generate it was because they responded in a way that someone would if they didn’t want a certain pull request accepted under any circumstances. Which is my point; it I just insane that their largest project submitted a pull request, and they just rejected it with prejudice, gave some statement saying the real and potentially fixable reasons why, then turn around and say we don’t want your help, we are doing this in house.
My interpretation of what they said is closer to “we already improved compilation speeds by 4x and we did it without compromising our plans to go much further - also this PR introduces specific timing bugs.”
Compromising on project goals just because someone with somewhat different goals made a pull request doesn’t exactly scream responsible and professional to me. The way I understand it, many people appreciate Zig because it’s very consistent and restrained about the kinds of problems it’s trying to solve and how, so being very careful with accepting complex, externally developed solutions seems perfectly in character for the language.
I’m not sure how well the Zig developers have handled their communication, so perhaps there really was room for improvement there.
"Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes."
"Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions."
"So instead of wasting time writing a more robust implementation of this LLVM module splitting logic for a relatively minor improvement, we have instead put that effort towards features like self-hosted backends and incremental compilation, which can improve compilation speed by orders of magnitude.
[...]
There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!"
> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad
It's unlikely to be just a devex issue. The fact of the matter is that a memory unsafe language is an extremely tough sell today, and companies that have a security team at all have likely already made or are planning on making policies like https://chromium.googlesource.com/chromium/src/+/master/docs...
There's a reason "rewrite it in Rust" was a meme long before LLM coding tools or this Bun drama. With AI accelerated fuzzing techniques and similar, memory safety is rapidly going to become a basic requirement of anything run in a production environment.
the “(super) efficient” is not there yet. Io is still dynamic dispatch with multiple layers of indirection. afaik it’s slower than before.
the upcoming releases are expected to provide a solution to this “dispatch is comptime-known, but still dynamic” problem, and drop the loses in efficiency.
Hmm in the 2025 talk ( https://youtu.be/f30PceqQWko?si=qZESxMaSyt7fYMfz ), Andrew emphasizes that this approach is more efficient than before- even showing compiled assembly iirc. I guess that was a one-off?
A vtable indirection is essentially free when you're going to perform a syscall. What matters is that the buffer is above the vtable (which is already the case for the current implementation) so that you don't pay for the indirection when hitting the buffer.
It's not just I/O, it's also mutexes, condition variables, time, etc. It's not horrible, but it does add up, so calling it super efficient is a stretch.
A modern allocator with per-thread cache can satisfy some allocations in 20-30 cycles - dynamic dispatch can easily double that, even if the target is still in cache.
It's one of these things where it's extremely use case dependant - like many performance issues, you probably don't care about it - but when you do it matters.
Inderect call cost is a few cycles, if predicted. Now, you can argue, that it may be mispredicted and misprediction would cost about 20-30 cycles. But if it is mispredicted, then you are not calling into allocator often enough. And if you don't hammer it hard, then why do you care about preformance?
I believe their plan is using "restricted function pointers", where you can specify that a pointer will only ever be to a function defined in the codebase. I'm pretty sure they also have plans for devirtualization, but I haven't followed super closely.
Oh, is it not a specific keyword? I thought they were thinking of it being a keyword so you could be sure that it was restricted, in case a variable or function was exported that took in a foreign pointer.
scheme is great, but the dx of some implementations is not. i’m on guile scheme due to guix, and frankly, i’m hating it a quite bit.
stack traces are esoteric and error messages entirely unhelpful,
documentation masquerades as deep but is indeed inconsistent and prosaic, mixing styles of reference, explanation, and how-to willy-nilly, (compare with Dybvig’s The Scheme Programming Language, which is focused and consistent, and it takes no time to get your answers; there’s just no method to guile and guix manuals), i hate it big time,
there’s big gaps in documentation (especially with Guix – there’s literally zero information about `define-record-type*` which is used everywhere in its codebase; admittedly, not scheme related, but still),
the cli requires too much memorization,
most modules are not named, but numbered, ie, instead of something like `(base list)`, you get `(srfi srfi-1)`, so you need to either memorize, or go through the info pages for each procedure you need to import, which means you also need to know the exact names for the procedures you need beforehand,
there’s like 4 ways to define a record, each with a different feature set and incompatibilities,
etc.
these are the reasons i find it hard to use.
to respond to the content of the article, the different neurotype idea is off, because scheme allows you very well to express sequences of operations; the ecosystem of APIs may not cater to this tho. although if it was rephrased into “scheme emphasizes symbolic manipulations, as opposed to operating a machine”, i would agree
Almost all of these problems are due to scheme being so absurdly fractured, it's a real shame. It's already niche, but then on top of it instead of having 2-3 robust implementations with robust cli / messages / docs / etc, you have 20 (not a hyperbole[1]), each one receiving diluted effort compared to what it could have been.
Probably the one bit that isn't strictly fracturing's fault is stacktraces -- scheme has TCO, which is nice for alot of things but it absolutely destroys dx as it relates to stacktraces. Other languages with TCO are similarly awful in that regard, including haskell (ghc has `HasCallStack` to try help it, but it's still awful to use).
I am only amateur level with scheme but these are common to other scheme implementations. SRFIs are semi-standardized core libraries that work mostly the same in all implementations. I believe the record-type and records generally are one of these SRFIs, and it’s based on a chapter in SICP (several show up as sections of the book where students implement things that would be language feature in a larger env)
All the Lisp implementations seem to have pretty cryptic seeming errors, but it also seems to be very informative to those who know how to parse the call stack and how to expand/dig down in the built in debuggers. This is likely because of the same idea as those record-types, much of the language is built in the same lisp you’re running - so the error messages go a few levels lower level than you would expect. It’s not just a C syntax error type explanation, but rather you get some error about a bad call to a function you’ve never heard of running below that feature we normally associate with being a core function
The issue with Guile's stack traces is that they get truncated beyond I think 80 characters, and frequently leave out stack frames (usually your own functions). Geiser does have a debugger, but it does things differently based on implementation and Guile's specifically is a fancy one that I couldn't get to grips with. Not that I've tried that much, as I believe it's quite new.
I explored migrating from NixOS to Guix, and I also hit the wall with the quirks of Guile Scheme. Architecturally, I find a Guix much clearer API than NixOS and aspire to the peace of mind that would come with a compiled system configuration. When I leaned into LLM's for support and they were substantially less effective at getting me over the line, not just conceptually but being able to close their parens properly. I ultimately decided to bail on the experiment, but it left me sad because my hunch was that if Guix were in nearly any other non-lispy language I'd have stuck through it.
Design rights[1] are a thing. However they need to be continuously defended. You can't let competitors make your designs (without license) for decades and then suddenly turn around and try to enforce the right, as seems to be the case here. Plus in the EU there are overall limits, apparently 25 years.
This is why I'm asking what the legal basis is for this case. It seems unlikely to be legally sound. Probably the German court made a mistake, and the company being sued should ignore Fender. (Not legal advice!)
Edit: Someone else just posted that Fender is now owned by private equity, so it's the usual PE playbook. A sad end to a famous brand.
Edit#2: Seems like the German court ruling was a default judgement because the other party failed to show up. So nothing to see here. Fender has no realistic case.
that’s why we say that with such discoveries we receive a new way – of looking, of doing, of thinking… these new paths preexist in the abstract, but they can be taken only when they’ve been opened. and that is as good as anything “new” gets.
(and such discoveries are often also inventions, for to open them, a ruse is needed to be applied in a specific way for the way to open).
it can’t really be a way to think about it when the recommendation is to not think about it and just do it. experience, observe, reach opinion. all in accordance with you and not some number that’s abstract to your perception.
Yawman, being on Linux for everything else feels great. In a personal way (rather than technical) it’s like being back in my 20’s hacking Redhat and FreeBSD. I also find the community support is great when I’ve run into the odd issue. My FPS are good and I don’t think about it.
I select games based on ProtonDB. There’s always constraints and I’m cool with the limitations that this brings. BF6 is a no-go due to its anticheat tool, no problem. Got lots of other choices.
My son is really into soccer, so I wanted to get the latest ~~Fifa~~ FC game. Oh it has anticheat and doesn't run, at all. Frustrating because I wouldn't want to play online anyway.
Happy to not give EA any money if they're so set on shoving online play and therefore anticheat down the players throats.
zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?
reply