Hacker News Reader

Comment by jcranmer | Hacker News Reader

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities.

This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust (https://github.com/uutils/coreutils).

More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic. Especially considering that the gate in question has already been thoroughly breached by the language in question (some universities have switched to using Rust in their OS courses, for example).

View on HN

There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on.

I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't seen any serious projects to implement POSIX compatibility. The Rust coreutils project is a good start but from their readme it looks like they are more aiming to achieve GNU compatibility on Microsoft Windows while being MIT licensed — I don't think anyone is seriously using it to build a BSD (or even a GNU) distro. If I'm wrong about that I'd love to hear it though. Rust is a good choice to write these things in but let's be realistic about the time frame required to rewrite everything.

Plus I just downloaded those Rust coreutils and tried to build it and now I'm waiting for 400 (!!!) Rust dependencies to download and compile. Is this really appropriate for a core system component to have this many dependencies? Or is there something I'm missing here? I admit I am not familiar with best practices in Rust. As the project stabilizes I assume they will want to start eliminating the dependencies or vendoring them upstream? At what point do we decide to put these into a separate library like libbsd or gnulib?

> Is this really appropriate for a core system component to have this many dependencies?

Absolutely not. The entire OpenBSD base system can be built without an internet connection.

after you are done downloading all the source.

You can check that the source hasn’t been tampered with before starting the build, and know you’re building the right code base.

Builds that curl junk and use a dozen language specific package managers don’t have that property.

That is exactly the set of properties you get with Rust and Cargo: that the source hasn't been tampered with, and that you know you're building the right codebase. It would be deeply irresponsible to build a package management system without those properties.

True enough... but you still don't know what the dependencies do. E.g., one added ads. Another added use tracking. This could even be legitimately in line with the dependency's purpose.

Unless you're manually vetting all the code, 400 dependencies means trusting a lot of third parties.

Trusting a lot of third parties is almost as irresponsible as not bothering with checksumming, etc.

See npm and pip for examples. I suspect cargo will have its share of incidents over time, unless it is somehow curated by a small group that tests and maintains the packages, but if it is, then it’s comparable to apt for c/c++.

This is one of those things that's strictly true, but is kind of misleading because it doesn't capture the full picture. In particular, there is actually no guarantee that the source code you see on GitHub matches the source code you compile from crates.io. Now, most responsible maintainers tag each release and publish exactly that tag to crates.io. Which is good. But that's just a convention. There's nothing enforcing it.

If you want to actually review the source code, then you'd have to download the crate archive itself and review the code there. There is some tooling for this (notably, cargo-crev), but it's definitely not a normal part of development in the Rust open source ecosystem as it stands right now. For the most part, trust and reputation hold the system together. For example, imagine what would happen if someone found malicious code in one of my crates that I was duplicitous about (i.e., published it on crates.io but kept those code changes off of GitHub).

You're right.

I've heard from reliable sources that this is actively being worked on.

That assumes every user is a developer, expert in security assessment, knowledgeable in tricks like trusting trust, and all the languages used in the code base.

You can also build Rust and its ecosystem without an internet connection. It works the same way; you need to get a copy of everything first, but the build itself does not require the internet.

(This has been a hard constraint for effectively forever, because both Firefox and Linux distributions have this requirement.)

I understand that if you have all dependencies locally, you don't need to download more dependencies.

I understood NotAPlumber's remark as: openbsd has no third party dependencies. In other words: there is one party to trust, not 400.

If I misunderstood the BSD case, I'd love to hear it.

I don't think you miss anything.

POSIX compliance is a headache which is not only hard to get right but also strongly limits your interfaces and internal tooling.

Many scripts still will run with non full compliance, but that doesn't help if you try to build for OpenBSD.

Also I'm not sure how they ended up with 400 deps for coreutils. I would have expected much less. But yes this means at least until better code signing and so on is the default this isn't at all appropriate for the base of any OS.

I just which the author would have written it a bit less mean in it's wording. (Probably was just annoyed, but sill).

The author is from the 1990s era of Linux / FOSS, before kindness was part of the culture, when the culture had a tough competitive streak where mistakes and humility were seen as signs of weakness and disrespected. High expectations wee tightly bound with low levels of patience. And many people were scared off from contributing.

> POSIX compliance is a headache which is not only hard to get right but also strongly limits your interfaces and internal tooling.

Platforms which are POSIX compliant usually offer extensions and then allow for selecting actual POSIX-compliant behavior. It's not a very strong limitation if you're already fairly close to that anyways.

Most scripts don’t depend on the POSIX standards anyway, they depend on GNU or BSD programs. CPython’s configure script, for example, blows up if the system grep is BSD and not GNU. The whole C build ecosystem is duct tape anyway and things rarely build without tons of manual effort (figure out what versions of which dependencies need to be installed to which locations in the file tree and then maybe things will build, but none of it will be documented and good luck reverse engineering those Autotools/CMake scripts!), so citing concerns about breaking things seems really disingenuous.

I believe a main point of the article is that while linux might be fine with this state of affairs, OpenBSD is not and actually care about having a specific standard.

To replace anything in OpenBSD, you need way more than POSIX-compliance -- you need OpenBSD-compliance. Which means every non-POSIX option has to be implemented down to edge cases, every departure from or controversial interpretation of POSIX (POSIX is vague in many places) has to behave exactly the same. Or you'll definitely break scripts.

These nuts don't understand OpenBSD's base doesn't map to GNU coreutils, it ships SEVERAL more tools. They are so GNU and Rust blind they don't get anything.

.ls -1 /bin/ /sbin/ /usr/bin/ /usr/sbin/ | sort -u | wc -l

Good luck reimplementing that.

> Or is there something I'm missing here?

There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downloaded.

One thing that may be skewing the count is that internally coreutils is packaged with one crate per command. There are about 100 commands, so you'll have seen at least that many separate crates building. They're listed here: https://github.com/uutils/coreutils/blob/6e8c901204934029c88...

My impression is that ecosystems where tracking dependencies is hard tend to discourage them, while ecosystems where tracking dependencies is easy encourage them. The coreutils crate depends on separate md5, sha1, sha2, and sha3 crates, if managing external dependencies was hard I imagine those would be bundled together. But it is easy, so it makes sense to organise the crates so that each just provides one specific piece of functionality. Think single responsibility principle applied to packaging.

Urgh, that's just a verification nightmare waiting to happen. Who is going to wade through all that mess, review every package, pin its version etc...? You need reproducability before you can get safety and security.

Cargo uses lockfiles by default to pin all dependencies of an application, so reproducibility shouldn't be much of an issue.

No one reads lockfiles. In python, people have successfully backdoored projects by sending a PR that upgrades a dependency and regenerates the lockfiles.

Somewhere in the 1MB lockfile patch, they pin a dependency to a version with a known remotely exploitable flaw (sometimes a zero day, sometimes not).

If you care about security, api stability and legal compliance, you should minimize the number of developers and packages you trust. My rule of thumb is that, for a team of ~10 developers, each package dependency adds a week or two of developer maintenance time each year or so.

Having a dozen packages where one will do, and having them do the same thing recursively means you need to spend 144 times longer dealing with such things.

Why is number of packages and not package size the relevant metric here? Especially when all the packages live in the same repository, there's practically no more overhead to review each package qua package, versus just a bunch of directories in a package monolith.

This "144 times longer" number seems pulled completely out of thin air.

Both are relevant. To their point, each additional maintainer is also a hidden dependency of each package, so the number of packages is relevant.

In the case in question the dependency count as crates is separate from the dependency count as git repos. In this case things that would normally be one big library where split in many different functional crates in the same repo.

Twelve packages with twelve dependencies each is 144. I’ve seen >10x this level of blow up on multiple products at multiple companies.

One company missed installing malware behind all the firewalls of most of the fortune 500 by less than a week.

We made a procedural change to the build process of a product that had been shipping for years.

The change hit our CI/CD 5 days before one of the big language package managers started spewing malware at us.

Package maintainer count bloat is a serious real world problem.

Ignoring it is negligent.

I'm not suggesting that we should stop reviewing dependencies. I'm pushing back against the idea that internally structuring a large repo or project via independent modules necessarily explodes the burden to review.

It may be the case that this preference for well modularized code leads to lots of disparate small packages in the ecosystem, but within the scope of a single project, I see no reason why modularization poses any intrinsic risk.

Rust dependencies are just compilation units. Do people complain when a coreutils-scale project ultimately depends on 400 .c (and/or .o) files?

Actually you did miss something.

Thinks like `cargo tree | wc -l` or the number of dependencies cargo builds are not appropriate as they count _internal_ dependencies (from the same repo).

Given that it's split into many "sub-crates" in the same workspace this will make the numbers unnatural high.

Or with other words _most_ of the 417 "dependencies" for building the "unix" feature set are internal ones in the same repository. I.e. the project is just split up into many small parts.

Additionally many deps are reused between many internal deps.

Removing duplicate dependencies, dev-dependencies (e.g. testing tools) and build dependencies less then 100 deps are left.

Looking through them many are rust versions a C/C++ libs which are "available per default", like e.g. unix_socket, libc and similar.

Then some are thinks which come from rust deps being split up more, e.g. there are md5, sha1, sha2, sha3 as separate crate.

There are also a bunch of "internal" deps of deps e.g. backtrace-sys.

Anyway still a lot of deps but most are quite reasonable and could be "taken care of" in some way or another if they want to ship a distro based on this.

His statement was that there was "no attempt" to write POSIX tools. As a "statement of fact." Irrespective of how much work there is still to do for coreutils in terms of compliance, they are an attempt. They may be be completely unsuitable as a drop-in replacement right now, but that was not the "fact" that he asserted.

Somewhat academic as I have no dog in the fight, but ...

> To actually achieve POSIX-compliance is not an easy task and requires lots of testing.

Why are the existing tests not enough for a new implementation?

Sweet summer child, imagining OpenBSD has comprehensive tests? This is UNIX, old-school. If it seems to work, it works.

He's a maintainer, gatekeeping is literally his job. He's the one who decides what makes it in or not.

His reply is not great, but IMO posting to some venerable old project's ML saying, in the abstract and without actually having made any effort to analyze the issue in depth "Under what conditions would you consider replacing one of the current C implementations with an implementation written in another, "safer" language?" comes off as rather rude and not very productive IMO. I can understand him shutting it down immediately instead of wasting his time arguing with programming 101 students who cargo cult Rust without understanding the reality of maintaining something as complex as OpenBSD.

Some substantive comments I read from the mail:

* It takes a long time for a rewrite to be fully compatible and a good implementation. This project says it uses the busybox tests and that seems like a good start. Is it good enough though? Busybox itself is quite good for certain embedded niches but it would be absurd to replace a good chunk of OpenBSD userland with that, the usability would suffer a lot.

* OpenBSD needs to compile itself, in reasonable time, and at the time of the writing rust was slower than C at this and could not self host on 32bit x86 due to address space limitations. Has it been fixed?

> Busybox itself is quite good for certain embedded niches but it would be absurd to replace a good chunk of OpenBSD userland with that, the usability would suffer a lot.

Not to mention that Busybox (last I checked) uses a license unsuitable for inclusion in OpenBSD (which is trying to reduce the amount of GPL-licensed software in the base install).

> the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic.

He's not gatekeeping in that way by saying that Rust isn't used to create OS utilities (which as an aside is what he actually says. He doesn't say anything about building an OS) and therefore isn't a serious language and therefore shouldn't be included in OpenBSD*. He's saying it's not used for making OS utilities and therefore has no specific use in OpenBSD that requires it to be in the toolchain. Very different points with the latter being pretty reasonable, imo.

The post was written in 2017. How far along was the project in 2017.

Also, I am a bit confused about the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic.? Which line in the e-mail stated that?

The gatekeeping is strongly implied by this statement:

> As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.

Which I read in the tone of "go play with your toy language somewhere else, and let the real programmers program with real languages. Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts."

That tone seems more you than Theo. OpenBSD isn't known as a first mover operating system for new technologies. If the utilities are rewritten and not compatible then it really isn't a rewrite, its a new program with the same name as a previous program. Frankly, if they don't implement that standard, they aren't serious replacement efforts. They could be useful and maybe the options omitted aren't important to the person implementing it, but they are not suitable to replace the current utilities.

> As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.

That doesn't imply "real programmers program with real languages". It implies they're not used to enrich the UNIX / open source ecosystem, which might imply there's not a real need for them in the official repositories, since they're not used to build anything else in the repository.

> Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts."

There is real value in being "POSIX-compliant". It means programs respect an interface. If I write a script that uses "grep" or "find", I have strict requirements from them. I expect them to take certain arguments and interpret them in a certain way. If I can't simply replace "grep" with "haskell-grep" and get the same results (with stronger safety guarantees or performance), I may not have a use for them in certain scenarios.

The critique that "They are completely different programs that have borrowed the names." doesn't imply "they can't be taken serious", it implies they can't be used to replace the existing ones.

There is gatekeeping here... but it's not implied, it active and out in front. The entire conversation here is whether Rust code is going to be permitted through the gate of the OpenBSD base system. You don't have to parse through implications to find the gatekeeping, it's the topic of the conversation.

I think it's OK for platforms to have principles and if those principles are going to yield anything of value you have to be fairly consistent and ruthless about them.

There was a little bit of editorializing there but if 'base builds base' is table stakes then start working on that coreutils project first.

> the gatekeeping implied here [...] is really toxic

It's Theo de Raadt, toxic rhetoric is sort of his brand.

But... he has a real point here. It's not about grep or cat or whatever really, those are just the use cases for which OpenBSD would care.

It's that as Rust is reaching the second decade of its history, and despite some outrageous wins in press, evangelism, and general developer mindshare... Rust just hasn't made much progress in replacing exactly the software that it claims to be intended to replace!

Where are the pervasively used compression libraries in Rust? Video and audio codecs? Network stacks? Database engines? System management utilities? PKI and encryption stacks? All that stuff is still in C. After ten years of Rust success!

It's not like no one is using Rust. It's not like it doesn't have success stories (even in the categories above). But they're comparatively rare, still. There's nothing in Rust that rises to the category of "stuff everyone just uses because it's what everyone uses" (c.f. zlib, libjpeg, readline...) yet.

And if there isn't after the first decade, what needs to change to make it happen in the second. I mean, is it maybe fair to say that the window is closing for rust to take over a significant fraction the systems programming world?

> It's that as Rust is reaching the second decade of its history

Sort of. It's only been five years since it was actually stable enough for production use. (with a few exceptions of folks who were really invested)

And:

> Where are the pervasively used compression libraries in Rust? Video and audio codecs? Network stacks? Database engines? System management utilities? PKI and encryption stacks? All that stuff is still in C.

How many of those projects in any language are less than five years old? The ubiquitously used stuff is mostly much older. But among the projects which are that young, Rust has substantial representation.

" There's nothing in Rust that rises to the category of "stuff everyone just uses because it's what everyone uses" (c.f. zlib, libjpeg, readline...) yet."

IMHO, that's basically not possible, so it isn't a fair ask. If the Rust community produced a drop-in replacement that is every bit as good as readline in literally every way... still nobody would switch, because why would they? What's the benefit? You spend all this effort just to trade evenly across. If the Rust community produces something better, nobody's going to use whatever those extra features are outside of Rust itself.

This is the category of software that will be last.

The question for Rust, and equally, every other ambitious language, isn't really "What percentage of existing code will be rewritten in this new language?" (And by "rewritten", I don't just mean "reimplemented but only your community uses it, but in the sense you mean... it actually replaces the original.) If your answer is any number significantly over zero, that itself represents entrance into the absolute top tier of languages... this is very rare. The question for Rust et al is "What percentage of future code will be written in your language?" On that front, Rust is still on a pretty decent trajectory.

> IMHO, that's basically not possible, so it isn't a fair ask

Is it not? There is software in that category written in the last ten years (not as much as in the preceding decade, obviously). How about Docker? V8/node? Most of the wasm ecosystem dates from that period. Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too.

Rust didn't hit any of those sweet spots. And I think we should maybe be spending more time asking why.

At a guess because it is much easier to yell from the sidelines than to be exposed with your stuff out in production across major installations. Maturity of code is measured in blood, bugs and overtime, regardless of what language it is written in.

"How about Docker? V8/node? Most of the wasm ecosystem dates from that period."

Not a replacement of any previous tech, not a replacement of previous tech, and not a replacement of previous tech respectively. You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing. It is "zlib, libjpeg, readline" I was suggesting is far too high a bar to clear to say a language is succeeding; I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages.

I don't even know what it would take for a language to actively replace C in those positions. What could a language possibly offer to overcome the cost of throwing all that code away?

"Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too."

This is closer to valid, but still a huge ask. Rust may not have done it but neither did anybody else; SSL is still C.

Now you've shifted the question from "Why doesn't Rust successfully replace existing tech?", which is what I was saying is effectively impossible, to the question "Why doesn't Rust have a killer app?". This is a fine question to ask; I don't attack you for asking it. I'm merely defending my original characterization.

Still, I suspect Rust is like Go; while there is definitely a significant set of apps now that are implemented in Go that people use because they are the best-of-breed and not because they are Go, I expect that usage is dwarfed by usage of Go that you never see. I see Rust coming up around me in places where it's just happening organically, unrelated to HN.

> You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing.

They're all parsers of foreign input. Somethings which C is extremely fast at, but also extremely dangerous at doing.

> I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages.

But did other languages have the same ambitions ?

As I understood, Rust wanted to be safer but just as fast as C. Which would make it an ideal language to replace those input parsers. It's a pity that still hasn't happened because we'll still be seeing plenty of CVEs for those libs..

I agree UNIX base is not its niche.

But take a look on Firefox:

* Video and audio codecs - MP4 metadata parser, Audio backend

* Database engines - key-value storage backed by LMDB

* Network stacks - A QUIC implentation, SDP parsing in WebRTC

* PKI and encryption stacks - TLS certificate store

* And more https://wiki.mozilla.org/Oxidation

Just five years since first stable release.

It's not ten or 20 years, the first release of Rust was in 2015. Pre-1.0 Rust was a wildly different language, with green threads, segmented stacks, regular and wild breakage, not really a C replacement! Please understand this point.

But anyway here are some projects:

https://github.com/ctz/rustls a TLS library that uses https://github.com/briansmith/webpki a pki library

https://github.com/burntsushi/rust-snappy a compression library

https://github.com/tikv/tikv a database engine

https://github.com/hyperium/tonic a gRPC library

https://github.com/tock/tock an embedded OS

https://lib.rs/command-line-utilities lots of CLI utilities which include system management

You ask for "pervasively used" but this is not under control of Rust itself. It's not feasible to replace decades old setups in five years.

The most widely deployed Rust stuff is in Firefox and some Gnome libraries AFAIK.

> I mean, is it maybe fair to say that the window is closing for rust to take over a significant fraction the systems programming world?

I don't see why this should be the case.

You make valid point, but you can't fault Theo for predicting a different future in 2017.

https://github.com/uutils/coreutils/commit/d4e96b33e34373399...

I read 2013, Theo de Raadt's email is from 2017, over 4 years later. I think we can fault him for being overconfident and not checking his facts.

That commit doesn't have any files in it. The first release of "uutils coreutils" appears to be this:

https://github.com/uutils/coreutils/commit/511f138e3856e2d69...

which is only twenty days young, and a 0.0.1 release to boot (whatever that means).

The first four utils were added 7+ years ago: https://github.com/uutils/coreutils/commit/9653ed81a2fbf393f...

This has been developed for a while. You're looking at the official GitHub releases which doesn't mean much. It just means they just started providing official compiled releases. Not all projects even do that at all.

I know a lot of people getting into Rust, including myself, started reading through this repo. This was one of the first good real-world examples of Rust, that I found.

> You're looking at the official GitHub releases which doesn't mean much.

Fermat would like rust then.

> There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities.

There was an attempt, that started over 4 years earlier, and if I understand correctly that attempt was pretty far along when this email was written. We can argue over definition, but I'm pretty sure he wouldn't have written this if he was aware of this project.

There are POSIX implementations in Ada since the mid-80's.

Yes, and 2017 should be in the title of the post.

There is nothing sinister being implied by wishing to maintain the course that the OpenBSD project has taken. This leadership may not please all of the people all of the time (least of all non-dependent external projects), and it has no obligation to do so.

Do any major Linux distros think uutils is good enough to ship as the default? Are they at all involved?

They'd be infinitely easier to persuade to try something like this than a BSD. For OpenBSD it's probably always going to be a non-starter because of all the hardware they'd have to leave behind.

BSD does not use GNU coreutils. Is it really unexpected that the developer of a BSD project might have been unaware at the time of a project attempting to replace it, or simply found it incompatible with the stated requirements-- POSIX compliant base utilities. OpenBSD does not care about compatibility with GNU, for example longopts do not work for many utilities, with exceptions to permissive replacements to historically used GNU utilities (grep example).

It also does not address the concerns of higher build times compared the contemporary C counterparts, which also support far more platforms than Rust.

The use of cargo for example suggests that at least a few uu utilities makes network connections at build time to fetch dependencies!

For example something as simple as chown:

https://github.com/uutils/coreutils/blob/master/src/uu/chown...

The use of cargo implies this no more than the use of make. One can fetch all dependencies and then build in a completely offline manner.

>the gatekeeping implied here is really toxic

The words 'gatekeeping' and 'toxic' are toxic.

Agreed, and it's even more toxic to use "gatekeeping" in this fashion for somebody who is LITERALLY a gatekeeper for the project under discussion.

Linked mailing list message is from 2017, which is may be after when the linked project was started/viable.

No need to speculate, if you follow the GitHub link you'll see that the project is older than 2017.

How many utilities were rewritten and shipped at the time of the post?

79 by my count, but I'd be happy to have someone correct me.

https://github.com/uutils/coreutils/tree/ef4d09ee3c067c280ba...

It looks to me like the only changes in that table since November 2017 are that `join` and `df` were moved from 'todo' to 'semi-done'.

Are they done, or did they move onto to something else?

I don't know.

You’ll also see that cp, ls, expr, test, and others are still only considered semi-done.

uutils was started in 2013, and was decently complete well before 2017.

Your definition of "decently complete" and Theo's are likely to be waaaaay different... and within your respective contexts, you are both correct.

Not only that, there are several POSIX implementations in Ada.

They just don't get exposure in FOSS land.

Is it 'really toxic', or just uninformed? Note that the email conversation was from a few years ago.

I'd say toxic. When you point out that "nobody has done this" in this way, there is a strong implication that it's not possible, not reasonable, or not wort the effort.

Rust explicitly aims to be a systems language. It explicitly challenges C and C++ on their own turf. Implying that it's not suitable for serious systems work is insulting.

> Note that the email conversation was from a few years ago.

Remember that the project he said didn't exist was 4 years older than his email. And if I understand other comments correctly, that project was well known among Rust practitioners.

He made strong claims outside his area of expertise. An easy mistake to make, but one that has consequences when you're this famous. Such mistakes are totally fine in private, but in public… they're a little toxic.

Meta: if someone could explain to me where the 5 downvotes come from, I'd be curious to know which part of my comment triggered them.

Is Theo de Raadt above criticism? Is Rust actually failing at its primary goal? Are words like "toxic" and "insulting" under a soft ban? Right now all I have to go by is a dead flagged strawman from a throwaway account.

Don't worry about it. My comment seems to be up and down like a yoyo.

Arguably, someone in that position speaking so definitively while also being uninformed, is at least a little "toxic."

Not only does coreutils exist there is also another think which shouldn't be forgotten.

When you re-write a tool, _why not improve it_? (Especially if the chance that the 100% backwards compatible rewrite will not be accepted anyway).

For a bunch of tools exactly this happens, a new tool which provides the (roughly) functionality but a new (IMHO often better) interface, slightly different options or syntax (for got reasons). Etc.

An example for this is ripgrep (rg), which already became a widely used replacement for grep. It's just not a drop in replacement. (It couldn't do what it does if it would be).

Reply on news.ycombinator.com