Why I rewrote the mesh generator of Dust3D from Rust to C++

I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I understood why it couldn't tell. Usually, when I hit it, it is because I forgot a case and am grateful for it. I know of at least one optimization I've made that I would never have bothered with without the borrow checker. It would have been too much bother for me to reason about everything. Even if I did, it would have been even worse to maintain.

Everyone can do statistical problem solving. At least everyone who can talk. What you do is that you start making sounds when you're an infant and then you receive positive or negative feedback. This continues until suddenly you know how to talk.

Similarly, in industrial chicken raising you need to differentiate between male and female chicks right after they're born. However, there isn't any guide to determine the difference. Instead what you do is that you take one person who knows how to do it and pair them with someone who doesn't know how to do it. The person who doesn't know how to do it will guess at the sex of the chick and they will be corrected by the person who does know how to do it. After enough time you have two people who know how to do it.

Sounding familiar yet?

Most people learn programming languages in a statistical fashion. They try a bunch of stuff and get positive or negative results (compile fails, runtime errors, etc). However, just like determining whether a chick is a male or female in the chicken raising industry, nobody can really give you the specification of how to program. All they can do is tell you that you are doing it wrong or doing it right for any given scenario.

Now of course there are problems with the statistical method (also benefits, but we're interested in failure right now). 1) You can't say why you're right [in order to do that you have to sit down an analyze what you've been doing in a structural fashion]. 2) The only teaching method you know involves telling people they're wrong when your gut tells you they're wrong. 3) You'll have a terrible intuition for any situation that only causes a failure after a period of time or some of the time (think undefined behavior in C).

If you have only learned programming statistically and haven't sat down and reflected on what the structure of what you're doing actually is, then when you are faced with information that is contrary to what you know your natural reaction is going to be to listen to your gut (even if your gut is wrong) and provide the same negative response that you got when you were first learning.

Additionally, the only "reasons" that you'll be able to give are paper thin metaphors and thought terminating cliches that don't stand up to even the smallest amount of examination.

The end result? You get a bunch of programmers that freak out every time a new language comes out.

Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment "If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make this code "safe" regardless of language. " , elsewhere "I get that this project probably values developer efficiency over safety or correctness, and probably makes sense in this use case.", etc. Still smells kind of elitist to me.