Doesn't mean we don't touch old code (change idioms, generic safe, build process etc). It means we do it when there is value to us for updating it. Not because we are forced to due to an infra change.

At the same time code that ran on a PA-RISC machine now happily runs on a mac arm (even then it was great because the same code ran on PA-RISC, powerpc, x86 and X86-64).

If that code was written in python it would have likely gone through two breaking cycles at least. C sure that would have worked but the cost of having it working such a variety of systems would have been humongous for a small group like us. What real alternatives have this claim? C++ chances that I can compile code from 2000 without issues is minuscule.

Sure I had my EJB "fun", and when I look at some of the micro-services being deployed I see the same problems. Because they are reflections of organizations. (i.e. sometimes have the feeling that changing language in an org is like switching your in-office communication to Italian, because it so fast and romantic.).

Just because there was "bad" code written in the past doesn't mean new code is done that way. Yes it exists, yes it needs to be poked once in a while, but that is a lot cheaper than rewriting in a modern style.

I LMAO when Python changed (or broke...depending how you look at it) the basic print functionality between version 2 and 3. Meanwhile I can use the latest and greatest JDK to compile old java code.

Don't get me wrong, I think Python is awesome for what I needed to do (data manipulation) and would likely be my language of choice for such tasks in the future.

Also, the best way to get a highly commented article on HN is to write one on why you love, or hate Java.

Really? I have code from the late 90ies and it compiles just fine. Do you perhaps mean dependencies? Because the issue there is the completeness of the framework and libraries around Java rather than the language itself.

So you need to get them but they are not available anymore and may depend on code that doesn't compile anymore. Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that.

Or the fact that C++ code was "almost" C++ code and not actually C++ code. Just a variant that was supported by an "almost" C++ compiler.

Not really the case for smaller utilities but larger projects originating on what is now rare equipment suffered from this.

So maybe not "miniscule" but not rare in my experience either.

But again, that's a problem with the OS, not a problem with C++. POSIX compliant code still compiles just fine on POSIX-compliant platforms and 32-bit code compiles just fine with 32-bit compilers as well - nothing changed in that regard. It's a similar story with other APIs such as Win32.

> Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that.

If you try to compile 32-bit code as 64-bit code you're porting, not recompiling. You can also just specify -std=c++98 (with g++) or just use an old compiler.

In my experience the problems with Java code are just as annoying, but those problems don't come from within the language itself either.

Things that weren't natively available had to be added via external scripts, application servers, native libraries, etc. And getting a fragile jumbled mess to work that relied on a specific Tomcat server version, command line scripts, external libraries or - god forbid! - certificates, was a major PITA as well.

Even today trying to get something as simple as SSL certificates working with Java can be frustrating. Why? Because for some reason Java insists on keeping its own keystore because it's the JDK that decides which authorities are to be trusted - not the user, not the OS, only the JDK.

Well, one of the installed versions, which gets to be real fun if you're working with containers, but I digress...

I would definitely not say that java is perfect, but the java ecosystem does have some very practical advantages that more than compensate for some of its very real disadvantages.

I once wrote an application in 2005 that kept running with unmodified source code up until 2017 in production across multiple operating system upgrades, database upgrades, and a transition from 32-bit to 64-bit runtimes.

I'm almost expecting a few years down the road, Microsoft will go back on 4.8 being end-of-the-line for .NET 4 and start releasing new minor versions of it because of all the customer code that can't be ported to .NET 5. Or maybe it will just end up like VB6. Stuff written in it still works, and will continue to work, but it's considered a dead language.

"Initially" would be somewhat closer to the truth than "always".