The Grug Brained Developer (2022)

Being at a firm where the decision to use C++ was made, the thought process went something like this:

"We're going to need to fit parts of this into very constrained architectures."

"Right, so we need a language that compiles directly to machine code with no runtime interpretation."

"Which one should we use?"

"What about Rust?"

"I know zero Rust developers."

"What about C++?"

"I know twenty C++ developers and am confident we can hire three of them tomorrow."

The calculus at the corporate level really isn't more complicated than that. And the thing about twenty C++ developers is that they're very good at using the tools to stamp the undefined behavior out of the system because they've been doing it their entire careers.

How does someone know twenty C++ developers and zero C developers though?

People sometimes forget we're not just trying to use the shiniest tool for fun, we're trying to build something with deadlines that must be profitable. If you want to hire for large teams or do hard things that require software support, you often have to use a popular language like C++.

Born in the 80s.

That wouldn't stop someone from knowing any C developers. It's still a common language today, and was more common when those 80s kids would have become adults and entered the industry.

Maybe they use only Microsoft Windows?

As a kid in the 1980s I thought something was a bit off about K&R, kind of a discontinuity. Notably C succeeded where PL/I failed but by 1990 or so you started to see actual specs written by adults such as Common Lisp and Java where you really can start at the beginning and work to the end and not have to skip forward or read the spec twice. That discontinuity is structural though to C and also C++ and you find it in most books about C++ and in little weird anomalies like the way typedefs force the parser to have access to the symbol table.

Sure C was a huge advance in portability but C and C++ represent a transitional form between an age where you could cleanly spec a special purpose language like COBOL or FORTRAN but not quite spec a general systems programming language and one in which you could. C++, thus, piles a huge amount of complexity on top of a foundation which is almost but not quite right.

And none of those 20 C++ developers can learn rust? What’s wrong with them?

They can, but why pay 20 people to learn Rust?

Probably they know C but the project is complex enough to warrant something else. Personally I'd rather C++ not exist and it's just C and Rust, but I don't have a magic wand.

Personally I think Rust is better thought out than C++ but that I've got better things to do than fight with the borrow checker and I appreciate that the garbage collector in Java can handle complexity so I don't have to.

I think it's still little appreciated how revolutionary garbage collection is. You don't have maven or cargo for C because you can't really smack together arbitrary C libraries together unless the libraries have an impoverished API when it comes to memory management. In general if you care about performance you would want to pass a library a buffer from the application in some cases, or you might want to pass the library custom malloc and free functions. If your API is not impoverished the library can never really know if the application is done with the buffer and the application can't know if the library is done. But the garbage collector knows!

It is painful to see Rustifarians pushing bubbles around under the rug when the real message the borrow checker is trying to tell them is that their application has a garbage-collector shaped hole in it. "RC all the things" is an answer to reuse but if you are going to do that why not just "GC all the things?" There's nothing more painful than watching people struggle with async Rust because async is all about going off the stack and onto the heap and once you do that you go from a borrowing model that is simple and correct to one that is fraught and structurally unstable -- but people are so proud of their ability to fight complexity they can't see it.

A lot of fintech. Bloomberg is real into C++.

Flip the question around: what is the benefit when they already know C++? Most of the safety promises one could make with Rust they can already give through proper application of sanitizers and tooling. At least they believe they can, and management believes them. Grug not ask too many questions when the working prototype is already sitting on Grug's desk because someone hacked it together last night instead of spending that time learning a new language.

I suspect that in a generation or so Rust will probably be where C++ is now: the language business uses because they can quickly find 20 developers who have a career in it.

In our case, a garbage collector is a non-starter because it can't make enough guarantees about either constraining space or time to make the suits happy (embedded architecture with some pretty strict constraints on memory and time to execute for safety).

I do think that there are a lot of circumstances a garbage collector is the right answer where people, for whatever reason, decide they want to manage memory themselves instead.

They're probably busy writing code for a living.

The correct answer was almost surely lua + native modules for hotspots. I'm not surprised they couldn't see that though.

Usually the main message is that they haven't thought about the organisation of their datastructures sufficiently. In my experience this is also very important with a GC, but you don't get much help from the compiler, instead you wind up chasing strange issues at runtime because object lifetimes don't match what you expected (not to mention, object lifetime is more than just memory allocation, and GC languages tend to have less effective means of managing lifetimes tightly). I agree async Rust is very painful still. It's very much something I don't use unless I have to, and when I do I keep things very simple.

(Also, the lack of a package manager for C is much more due to historical cruft around build systems than it is difficulty getting C libraries to work together. Most of them can interoperate perfectly well, though there is a lot more faff with memory book-keeping)

There's a layer that you could turn your head and squint and call Lua, but it's far more constrained than Lua is.

They never wanted to be in a situation in the embedded architecture where performance was dependent upon GC pauses (even incremental GC pauses). Their higher-level abstraction has tightly constrained lifecycles and is amenable to static analysis of maximum memory consumption in a way Lua is not.