You’re not wrong, but not everything needs to scale to 200+ servers (…arguably almost nothing does), and I’ve actually seen middle managers assume that a product needs that kind of scale when in fact the product was fundamentally not targeting a large enough market for that.

Similarly, not everything needs certifications, but of course if you do need them there’s absolutely no getting around it.

In case you’re still interested in this type of resource, here’s another one I just learned about: https://google.github.io/comprehensive-rust/

It’s by the Android team at Google, and while it doesn’t require knowledge of C++, it seems to be intended to bring devs up to speed on the concepts required for using Rust in Android and Chromium.

Wow, I definitely should have google that myself before asking, but thank you for explaining and calling out that data point.

I honestly think that shows that it was in fact a bad idea to assign TLDs to countries. Having a country code acronym with a popular tech meaning is essentially just luck of the draw, so they’ve basically just arbitrarily given a few small countries a valuable resource to sell. I guess that benefits those countries, but I doubt “quasi-random fundraising for small countries” was ever the intent.

But do they actually have autonomy, give that random companies can use .io and .ai? Or did the British Indian Ocean Territory and Anguilla approve all such uses of those domains?

Why top-level, though? Why not amazon.in.com?

Obviously this isn’t specific to Rust, but frankly it’s bizarre to me that ICANN chose to tie top-level domains to country codes in the first place. Languages might have made sense, but a major feature of the internet is that it’s less beholden to political boundaries than most of the physical world is.

I was hoping this might start with some actual evidence that programmers are in fact getting worse. Nope, just a single sentence mentioning “growing concern”, followed by paragraphs and paragraphs of pontification.

Yeah, that part is pretty wild and definitely Microsoft’s fault.

The Crowdstrike problem was in fact a Crowdstrike problem. It affected Linux too, but of course there are vastly fewer users of Crowdstrike on Linux: https://www.google.com/amp/s/www.theregister.com/AMP/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

This is pretty obviously a Microsoft problem.

What were the issues you’ve had with WSL? I’ve been happily using that for a while now.

I agree with everything in the article, which makes it all the more unfortunate that I really detest Go as a language.

(It’s getting better, though.)

I hear you, but here’s my experience:

I’ve had one coworker whose personal coding style actually somewhat resembled that in the Clean Code examples. He wrote functions as small as possible, used many layers of abstraction, and named everything very verbosely and explicitly.

Now, to be fair, I don’t think he did that because of Clean Code, and he also didn’t follow most of the good practices that Martin recommends. Most egregiously, he almost never tested things, even manually (!!). He once worked an entire weekend to finish something that I needed for my part of the project, and when he was done, it didn’t work, because he hadn’t actually run it at any point (!!!).

But even when his software did work, it was horrendous to navigate and modify, specifically because of that style of writing code. I know, because when he retired, I was the only person on the team who could deal with it, so his part of the project fell entirely on me.

Now, I’ve also had to work with code that had the opposite problem: short names, no abstraction. And a sort of “worst of both” codebase where the functions were exceedingly long and full of near-duplicate functionality, but overall there was a fair amount of modularity and abstraction.

But in my opinion, it was much harder to deal with the code that hid all of its weirdness behind layers and layers of abstractions, despite those abstractions being carefully documented and explicitly named.

That’s great, but surely, from time to time, you have to deal with code that other people have written?

I’m a Rust fan, and I do think they eventually struck a pretty good “visibility vs noise” balance with ? (which was highly controversial at the time).

It’s not a strawman, though, because Martin’s actual example code in the book is like this, including a full module he rewrites toward the end.

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.