[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.