I think the other user meant that ls output is not supposed to be treated as parsable, because the tool doesn’t offer any guarantees in that regards.

Shells have built-in support for globbing files anyway. xargs is also not needed. If someone is allergic to using a shell for loop, find always had -exec with ; instead + which wouldn’t trip on too many arguments.

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.

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.

There is a huge difference between vetting packages once every 6 years,

And here the myth shows its head. No one is actually “vetting” 10s of thousand of packages, to a meaningful degree.

And all distros have rolling channels and testing channels, so the every X years part is mythical itself.

In the case of Debian, when is the mythical vetting taking place exactly? Whenever a Debian unstable/sid package gets updated? That’s a rolling repo.
Or is it when world is frozen, and the unvetted packages which lived happily in “unstable” and “testing” will now magically get vetted on their way to “stable”, in a few months (not six years as you imagined).

You clearly lack basic knowledge about what actually goes on in a distro release cycle.

This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.

You missed the point. crates.io is a source registry. Debian ships binary packages (yes, including rust ones).

Where do you think Debian gets source packages for C or C++ from? Did you think they get them in the (physical) mailbox? 🎅

As for dynamic linking, the “security” argument for it has been discussed and debunked. You can search the web for discussions regarding that. Most arguments for .so has been debunked, in fact.

But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.

Nothing is “automatic” when it comes to distro maintenance. Much more so when an upstream doesn’t give a f*** about helping you patch your X years old version. If Red Hat, Canonical, …etc wasn’t actively paying developers to do maintenance, Debian wouldn’t exist as it is. But even then, that only covers a very small fraction of core packages.

The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don’t update them.

Pinning and vendoring are orthogonal.

The original talking points were about source supply chains. But people like you seem to confuse concerns across multiple chains from the individual upstream dev to the binary distro repo mirror.

Pinning is actually the only way to actually (almost*) guarantee that built code would work correctly. What distros sell you is “should work” and “API looks compatible” and “this patch hopefully doesn’t break the interface”.

And more ironically, why distros do is global pinning, so the problem is apparently not pinning itself, but upstreams choosing the pinning themselves, right? right?

“But they don’t fully pin… security updates smth smth”

Good. Let’s continue…

Here is cargo-audit ran against radicle-tui

Good.

The next best thing to pinning is semver-compatible updates.

Now you have an example where you will see that to “fix all CVEs”, you need to run the total of TWO whopping commands.

You ran the first command already. The second is cargo update (or cargo update <only_audit_mentioned_packages> if you want to be more precise.

cargo update only does semver-compatible updates, as released, authorized, and supported by the upstreams, whose knowledge of the code and its interfaces infinitely trumps your random distro maintainer doing raw patching. This is how a coherent competent ecosystem operates.

Some of what the distros do is actually not far away from this. If you looked close enough, you will find that it’s not rare for a stated “frozen” version to be a complete lie, with distro patches effectively updating the distro source package to a later patch, or sometimes even minor version, without changing the version number.

But of course, they wouldn’t tell you about any of that, because the myths must live on 😉.

I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.

While not completely misplaced, your confidence is inspiring 🙂.

Weird how this random thread came back to life, just to rehash some talking points.

See my comments here and here.

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

If you followed the link, you would have seen that nothing actually fishy was found, unlike the implication.

Cargo and crates are basically just as bad as npm, just less popular, which is why they haven’t been hit yet… And it’s currently very difficult to build rust programs without cargo.

The number of actual supply chain attacks actually effecting anybody in the crates.io ecosystem is ZERO. In npm, it’s a weekly occurrence.

less popular

Rust cleared the critical mass and critical relevance milestone years ago. Most people can run desktops without npm or local js code. This is increasingly unfeasible for rust components. And yet, nothing happened. And that’s not a coincidence (read linked threads). That doesn’t mean nothing will ever happen. Nothing is fully fail-safe. But the talking points themselves are completely false.

Also, I would like to see you explain how cargo itself is a problem. It’s a build tool that is not tied to crates.io. You can use different registries, repos, and even full vendoring with it (which you can switch to with one command, and it will just work). But I can’t wait to hear your explanation 🙂. Examples of tools that do it better, with an explanation why would also be appreciated 🙂.

Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers.

This myth is discussed extensively in the linked threads at the start of this comment, especially the second one.

Debian, for example, was not affected by the xz utils backdoor, due to it’s policy of only doing cherry picked security patches, and ignoring feature or bugfixes for the most part.

Also covered in the linked threads. But let’s address specifics.

• Debian unstable/sid (the rolling branch) was affected. Debian is not special.
• Debian stable was unaffected because it runs multi-year old packages. This specific attack was discovered early, so they were spared. Other upstream-controlled attacks could target projected-to-be-stable upstream versions, and remove the compromised part later, reversing that effect (depending on who would discover the malicious code, and what are they testing looking at).
• The stable distro model is broken. Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones. And out-of-date(ness) itself can have adverse affects in other ways. This was always been known/realized by people who know the reality of the situation. But nowadays, “AI” security scanners had a complete mockery of the stable distro model “security” claims.
• Debian’s willy-nilly “security” patching in particular, lead to multiple scandals in the past. This is not all theoretical. One day half the internet had to re-issue SSL certs/keys because of the mythical Debian super security. And on that subject, do you know what distro wasn’t affected by the specific xz attack, despite actually shipping the compromised xz version? It’s Arch. Why? Because they didn’t patch systemd with xz support thinking they can outsmart an upstream.
• Distros pull from upstreams anyway (code has to exist somewhere), crates.io included. So they inherently can’t have better supply chain security than upstreams at the code level, unless you’re also a believer in the popular myth "they review and vet everything ". Some distros may have good/better build security practices. But that’s about it.

I would prefer Java if you cared strongly about supply chain security

What makes you think JAVA or its ecosystem(s) are unique or immune from any of this?

Another hit-and-run Rust thread!

I advise against any more activity here, until, or rather, unless OP appears again.

It’s on the title, you don’t even need to read the excerpt👆.

But more seriously, the excerpt is from the release/tag notes, but what’s quoted above is from the README.

While eventually implementing incremental linking was the inspiration, as already pointed out. It’s actually already faster than mold (see benchmarks).

There is the odd (genuine) security issue tbf. But they are more of the variant:

“If an attacker is close enough to sneak that on me, then I’m probably already screwed.”

Why are you hallucinating facts?

• There is no “team of 200 rust developers”.
• “<lang> developer” is not an identity.
• uutils is not a “professional” project, as in people are paid by the (non-existing) uutils company to work on it.
• The project started as personal hobby of one person during COVID, There were no 200 contributors who sprung up magically and simultaneously from the start.

They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.

If you think you saw a group of 200 people starting uutils and doing this. You should seek medical help.

The “reported upstream” link is broken (fixed link).

mostly compatible with C

It’s not mostly compatible, not even on the surface level, with any version of C post C89. And most of the ever-growing crap in the language came after the early years anyway, with constructs that are C++-exclusive.

compatible with C

myth

I will let you expand on this before responding to both:

And also, cargo.toml has inconsistencies and double-standards.