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.
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
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.
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?
We are at an infection point with software. Similar to AWS was about fifteen-twenty years ago, or git. If you ignore it, you’re behind the curve. Now’s the time to experiment, figure out the good and bad. Not all orgs are going face first. Some of us are learning along with it.
Where it shines for me? Really small changes in a complex system. I can’t store all the context all the time. Business requirements, security ones, aesthetic ones. Where it shines is if you suss out small changes thoroughly, it’s a great text generating engine.
All of that said, the side effects of data centers and pump and dump stocks, are absolutely horrid. Hopefully on the other side of it we come to something more sane.
You can learn how to use AI coding tools in a week at most, and there’s no telling if next week they’ll be a new harness or loop or whatever that becomes the new trend, making everything you’ve learned so far obsolete. Nobody’s being left behind. AWS also isn’t hard to learn if you’ve done the similar infrastructure stuff yourself. And git isn’t hard to learn if you’ve used other version control systems.
And that’s the point. You don’t have to consume everything all the time w/ AI/LLMs. But if you don’t pay attn, 1) You’ll likely make mistakes on things which didn’t work out, like zero-shot prompting, or which models do better on which languages and 2) you’ll have to play catch up.
On git? Did you know git would have won over HG, or Fossil? What about using git submodules, or bisect? You can do the research now that I wrote it out, but would you have known about them before hand? What about all the hook features?
And git can be hard, esp if people around you don’t know it as well as you do, or people above you know it better than you do. Which again is a problem of people getting in way too late.
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
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?
Zig is not as strict as Rust for memory management
Unsafe rust too
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.
my comment was just pointing out to unsafe rust blocks used in sloppy rewrite.
You clearly don’t even know what
unsafein rust means. And it’s not something you can avoid when FFI is involved, slopping involved or otherwise.I see what you’re saying, but there’s no need to be rude.
Claude is it you?
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.
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.
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.
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.
-
Does Rust’s memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google’s blog posts).
-
Does “normal” (not slop) Rust code rely on some
unsafe? Yes. All Rust code must use someunsafebecause 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 someunsafe. Let’s say 0.1% of lines. -
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.
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
unsafeat 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.
-
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?
Haven’t you heard? “React” content is the new meta (/s only half way).
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.
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.
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
JavaScriptCoreis faster thanV8? Or is the majority of time in webshittery operations not spent on actually running code, and that’s how bun “wins” ?Are you saying
JavaScriptCoreis faster thanV8?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.
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.
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.
HTML title: Bun: A fast all-in-one JavaScript runtime
Bun is designed as a drop-in replacement for Node.js
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.
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 againstV8, 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.
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.”
I’m going to call
cargoa Rust runtime from now on, consideringcargo-scriptexists.Take the L and move on
