That is a pretty lame "poisoning".

What's wrong with the explanation given?

I really don't think these are clearly comparable. I would rather see two more similar projects with comparable functionality that are both attempting to optimize for program binary size.

Busybox ls has 26 flags. GNU ls has 60.

From the busybox "about" page:

The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts.... BusyBox has been written with size-optimization and limited resources in mind.

Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don't think there is a comparable Rust project for minimized utilities.

Slow compared to just chucking everything into a single source file, actually: https://github.com/j-jorge/unity-build

That's only true for clean builds and even then isn't universally true, and of course there are other reasons not to do unity builds. But the existence of the technique, and the fact that historically it has sped up build times enough for various projects to adopt it, does show that the C++ model, with headers and separate compilation units, has some inherent inefficiency.

Do you mean moonshine_save? Does it even provide an API for loading that doesn't return a Result with a possible LoadError?

Rust doesn't generally "throw" errors, it returns them; and generally, function APIs will guide you in the right direction. You generally should not use unwrap() or expect() in your finished code (though the unwrap_or... variants are fine), which means that you must handle all errors the API can return programmatically (possibly just by propagating with ?, if you will instead be handling the error in the caller).

I asked, and it's to replace some of the bits that require Perl: https://hachyderm.io/@notgull/113035157972265244

You can see the full (current) sequence here: https://bootstrapping.miraheze.org/wiki/Live-bootstrap

If you have a Linux or Mac handy, you can trying it out! It's...kinda wild. If you know some Vim commands that start with :, there's a good chance they'll work in ed, except you don't type : itself (effectively you're always in "command mode").

There's also a novelty Twitter account, @ed1conf, that tweets about ed.

Some coworkers told me a story about a previous job candidate who said his preferred editor was ed. They thought it would be really interesting to see someone actually use it. But during the actual interview, when he opened ed, he didn't recognize or understand it; he was actually accustomed to a graphical editor that he thought was called ed because he apparently did all his work on a system where someone had symlinked or aliased ed to a modern tool.

You are making an extreme assumption, and it also sounds like you've misread what I wrote. The "attempts" I'm talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.

I cited one specific measurement, Daniel Stenberg's analysis of the Curl codebase. Here's a separate post about the testing and static analysis used for Curl.

Here's a post with a list of other studies. The projects analyzed are:

• Android (both the full codebase and the Bluetooth & media components)
• iOS & MacOS
• Chrome
• Microsoft (this is probably the most commonly cited one)
• Firefox
• Ubuntu Linux

Do you really think that Google, Apple, Microsoft, Mozilla, and the Ubuntu project "don't even consider onboarding basic static analysis tools" in their C and C++ projects?

If you're curious about the specifics of how errors slip through anyway, here's a talk from CppCon 2017 about how Facebook, despite copious investment into static analysis, still had "curiously recurring" C++ errors. It's long, but I think it's worthwhile; the most interesting part to me, though, starts around 29:40, where he asks an audience of C++ users whether some specific code compiles, and only about 10% of them get the right answer, one of whom is an editor of the C++ standard.

Sorry, are you saying the NSA's information sheet shouldn't have mentioned specific languages? Why not?

If I explain myself or add nuance, it won't be a "hot take" anymore, but here goes...

• I've mostly worked on small teams, but have maintained fairly large codebases (I think the largest single repo I've worked in was about 1.5 million LoC). I've also maintained software used by other teams, though in fairly small software organizations (under 100 developers total).
• I've written code with 100% unit test coverage, and code with almost no coverage. The 100% coverage was in a library that was intended to be core functionality shared across multiple teams.

I definitely agree that they can be useful as both usage examples and as a way to enforce some rules (and consistency) in the API. But I'm not sure I'd go so far as to call that a "spec", because it's too easy to make a breaking change that isn't detected by unit tests. I also feel that mocking is often needed to prevent unit tests from becoming integration tests, but it often hides real errors while excessively limiting the amount of code that's actually being exercised.

I also think that actual integration tests are often a better demonstration of your API than unit tests are.

I haven't used any of these methods as much as I'd like to, but I suspect that each of them is strictly more useful than standard unit testing:

• contract tests (arguably just a form of unit testing, but not the way I've generally seen it done)
• property-based tests
• mutation tests
• preconditions & postconditions (with language support)