It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them?

I know that in the domains that I'm interested in, I would be way miserable programming in something like e.g. Java, because I've figured out certain patterns that I know will work in a memory-unsafe language with very little friction, but that cannot be simply be translated to Java because of e.g. reference semantics.

The same probably holds for other approaches to safety, like Rust. I'm not interested anymore in tight opinionated approaches to problem solving. I _love_ void-pointers and memcpy'ing stuff because these let me do abstraction with very low friction. Getting the job done very quickly, with very very low rate of bugs, and those get quickly fixed. (I'm not making a statement about multi-million line projects in corporate environments. This is about the situations that I run into, personally).

> It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them?

Honestly? And this might be a hot take - exactly the same way as I'd explain people rejecting structured programming way back in the day. It was the new thing on the block and people were not used to it, and preferred to just sprinkle GOTOs in their program just like they always used to do rather than learning a new paradigm.

As someone who used to professionally program in C++ on an expert level in the past and now has completely switched to Rust I can tell you that (at least subjectively for me) Rust is way more productive than C++ ever was. Once you internalize how the language works the limitations of Rust just disappear. You learn how to instinctively write code that's idiomatic, and it just stops slowing you down. But it also gives you a ton of new features that end up speeding you up compared to C++, e.g. sum types, pattern matching, cargo, great standard library, destructive moves, proper modules, #[derive], good error messages, etc. Memory safety can also be significant productivity boost because you can (or at least I do) just churn out code without thinking about it too much and just rely on the compiler to make sure that it's memory safe. Can this code trigger use-after-free? Is this iterator valid? What's the lifetime of this pointer? Instead of thinking about all of these you can use those brain cells for something else.

>how do you explain so many programmers still willingly choosing them?

Lack of education + Legacy software / programmers / education material.

It’s also a dumb macho thing. “Real programmers…” Yeah and I bet real home builders don’t use nail guns, prefab sections, or tape measures. They just eyeball it all and use wooden pegs and hammers.