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.

It would be a valid point if he weren't literally speaking over the people trying to tell him that they're not demanding he learn Rust: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548

Oh jeeze, you have no idea. You can watch it yourself: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548

That timestamp is about where the audience member (a maintainer of ext4 and related utilities) starts speaking. The "here's the thing" quote is around 28:40.

You get admin privileges on MacOS like a big boy. You can use bash or zsh commands in Terminal all you want.

Cool. So try updating to a version of Bash from the last 15 years, because the pre-installed one is Bash 3, because Bash 4 and 5 are under the GPLv3 license, which Apple won't comply with.

...ah, no, you can't update the pre-installed Bash, because it's on a section of the file system that is read-only even with admin access. You can install Bash 5 as a separate shell, and use that as your default terminal shell, but any scripts written with the standard #!/bin/bash instead of the more flexible #!/usr/bin/env bash will still use Bash 3.

This "handholding" (or really, a safety net) is arguably a good thing, or at least a positive tradeoff; but you can't claim it doesn't exist.

The trope will be "old" once the mainstream view is no longer that C-style memory management is "good enough".

That said, this particular vulnerability was primarily due to how signals work, which I understand to be kind of unavoidably terrible in any language.

I was a professional C++ developer for several years, and came to the conclusion that any professional C++ developers who don't acknowledge its flaws have a form of Stockholm Syndrome.

That's true in C as well, though. This is what people mean when they say things like "undefined behavior can result in time travel".

The difference is twofold:

• Rust's rules for valid unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.
• Because safe Rust is so strict about what it permits, the compiler is able to make more aggressive optimizations; in theory, this could indeed cause undefined behavior to be "worse" at runtime than a comparable situation in a globally-unsafe language. I'm unaware of any actual examples of that phenomenon, though.

To play devil's advocate, most systems programming can be done even with a garbage collector. Midori was a project to build an operating system on a variant of C#, and although the garbage collector did impose technical difficulties, it wasn't a dealbreaker. Go isn't usable everywhere Rust is, but it can in fact be used for many things that previously would have been considered "systems" niches (which is part of why there was a somewhat prevalent misconception in the early days of Rust that they were similar languages). Prominent D developers have defended D's garbage collector (even though it's technically optional). Bjarne Stroustrup, the creator of C++, used to express great confidence that C++ would one day have a garbage collector.

...but you're right, Rust and its rise in popularity (and, conversely, the C++ community's resistance to adopt anything with garbage collection) have definitely narrowed the common definition of "systems programming" to exclude anything with a "thick" runtime.

The author also makes some incorrect or misleading claims, specifically about emacs. I acknowledge there's a high bar for entry there and don't personally like emacs, but it's not modal, and it does have the ability to display images and markdown previews.

I know several world class programmers, and interestingly, the commonality among them is that they all seem to use Vim as their code editor. Many people I know who think of themselves as world class programmers use Emacs.

What a burn!

Rust's 1.0 release (i.e. the date on which the language received any sort of stability guarantee) was in 2015, and this article was written in 2019. Measuring the pace of feature development of a four-year-old language by its release notes, and comparing against a 50-year-old language by counting bullet points in Wikipedia articles, is absolutely ridiculous.

Yes, younger languages adopt features more quickly, and Rust was stabilized in a "minimal viable product" state, with many planned features not yet ready for stabilization. So of course the pace of new features in Rust is high compared to older languages. But Wikipedia articles are in no way comparable to release notes as a measure of feature adoption.

I think C is faster, more powerful, and more elegant.

"More elegant" is a matter of opinion. But "faster" and "more powerful" should be measurable in some way. I'm not aware of any evidence that C is "faster" than Rust, and in fact this would be extremely surprising since they can both be optimized with LLVM, and several of the features Rust has that C doesn't, such as generics and ubiquitous strict aliasing, tend to improve performance.

"Powerful" can mean many things, but the most useful meaning I've encountered is essentially "flexibility of application" : that is, a more powerful language can be used in more niches, such as obscure embedded hardware platforms. It's really hard to compete with C in this regard, but that's largely a matter of momentum and historical lock-in: hardware vendors support C because it's currently the lowest common denominator for all hardware and software. There's nothing about Rust the language that makes it inappropriate for hardware vendors to support at a low level. Additionally, GCC is probably the toolchain with the broadest hardware support (even hardware vendors that use a bespoke compiler often do so by forking GCC), and Rust currently has two projects (mrustc and gccrs) working to provide a way to use GCC with Rust. So even the advantage C has in terms of hardware support is narrowing.

But note that there are also niches for which C is widely considered less appropriate than Rust! The most obvious example is probably use in a front-end web application. Yes, C should in theory be usable on the front-end using emscripten, but Rust has had decent support for compiling to WebAssembly almost as long as it's been stabilized.

The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.

Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.

Go sacrifices too much for superficial simplicity; but I would like to see a language that's nearly as easy to learn, but has a better type system and fewer footguns.

Unit testing is often overrated. It is not good for discovering or protecting against most bugs.

Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.