[htfy96]

While I sort of agree on the complaint, personally I think the best spot of C++ in this ecosystem is still on great backward-compatibility and marginal safety improvements.

I would never expect our 10M+ LOC performance-sensive C++ code base to be formally memory safe, but so far only C++ allowed us to maintain it for 15 years with partial refactor and minimal upgrade pain.

[IshKebab]

I think at least Go and Java have as good backwards compatibility as C++.

Most languages take backwards compatibility very seriously. It was quite a surprise to me when Python broke so much code with the 3.12 release. I think it's the exception.

[thbb123]

I don't know about go, but java is pathetic. I have 30 years old c++ programs that work just fine.

However, an application that I had written to be backward compatible with java 1.4, 15 years ago, cannot be compiled today. And I had to make major changes to have it run on anything past java 8, ~10 years ago, I believe.

[simoncion]

Compared to C++ (or even Erlang), Go is pretty bad.

$DAYJOB got burned badly twice on breaking Go behavioral changes delivered in non-major versions, so management created a group to carefully review Go releases and approve them for use.

All too often, Google's justification for breaking things is "Well, we checked the code in Google, and publicly available on Github, and this change wouldn't affect TOO many people, so we're doing it because it's convenient for us.".

[olegkovalov]

> delivered in non-major versions

Can you clarify these 2 changes please? Cannot recall anything similar

[simoncion]

Nope. It has been like five, maybe eight years, so I do not remember. There have been more since then, but after seeing how Google manages the Go project, I pay as little attention to it as I can possibly get away with... so I do not remember any details about them.

[olegkovalov]

> There have been more since then

Doubt, again. Without a minimal proof of mentioned problems continuing dialogue doesn't make sense for me, thanks.

[pjmlp]

As long as you are lucky enough to not have used any stuff dropped in C++14, C++17, C++20 and C++23.

Exception especifications, gets, GC, string ABI,...

[bigstrat2003]

Java has had shit backwards compatibility for as long as I have had to deal with it. Maybe it's better now, but I have not forgotten the days of "you have to use exactly Java 1.4.15 or this app won't work"... with four different apps that each need their own different version of the JRE or they break. The only thing that finally made Java apps tolerable to support was the rise of app virtualization solutions. Before that, it was a nightmare and Java was justly known as "the devil's software" to everyone who had to support it.

[ivan_gammel]

That was probably 1.4.2_15, because 1.4.15 did not exist. What you describe wasn’t a Java source or binary compatibility problem, it was a shipping problem and it did exist in C++ world too (and still exists - sharing runtime dependencies is hard). I remember those days too. Java 5 was released 20 years ago, so you describe some really ancient stuff.

Today we don’t have those limits on HDD space and can simply ship an embedded copy of JRE with the desktop app. In server environments I doubt anyone is reusing JRE between apps at all.

[simoncion]

While "Well, just bundle in a copy of the whole-ass JRE" makes packaging Java software easier, it's still true that Java's backwards-compatibility is often really bad.

> ...sharing runtime dependencies [in C or C++] is hard...

Is it? The "foo.so foo.1.so foo.1.2.3.so" mechanism works really well, for libraries whose devs that are capable of failing to ship backwards-incompatible changes in patch versions, and ABI-breaking changes in minor versions.

[ivan_gammel]

> Java's backwards-compatibility is often really bad.

“Often” is a huge exaggeration. I always hear about it, but never encountered it myself in 25 years of commercial Java development. It almost feels like some people are doing weird stuff and then blame the technology.

> Is it? The "foo.so foo.1.so foo.1.2.3.so"

Is it “sharing” or having every version of runtime used by at least one app?

[simoncion]

> I always hear about it, but never encountered it myself in 25 years of commercial Java development.

Lucky you, I guess?

> Is it “sharing” or having every version of runtime used by at least one app?

I'm not sure what you're asking here? As I'm sure you're aware, software that links against dependent libraries can choose to not care which version it links against, or link against a major, minor, or patch version, depending on how much it does care, and how careful the maintainers of the dependent software are.

So, the number of SOs you end up with depends on how picky your installed software is, and how reasonable the maintainers of the libraries they use are.