[adam_arthur]

Ok, well then provide a counterclaim.

Ignoring network effects and existing libraries, which language feature of C++ makes it better than a Go or Rust for similar use cases? Which language features are more concise and easy to use? What objective traits of the language make it superior?

[scottLobster]

Ignoring network effects and existing libraries is a good way to make an irrelevant argument. It would be like requiring the Marine Corps to train in BJJ and Kickboxing because that works best in the Octagon. Great, but the Marine Corp doesn't fight in the Octagon.

In general, I'll take a somewhat mediocre tool where I can look up examples/libraries to do everything I need, with a large pool of competent developers to hire from, over an excellent tool that may or may not do everything I need at the level that I need, that relatively few people know how to use.

Of course, standards can change. But Go and Rust have a long way to go to build the network effects/libaries/ecosystem equivalent to that enjoyed by c++. I'll let the enthusiasts figure that out while I build things that get deployed, I look forward to the day it's ready, lot of promising features in those languages. Thanks in advance!

[adam_arthur]

Yes, so you're talking about network effect momentum.

In 20 years Java will not be the default choice for the vast majority of projects, just as C isn't now, despite being so in the 80s... it's obvious from the verbosity of the language. Network effect will fade over time.

Kotlin is already a drop in replacement for Java that is less verbose, more ergonomic and still compatible with the existing ecosystem. Why would anyone use Java over Kotlin on a greenfield project aside from prior familiarity? They wouldn't

[scottLobster]

Right, and if that momentum is going to last 20 years, then that's going to dictate what's a good strategic decision and what isn't for the next 20 years. Thanks for letting me know what the good options might be when my infant daughter is halfway through college, that doesn't help me save for it in the meantime.

Prior familiarity is a very good reason to pick an option for a greenfield project if you're operating on any type of serious budget (time or money), especially if you need to hire others to help out. There's also the annoying reality that most libraries for new/up-and-coming languages are simply inadequate, despite whatever claims they make.

For instance, one of my personal side projects involves getting familiar with WebAssembly (note: not on a serious budget), and I'm using emscripten to transcode because that's what the internet seemed to think was the closest thing to a standard toolkit. I found a bug simply by combining two pieces of example code from Emscripten's own documentation (you'll note I'm transcoding from c++ due to prior familiarity): https://github.com/emscripten-core/emscripten/issues/17143

This is not a dig on emscripten, merely pointing out that it's probably not mature enough for the stress of corporate-scale development, where you encounter all sorts of crazy edge cases well beyond the sample code. Java over the years has obtained that level of maturity. The edge cases are largely solved or at least known, and there's an army of experts and consultants ready to help if there's a problem. When time is money, that matters. It determines the risk profile of any project, greenfield or otherwise.

Java's momentum hasn't stopped, at best it's simply slowing. And at this rate it'll take decades to come to a stop, and decades more to recede to any meaningful degree. I'll also point out that C is very much alive and well in the embedded world. Plenty of job postings looking for C experience explicitly, for new products as well as legacy.

[pwinnski]

> Ignoring network effects and existing libraries

aka Ignoring the fact that it's easy to hire developers that already have widespread experience in C++, and ignoring the cumulative effort that thousands, if not millions of developers have put into writing and testing code that I don't have to... wait, why would I ignore both of those things?

If I'm creating software in a vacuum, such that I don't have to think about things like developer experience or time-to-market, then sure, let's say that Go or Rust is definitely better for many use cases. Very few people create software in a vacuum!

[TillE]

You started with "C++ getting replaced by go and rust everywhere" (an enormous exaggeration), and now you want to argue about languages features. OK.

C++ is in a state where it's good enough and slowly getting better. The enormous ecosystem, from libraries to game engines like Unreal, means it's not going anywhere for decades. New "greenfield" games are being written in C++ every day.

[adam_arthur]

"ecosystem" just like C before Java, yes. Not an argument