87
Zig Creator Calls Spade a Spade, Anthropic Blows Smoke (raymyers.org)
submitted 2 days ago by codeinabox@programming.dev to c/programming@programming.dev
35 comments fedilink hide all child comments
top 35 comments
sorted by: hot top new old
[-] ExLisper@lemmy.curiana.net 2 points 8 hours ago* (last edited 7 hours ago)

This is soap opera level drama. "It was a toxic relationship and we're happy they are gone".

I get it, they made you look bad when they were using Zig and they made you look even worse when they switched. It's just sad that software projects have to deal with issues like that instead of just focusing on engineering.

[-] vanillama@programming.dev 1 points 5 hours ago

It's more that most people would only associate them with that one project. It's not as bad as it could be, but for instance in the Ruby world everyone just thinks of Rails and, if they're aware of it, the main guy behind it flirting with white supremacy

[-] ExLisper@lemmy.curiana.net 1 points 4 hours ago

I think Rust was lucky no to get assassinated with just one app. It was created around the same time as Zig and 15 years after Ruby but it feels like its development is more mature. A lot of haters but few dramas.

[-] MoonMelon@lemmy.ml 74 points 2 days ago

The whole "AI is enough" marketing that the author mentions in the conclusion is total poison. A buddy of mine works at one of the companies involved in this circlejerk and they have the same mandate. Cost is not an issue. Use it for everything.

He said he has to roll the dice all day to get good output from the AI. Its more important they USE THE AI than it is that they PRODUCE GOOD CODE. In fact "good code" is not a thing, in the traditional sense. "Good code" means AI created. His actual title ostensibly has nothing to do with AI, they are producing a totally different thing. But since he works at a company that is benefiting massively from AI investment, his bosses are mandating a worse form of developing because they are now in the business of selling AI rather than what presumably is the product.

It's like if you were a plumber and your plumbing company merged with a huge factory that makes 90 degree pipe elbows. So they mandated that all plumbing now had to be done by joining together nothing but 90 degree pipe elbows rather than any other fitting. And since its all going to be sealed up inside a wall, who cares? How dare you question this? Are you saying there AREN'T legitimate uses for 90 degree pipe elbows?

[-] eager_eagle@lemmy.world 32 points 2 days ago

for anyone like me who could not understand that stupid title

"Call a spade a spade" is a figurative expression. It refers to calling something "as it is"[1]—that is, by its right or proper name, without "beating about the bush", but rather speaking truthfully, frankly, and directly about a topic;

"Blow smoke" - to speak idly, misleadingly, or boastfully

[-] slazer2au@lemmy.world 20 points 2 days ago

Bun’s founder experimented with a massive agentic rewrite from Zig to unsafe Rust.
That experiment was merged days later and is now the official version.

Wait, they ai yolo from a memory safe language to an unsafe version of a different memory save language?

[-] eager_eagle@lemmy.world 19 points 2 days ago

Zig is not as strict as Rust for memory management

[-] tracyspcy@lemmy.ml 9 points 2 days ago

Unsafe rust too

[-] eager_eagle@lemmy.world 7 points 2 days ago* (last edited 2 days ago)

yes, but when you make a port from one language to another, usually you want to rewrite it as a translation first, then refactor later with the features that language provides. A port that refactors everything in the first release is too risky.

The fact the translation has unsafe blocks only demonstrates the Zig version is not really safe as per Rust standards.

[-] tracyspcy@lemmy.ml 5 points 2 days ago

my comment was just pointing out to unsafe rust blocks used in sloppy rewrite.

[-] BB_C@programming.dev -4 points 2 days ago

You clearly don't even know what unsafe in rust means. And it's not something you can avoid when FFI is involved, slopping involved or otherwise.

[-] vanillama@programming.dev 3 points 1 day ago

I see what you're saying, but there's no need to be rude.

[-] tracyspcy@lemmy.ml 3 points 2 days ago

Claude is it you?

[-] BB_C@programming.dev -5 points 2 days ago

You can interface with a C++ JS engine without unsafe (which is equivalent to just using C btw), if you just really put a real effort into it.

😇

I do love me some internet gantry commentary. Especially when it's super confident and acting knowledgable, with multiple layers of genius on display.

[-] tracyspcy@lemmy.ml 8 points 2 days ago

where is quote from? You pretend this is a quote of something I wrote?

[-] FizzyOrange@programming.dev -2 points 2 days ago

Sure, but only 5% of the Rust code is unsafe, which is clearly an improvement. And their plan is to reduce that amount over time.

I'm no fan of AI slop but that point isn't an issue.

[-] SinTan1729@programming.dev 12 points 2 days ago* (last edited 2 days ago)

It depends on where exactly that 5% lies. If it's in the core API that's used by the rest of the architecture, it essentially makes the whole codebase unsafe when used irresponsibly.

I don't know if that's the case here, just pointing out that the 5% doesn't mean much.

[-] FizzyOrange@programming.dev 0 points 1 day ago

Not exactly. It means that any of the code could lead to memory unsafety, but it's still better than Zig or C because you still only have to read 5% of the code to debug/fix those issues, instead of 100%.

5% is clearly better than 100%. Whatever else you think about this port you can't argue against that. In fact I can prove that it's better.

  1. Does Rust's memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google's blog posts).

  2. Does "normal" (not slop) Rust code rely on some unsafe? Yes. All Rust code must use some unsafe because it's used in the standard library, and even if you ignore that (there is an effort led by Amazon to formally verify it), it's usual for Rust projects to use at least some unsafe. Let's say 0.1% of lines.

  3. So 0.1% unsafe is clearly better than 100%. Is it possible for 0.1% unsafe to be better than 100%, but somehow 5% isn't? That would require things to be non-monotonic which is completely implausible.

[-] SinTan1729@programming.dev 7 points 1 day ago* (last edited 1 day ago)

I'm sorry, but since we're being pedantic, this is not a proof. It's full of assumptions, some of which are wrong.

5% is clearly better than 100%

Never denied it. 0% is even better. What matters is where it's used. If it's used for FFI, that's understandable. Any other use should be scrutinized more. And that's the issue. The claim of Zig's creator is that the devs of Bun are not reliable. And to me at least, his arguments make sense.

it’s usual for Rust projects to use at least some unsafe

Doesn't seem like it. This article claims that only about 20% of Rust crates use unsafe at all. Even among those, the vast majority use it for FFI, which is kinda unavoidable.

but somehow 5% isn’t

Again, no one claimed that. But we need more than "better than 100%" when it's a JS runtime. And the "better"ness isn't necessarily linear. So, even though it might be technically "better", it might not be by much. At that point, what even is the point of the rewrite?

Again, I'm not claiming that it's actually badly written. I'm only claiming that your arguments are not adequate, and that Bun is not a reliable company, so take whatever they claim with a grain of salt.

[-] tracyspcy@lemmy.ml 5 points 2 days ago

So it is a reaction to Andrew Kelley’s reaction to bun / anthropic blog post that in their case was reaction to dev community reaction to sloppy rewrite from zig to rust with ai?

[-] Jayjader@jlai.lu 1 points 8 hours ago

Haven't you heard? "React" content is the new meta (/s only half way).

[-] BB_C@programming.dev -5 points 2 days ago

Bun is a TypeScript runtime, like a faster NodeJS.

I guess the target audience is non-coding AI skeptics looking for pseudo-intellectual takes, which appears to be a growing market. Because getting the very first technical detail, and a very basic one at that, this wrong is not a good look.

[-] TehPers@beehaw.org 3 points 21 hours ago

Which part of the statement is wrong? Bun is a TypeScript (and JavaScript) runtime and can execute TypeScript directly. Node.js can also execute TypeScript directly on relatively newish versions.

Sure, internally they execute JavaScript, but the statement as-is isn't incorrect, unless you're saying that Bun is slower.

[-] BB_C@programming.dev 1 points 18 hours ago

can execute TypeScript directly.

Did the word "directly" get the same fate the word "literally" got? As in, it completely lost its real meaning?

Bundling a compiler/transpiler and directing inotify at a source directory (for glorious hot-reloading) doesn't a language "runtime" make. Otherwise, I can create "runtimes" for any language in three lines of code right now.

unless you’re saying that Bun is slower.

Are you saying JavaScriptCore is faster than V8? Or is the majority of time in webshittery operations not spent on actually running code, and that's how bun "wins" ?

[-] TehPers@beehaw.org 2 points 16 hours ago

Are you saying JavaScriptCore is faster than V8?

No. Are you saying it isn't? Please cite your source if so.

Bundling a compiler/transpiler and directing inotify at a source directory (for glorious hot-reloading) doesn't a language "runtime" make. Otherwise, I can create "runtimes" for any language in three lines of code right now.

My bad, they're x86/ARM64 runtimes.

[-] BB_C@programming.dev 1 points 16 hours ago

You could have searched for some benchmarks yourself, instead of thinking you're winning an argument in such a stupid manner.

Note that Jarred himself (bun creator) wouldn't push against this either. Instead, he will sell you the aggregate performance talking point (as another user did), which is why I made my deliberately facetious comment about webshittery.

[-] TehPers@beehaw.org 3 points 15 hours ago

You could have searched for some benchmarks yourself, instead of thinking you're winning an argument in such a stupid manner.

Why would I do that? I made no claims to its speed. You're the one making claims, so the burden of proof lies with you.

Note that Jarred himself (bun creator) wouldn't push against this either. Instead, he will sell you the aggregate performance talking point (as another user did), which is why I made my deliberately facetious comment about webshittery.

I don't really care what Jarred says though. He hasn't exactly left a good impression with the direction he's taken Bun.

[-] assaultpotato@sh.itjust.works 15 points 2 days ago

https://bun.com/

HTML title: Bun: A fast all-in-one JavaScript runtime

Bun is designed as a drop-in replacement for Node.js

https://bun.com/docs/runtime

execute javascript/typescript files [...] with Bun's fast runtime.

Am I missing something? How is that claim incorrect? I've never used Bun but their marketing material lines up exactly with the claim.

[-] BB_C@programming.dev -5 points 2 days ago* (last edited 2 days ago)

First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.

Second of all, bun binds against JavaScriptCore, which is the JS engine used in Safari. Node binds against V8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.

Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.

[-] assaultpotato@sh.itjust.works 11 points 2 days ago* (last edited 2 days ago)

Saying there's no typescript runtime is (imo) a bit pedantic - if you JIT transpile TS down to JS at run time with hot-reloading you're effectively a TS runtime. For a non-technical one-liner on Bun, I feel that is a very reasonable simplification to make.

Perhaps bun would be even faster if they bound against another JS API, but that doesn't mean that Bun isn't faster than Node.js. They claim it's 3x faster than Node in aggregate, and that can potentially be true even if they use slower machinery under the hood. Python is a slow language but a fast framework can outperform a poorly written C++ implementation.

I'm not going to defend the article, I have no horse in that race, but until I see benchmarks that say Bun isn't faster than Node in aggregate, I don't think the claim can be called "wrong" on its face.

E: that's exactly what Bun does: "Bun supports TypeScript and JSX with no configuration. Bun transpiles every file on the fly with its native transpiler before running it."

[-] BB_C@programming.dev -5 points 1 day ago

I'm going to call cargo a Rust runtime from now on, considering cargo-script exists.

[-] vanillama@programming.dev 6 points 1 day ago

Take the L and move on

this post was submitted on 13 Jul 2026
87 points (96.8% liked)

Programming

27709 readers
348 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev