[hft_throwaway]

Guys who write HFT systems in Java are basically programming them like one would in C or C++. They pre-allocate byte buffers for everything and never run the GC. If you write C-style code in Java, it's going to run pretty quickly. They aren't doing architecture astronaut AbstractMetaClassFactory stuff or using much of the provided libraries for latency-sensitive code.

FWIW, I don't think Jane Street is a competitor in the "ultra HFT" space where every nanosecond counts. AFAIK they are more of a statistical and quantitative trading group, so they may have less need for things like talking directly to hardware, keeping tight control over memory layout, deterministic latency w/o GC pauses, etc.

Almost everything that is popular has evolved over time, and making these changes once you have established users results in compromises that can be sort of ugly. C++ has patina.

[loup-vaillant]

> Almost everything that is popular has evolved over time, and making these changes once you have established users results in compromises that can be sort of ugly. C++ has patina.

You will note that C++ made that sort of ugly compromises from the start. Keeping a C-like syntax really wasn't necessary. (Keeping a C-like semantics, that's a different story.)

[hft_throwaway]

But isn't that because C++ itself evolved from C? The original "C With Classes" wasn't much more than a convenient syntactic sugar for using structs and function pointers as a poor man's object system, something that was and is common in large, abstract C programs (e.g. Linux's VFS layer, Gtk+).

I think you may be confusing is with ought here. Everybody sane knows C++ has flaws; I think Meyers even feels this way in his presentation. C++ is popular because it evolved and thus contains a lot of compromises. To draw an analogy, the Mormon Church is immensely popular in the US for similar reason--they basically said, "Hey the New and Old Testaments you spent your formative years learning are all good, but we've got some swell new stuff here too!" I'm sure Zen Buddhism is more theologically pure, but people like what's familiar to them.

Programming languages are a network effect problem first and foremost. Just like it's hard to unseat Craigslist despite its crappy UI, it's difficult to get users for a new language that may be only marginally better in terms of features, productivity, safety or convenience. Even if it's a significant improvement existing code bases, library availability, programmer availability with domain knowledge and so on matter much more for serious projects. There's a reason why Facebook took the time to write a PHP VM instead of rewriting their code.

[loup-vaillant]

> Programming languages are a network effect problem first and foremost.

If only reality wasn't like this. Yes, network effects are ridiculously important. And so is status-quo bias in general. I know C++ wouldn't be nearly as popular if it adopted a different syntax. I know that the ability to compile most existing C code out of the box was a big help in the adoption of the language, even though it technically doesn't matter. This is why I said erlier¹ that C++ is one of the greatest shame of our community. Stroustrup was well aware of our insanities, and he exploited them on purpose, supposedly for our own good. We as a community were simply incapable of accepting anything better. It would have been too different.

[1]: https://news.ycombinator.com/item?id=7938469

> But isn't that because C++ itself evolved from C?

It didn't. C++ did not evolve from C, it was implemented on top of C. Stroustrup didn't started by modifying the front-end of GCC, he started by writing CFront. From there, it would have been real easy to fix some of the most glaring flaws of C: switches that fall through, overly general (and verbose) for loops, the insane syntax of type declarations (ML existed at the time, and could have been an inspiration), the priority of the operators (15 levels are too much, some priorities are backwards), and maybe some operators themselves (the star for instance serves two unrelated purposes, which may be confusing). While we're at it, Stroustrup could have thrown the headers away, replacing them with a proper module system. Nothing fancy, just a nice way to package compilation units.

That was the "fixing C" part. These flaws were known at the time, it would have been easy to fix them. (Except maybe the module system. You still want an easy way to talk to existing C code.)

Then we can move on to building C++: a language with a stellar C FFI, semantics that are identical to C (except for advanced syntax sugar such as classes), but with a much cleaner, easier, and more flexible syntax. This language would have been much better than the current C++ on every possible measure, except one.

Adoption.

It seems we just can't change our syntax. No, scrap that, we just can't change, period. People love "change", but they hate change. There are few circumstances where people are willing to accept change (like this anecdote about introducing OpenOffice as "the new version of Word"). One of C++'s greatest strength (and our community's greatest weakness), was it's apparent similarity with C. It's the same, except with more features! A better syntax for C however, while more useful than a mere C-with-classes², would never have caught on.

[2]: Templates are C++'s killer feature, not classes. (OO as done with C++ and Java classes is mostly a mistake³. But that's another debate.)

[3]: http://loup-vaillant.fr/articles/classes-suck

(I'm not kidding about C's syntax being terrible. Experiments have shown that beginners fare no better with C than they do with a randomly generated syntax. It is that bad.)