[caffeine]

> survivorship bias, that countless projects never got the chance to be developed due to the too high of a burden of doing it properly

I would contend the cost of doing things “safely” is much higher in C++. since a human being has to mentally do all the work the compiler would do in a safe language.

[pittmajp]

Right. Op is saying an unsafe program that’s paying the bills and we can fix later is better than being a Rust evangelist on hn because your startup never got off the ground.

Somewhere out there, a startup is writing a browser in pure safe rust, and there won’t be any memory errors in it because they’re never gonna take on any tech debt and it’s never gonna ship.

[caffeine]

Yeah I understand but I disagree.

If you race a skilled Rust team against an equally skilled C++ team to build some big complicated fast software, the Rust team would likely ship first, and with less bugs.

The C++ team will eventually ship too, but it will take much longer. The software will also be of high quality, and very slightly superior performance, but there will be a couple of memory leaks, maybe a couple of exploits, and possibly a tricky segfault, somewhere down the line. Maintaining the C++ team’s software without introducing further issues will require superhuman intelligence, so it won’t happen - there will increasing issues as the team turns over and the detailed understanding of the code is lost over time.

The Rust team will mostly suffer from frustration about how bad async is, go down the rabbit hole of using it, and then rip it out and replace it with hand-rolled state machines and epoll. Down the line at some point, future programmers will decide this is legacy garbage and replace it all with async again.

There will be no segfault or memory exploits, and a similar number of logic bugs to the c++ team.

I say this having worked on large C++ projects and large Rust projects, and with no particular religious love for Rust other than a grateful appreciation for the compiler.