[adam_arthur]

C++ still exists because existing projects were written in it... that's it.

There's no value in using it for future projects other than a wider pool of developers to source from... a network effect that will diminish with time.

Java is objectively dated in so many ways, it's not really defensible to say otherwise. Tons of unnecessarily verbose and boilerplate aspects of the language.

[toxik]

That is a very bold claim from basically zero evidence, on both accounts but especially C++ being a zombie language.

[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

[AnimalMuppet]

> C++ still exists because existing projects were written in it... that's it.

False.

> There's no value in using it for future projects other than a wider pool of developers to source from

Well, you know, that is value. And there's value in being in the same language as the libraries you use. And there's value in C++ in the embedded space. And there's value to being able to control memory alignment in the high performance space. And...

If you're writing some generic web service, sure, there's no reason to write it in C++. Your statement was far too broad, though.

[qsort]

> C++ still exists because existing projects were written in it... that's it.

Obviously wrong, but sure, go on.

> Java is objectively dated in so many ways, it's not really defensible to say otherwise. Tons of unnecessarily verbose and boilerplate aspects of the language.

What Java are you talking about? It might have been true in the past, but modern versions of Java are just normal Algols. It's on par with C++, C# and Go, the other mainstream options you'd have for a project you'd write in Java. Sure, it's not as terse as Python, but neither is C++ or C# or Go.

[seer-zig]

Modern Java is much more terse than golang. No comparison really.

[vips7L]

Java the language is far more expressive than Go. Switch expressions, pattern matching, and streams are better than anything Go can offer right now.

[adam_arthur]

Ok, provide the counter evidence then.

Which aspects of C++ are superior to modern equivalents, ignoring ecosystem and network effects which aren't facets of the language.

[AnimalMuppet]

You made the claim. You should provide some evidence, not just demand that others do...

[adam_arthur]

Rust is more memory safe, more concise, and pretty much just as fast. There, now you go?

[AnimalMuppet]

>> C++ still exists because existing projects were written in it... that's it.

That was the claim. Between "Rust exists" and "the only reason C++ still exists is existing projects were written in it" there's still a fair amount of ground for you to cover.

You said that Rust is more memory safe. Hard to argue. And more concise, about which I have no information. Those are good things. But, as I brought up elsewhere in this thread:

Is Rust as easy to use in the embedded space? Is it available on as wide a variety of chips?

Does Rust make it as easy to control memory alignment, for those who need it?

Does Rust make it as easy to interface with libraries, many of which are written in C++?

Memory safety is good. Conciseness is good. Those are not the only reasons one might choose a language.

[kaba0]

C++ is still the choice for truly performance-critical applications, period.

[adam_arthur]

Because of network effects, not because of the language itself. Thus dominance will fade over time.

There are many modern languages that are more ergonomic and just as fast.

[AnimalMuppet]

No, actually because of the language itself.

What matters most in high-performance computing? The algorithm, sure. What's in second place? Memory alignment.

Memory alignment determines whether or not I can use SIMD. It also determines how many cache misses I have.

Can I fight that battle using Rust? Maybe. Is it as convenient as in C++? Is any other language? as convenient as C++?

[steveklabnik]

Rust absolutely lets you control alignment, and use SIMD. I won’t claim to make a comparison to C++ here because I have never done that sort of work in it, but it is absolutely a thing.

[adam_arthur]

There are tons of modern languages that allow low level memory access, including Rust. Nobody chooses C++ due to it being more convenient than modern languages.