it will always be ambiguous as implementations are hard to compare across languages
Correct.
in the transition for x86_64 they were seeing up to 70% increase in compile speeds
And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.
Beyond what amounts to a packaging difference, what does that even mean?
How do you think zero-cost C ABI support (including fully working cross-lang LTO) works in lang implementations that have that? And how do you think that's different from what Zig gives you?
You can trivially use C libraries in Rust, or any system language that supports the C ABI for that matter, and this includes many hobbyist languages. Zig is not special.
They didn't use that technique. Some vibers do ask Codex to review Claude and vice versa. But since this is Anthropic-owned, they did use "parallel agents", but they were all Claude.
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.
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" ?
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.
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.
Putting vibe negativity aside, I checked what the local STT and TTS "support" looked like.
STT is based on rust bindings for whisper.cpp (2024 called!). And the three local TTS models claim is total bullshit. One is using an external service from a docker image, and the other two are trivial web clients that are not even wired. I also loved the circular reasoning at the start of the three TTS modules. Even an LLM is not something I would have pegged as that bad at logic. But maybe they got that way because of the prompter.
So ZERO interesting shit is happening here, vibed or otherwise. Nothing even close to using rust-based ML engines (candle, burn, tract), not even in a completely broken untested way.
This sorts of formalizes something that always existed ("communicating with rust users in production", "experience reports", ...etc). And it could be argued that centralizing and publicly documenting these activities is a positive move.
But this argument runs hollow in the presence of this potential start to a bureaucratic behemoth pushing towards a committee-centric model.
Best case scenario: this is just a (side-)gig bureaucratic job for the boys, which will largely be irrelevant as far the Rust project itself goes.
Thankfully, that scenario is not implausible.
Not sure what some of these clueless comments in this thread are about. Maybe stop treating every new news item as a connected next episode in a telenovela of grand conspiracies and big betrayal.
There should be a rule against posting from random websites rehashing an original source (and not doing it well, but that's besides the point) then linking to it.
But I guess if this instance cared, it wouldn't have gave space to a reposting spammer to begin with.
ABI is not something that gets "exposed" or not.
Correct.
And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.