Ah yes, because we should condemn people over a statistic, even when the things they do may actually warrant some praise.

I think you’re hitting some good points, but the thing we need to teach these boys is that they shouldn’t be looking towards society for rewards. Society’s rewards have become a gamified rat race, so the way out is men to look inward. Not gonna lie though, that’s easier said than done…

I recently wrote a post too that touches on this topic: https://philosophyofbalance.com/blog/the-emancipation-of-men/

I’m not saying you can’t, but it’s a lot more work to use such solutions, to say nothing about their quality compared to std solutions in other languages.

And it’s also just one example. If we bring multi-threading into it, we’re opening another can of worms where C doesn’t particularly shine.

I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅

Another data structure that you can consider is the red green tree: https://willspeak.me/2021/11/24/red-green-syntax-trees-an-overview.html

We use it in Biome too, and it’s great for building trees that are immutable and yet still need frequent updates, as well as traversal in all directions. Its implementation contains quite a bit of unsafe to make it fast, though as a consumer you’re not really exposed to that.

There is a serious attempt for that actually: https://www.assemblyscript.org/

It doesn’t offer full compatibility with the regular TypeScript though, despite being very similar.

But he did step in, albeit privately. I actually agree an earlier public statement would have helped, but we don’t know the specifics of what went on behind the scenes.

In any case, I don’t think it’s fair to assign blame for Marcan’s burnout to Linus, as the post above did. Marcan himself mentioned personal reasons too when he announced his departure. I think we should show understanding and patience with both sides, and assigning blame isn’t helping with that.

Finding a Webpack replacement that doesn’t use NPM at all is going to be hard, but there are certainly alternatives that don’t require the 1000+ NPM dependencies required to use Webpack.

Some alternatives you can consider are Rsbuild and Farm. Part of the reason they use so much fewer NPM dependencies is because they’re written in Rust, so they’ll have Cargo dependencies instead, but you shouldn’t notice anything of that. Of course if you want to audit everything it’s not that much easier, but at least the Cargo ecosystem seems to have avoided quite some of the mistakes that NPM made. But yes, in the end it still comes down to the extent that you trust your dependencies.

I mean, the actual operation is just an example, of course. Feel free to make it a .map() operation instead. The strings couldn’t be reused then, but the vector’s allocation still could… in theory.

Some programming languages are blindly deemed “safe” in spite of supporting unsafe memory management strategies, and somehow not enforcing those rules does not render them unsafe.

You’re applying a strawman argument here, because nobody is blindly deeming any languages as safe. But they are recognizing some languages as safer than others. Safety isn’t a binary switch, and most people recognize that. Most people also recognize that using tools that make it harder to achieve safety, does, in fact, make it harder to achieve safety. And thus, if safety is important, avoiding those tools makes perfect sense.

I would still like to take a moment to answer your specific questions more directly:

And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.

Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

I think that's only half of the issue, with the other half indeed being use after free. After all, using a reference isn't much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there's a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.

Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Thread safe code is also the issue. The reason people don't have to run from Java is because data races there don't escalate to memory unsafety; they're just caught as "ordinary" exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

It is indeed a dangerous subset, but as I mentioned elsewhere, Rust's borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you're on your own when it comes to safety.

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

They indeed avoid some of the issues, but notably don't protect against use after free at all. And take std::vector as an example:

std::vector v;
v[2]; // out-of-bounds access

vs.

unsafe {
    let v = Vec::new();
    v[2]; // panic
}

Even wrapped in unsafe, the Rust equivalents are still safer.

I’m learning c++ via exercism because I’d like to use it for game development and other high performance use cases, and because it’s a good pip for the resume.

I think for game development you don't need to worry about a shortage of C++ opportunities any time soon. Both Unreal and Godot are built in C++ as well as many in-house engines. Similarly, there are other niches where C++ is king and it would decades for that to change.

That said, there are certainly areas where C++ is already being replaced by Rust. Areas where both performance and security are important are the first movers, such as webbrowsers, operating system components, but also things like high-frequency traders (crypto ones almost exclusively use Rust, while traditional ones will move slower).

Personally, I also used to be heavily invested in C++, but I'm happy to have moved to Rust myself. I recently became an independent contractor, and while I would be happy to take contracts involving C++ to migrate them to Rust, I would certainly not start new projects in C++ anymore. But for you, I wouldn't worry about that yet. The experience you gain working with C++ will help you appreciate Rust more down the line. Just keep in mind that at some point you will be likely to be exposed to Rust too.