⚠TRIGGER WARNING⚠ two tokio-rs repos (this and toasty) have AGENTS.md files.

exposed ABI

ABI is not something that gets “exposed” or not.

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.

You know bindgen exists, right?

That has nothing to do with what we were talking about. And in any case:

insanely fast

Needs qualification vs. other languages for binaries with comparable runtime performance.

(Hint: you will be surprised.)

with incremental rebuilds

Not special or unique.

and can watch files for changes

Not only not special, but literally exists in all workable build tools. bindgen+build.rs is the Rust version of this.

a c compiler not just using ffi.

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?

and memory safety is checked through unit testing

🤣 🤣🤣🤣🤣🤣

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.

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” ?

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

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.

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.

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.

Code viewing was always a part of rustdoc, and thus available via docs.rs. I actually don’t like this violation of abstraction separation.

And doing this before doing the most obvious sensible trivial addition, a download link, is doubly ironic in my view.

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.

Congrats.

Perhaps no project is more deserving.

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.