C++20, How Hard Could It Be

This has never been my experience, and Joel isn't an all-seeing oracle.

In just one notable example, a company I was at had a team develop an important platform in Node.js when the rest of the company was hired for and familiar with Java/Ruby. This app ran our 3rd party API gateway and was a central part of how our company was attempting to grow.

The Node.js team left wholesale to go found CockroachDB, which left nobody at the company who had the expertise to take over. You'd think that someone at a fairly large company would have Node.js experience, but it wasn't the case that we could staff the team back up easily.

There were several major production outages and the app lagged behind in development for the entirety of its life. We also had to port our protoc changes and traffic stack just to serve this one app. This despite being a central part of our upmarket strategy.

Ultimately it was completely rewritten. And nobody regretted that decision. We carefully weighed the pros and cons.

There's something to be said for a company that standardizes on one or two languages. Letting engineers have free reign leaves you with Haskell and Erlang littered in important places, with a very tiny bus factor.

It's a very good language. I learned it graduate school in the mid 1990s. I personally think the learning curve is not particularly steep. But it seems like most developers and the industry would rather enforce coding standards to nerf the foot-guns in C/C++ (https://news.ycombinator.com/item?id=7628746). With Ada there would still be coding standards but I would wager that it wouldn't be as much about inherent problems in the language.

They might both have a rule like: AV Rule 1 Any one function (or method) will contain no more than 200 logical source lines of code (L- SLOCs).

But Ada would probably not have something like: AV Rule 59 (MISRA Rule 59, Revised) The statements forming the body of an if, else if, else, while, do...while or for statement shall always be enclosed in braces, even if the braces form an empty block.

Or: AV Rule 193 (MISRA Rule 61) Every non-empty case clause in a switch statement shall be terminated with a break statement.

Those two arise from deficiencies in the basic C/C++ syntax. They are probably not fixable in a future revision of the spec because they would break too much code. So we create a coding standard, configure a linter to check for it, wire up our source repository to scan for it on checkin, and make all the leads code review for it.

Ada might have different language specific standards. For example, around not allowing breaks out of infinite loops. Requiring, instead, a loop construct with a testable condition. But even then, you can pragma things out of the compiler to help you enforce behavior. That's "built in."

My comment with Rust is not that Ada is bad or too hard, but rather even a small amount of additional work might be enough for developers and organizations to avoid Rust. There's a lot of Rust advocacy, which is a good thing. However, there was also a lot of activity on comp.lang.ada.advocacy (if I remember the newsgroup correctly). One good thing is that Ada felt "imposed" by a number of people and that automatically stimulates a kind of rejection response. Rust's introduction is definitely more "bottom up."

In short, no.

But then, it's hard to find good programmers for any language, so C++ isn't really any worse off here, and better off than some in that at least there's a bunch of candidates to pick from.

C++ allows you to control your memory allocations.

You can use mark and sweep, you can us reference counting, you can use arenas, you can use local stack, you can use shared memory, you can have custom allocators for any object, you can avoid memory allocations altogether, and any combination of these.

C is the same. Java can do some of this, if you twist it hard enough. Go cannot. That's ok -- often, even most of the time, you don't care, and then Go is a fine language.

But C++ is useful in a much wider set of domains than many people think, because it offers a level of control that many other languages don't.

My favourite analogy? Go (etc) is like an Apple product: smooth, and shiny, and tries to be idiot-proof, but you can only do it the Go way. C++ is more Linux: a mess of incompatible, incomplete, infuriating things that let you do absolutely anything you want, if you invest the effort.

> performance tends to be a major objective

My comment is about the thinking behind making this decision, C++ or not. It wasn't "is it speculative that GC will add a cost?" or something like that.

I wonder how much of the thinking that leads one to conclude "I need so much performance here that I can't afford a managed language", for example, is real carefully thought vs. speculative.