3 ms·

Yes, the C++ dependencies are unlikely to be available. Specifically dependencies on OS libraries that are just not available on current common systems. So yo

by jerven 5y ago

Yes, the C++ dependencies are unlikely to be available. Specifically dependencies on OS libraries that are just not available on current common systems. 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.

qayxc 5y ago
> Specifically dependencies on OS libraries that are just not available on current common systems. 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...
- jerven 5y ago
  All very fair points. But I think the ecosystem of a language is part of this discussion. And the ecosystem of year 2000 C++ is hard to run on current systems. While the ecosystem of year 2000 java still works.(IMHO better than 2005 java) 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.

by jerven 5y ago

qayxc 5y ago

> Specifically dependencies on OS libraries that are just not available on current common systems. 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...

jerven 5y ago
All very fair points. But I think the ecosystem of a language is part of this discussion. And the ecosystem of year 2000 C++ is hard to run on current systems. While the ecosystem of year 2000 java still works.(IMHO better than 2005 java) 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.