BatmanAoD

The whole book is like this, though, and these are specifically supposed to be examples of "good" code. The rewritten time class toward the end, a fully rewritten Java module, is a nightmare by the time Martin finishes with it. And I'm pretty sure it has a bug, though I couldn't be bothered to type the whole thing into an editor to test it myself.

Because abstractions leak. Heck, abstractions are practically lies most of the time.

What's the most time-consuming thing in programming? Writing new features? No, that's easy. It's figuring out where a bug is in existing code.

How do abstractions help with that? Can you tell, from the symptoms, which "level of abstraction" contains the bug? Or do you need to read through all six (or however many) "levels", across multiple modules and functions, to find the error? Far more commonly, it's the latter.

And, arguably worse, program misbehavior is often due to unexpected interactions between components that appear to work in isolation. This means that there isn't a single "level of abstraction" at which the bug manifests, and also that no amount of unit testing would have prevented the bug.

I should have stressed the "opinion" part of "IMO". What I mean is that, when I read this, it struck me immediately as being exactly correct: https://joeduffyblog.com/2016/02/07/the-error-model/

The problem is that most languages with exceptions treat that as the idiomatic error mechanism. So checked exceptions were invented, essentially, to do exactly what you say: add the exception type to the function signature.

Having separate errors-as-return-values and unwinding-for-emergencies is a much more recent trend (and, IMO, an obviously good development).

Yes. True. But Uncle Bob literally complains about non-nullable types in the linked blog post.

I'm not saying testing isn't important. I'm saying that hand-written unit tests are not the end-all be-all of software quality, and that Uncle Bob explicitly believes they are.

The blog post? Yeah, that was the moment I lost most of my remaining respect for his tech opinions.

Unlikely, unless his view has changed substantially in the last seven years: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.

(To be clear, I realize you're kidding. But I do think it's important to know just how at odds the TDD philosophy is from the "safe languages" philosophy.)

The phrasing "available on servers" does seem quite weird. It does seem that having a single, standalone binary is much easier with Rust than with C++, though.

Oh, right, yes; of course it statically links the standard library. I was thinking of the fact that the standard lib is precompiled, but yes, it's statically linked.

In this context, stabilization refers to the adoption growth curve flattening out.

There is nothing specific in the rust port that makes fish more available for servers or LTS distros.

Being written in Rust does improve availability, because by default Rust statically links against everything except libc, and you can opt out of that if necessary. So there is inherently no need to build separate dependency packages for each distro, unless you use a Rust crate that specifically links to a C or C++ library.