Let me extol the virtues of Java the language.

You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it.

Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.

I have C++ code from 1997 that I occasionally compile. So far it runs. 10 yeas ago compiling with -Wall exposed an inconsequential bug and that was it. I suspect when it stops to compile it will be from an absence of a particular X11 library that I used to parse a config in otherwise command-line utility.

Which also points to another thing where Java compatibility shines. One can have a GUI application that is from nineties and it still runs. It can be very ugly especially on a high DPI screen, but still one can use it.

Yeah, that and the portability are really incredible and underrated. It is funny, because I constantly hear things like "write once, debug everywhere", but I have yet to see an alternative that has a higher probability of working everywhere.

Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).

I can run basically any Perl code back to Perl 4 (March 1991) on Perl 5.40.2 which is current. I can run the same code on DOS, BeOS, Amiga, Atari ST, any of the BSDs, Linux distros, macOS, OS X, Windows, HP/UX, SunOS, Solaris, IRIX, OSF/1, Tru64, z/OS, Android, classic Mac, and more.

This takes nothing away from Java and the Java ecosystem though. The JVM allows around the same number of target systems to run not one language but dozens. There’s JRuby, Jython, Clojure, Scala, Kotlin, jgo, multiple COBOL compilers that target JVM, Armed Bear Common Lisp, Eta, Sulong, Oxygene (Object Pascal IIRC), Rakudo (the main compiler for Perl’s sister language Raku) can target JVM, JPHP, Renjin (R), multiple implementations of Scheme, Yeti, Open Source Simula, Redline (Smalltalk), Ballerina, Fantom, Haxe (which targets multiple VM backends), Ceylon, and more.

Perl has a way to inline other languages, but is only really targeted by Perl and by a really ancient version of PHP. The JVM is a bona fide target for so many. Even LLVM intermediate code has a tool to target the JVM, so basically any language with an LLVM frontend. I wouldn’t be surprised if there’s a PCode to JVM tool somewhere.

JavaScript has a few languages targeting it. WebAssembly has a bunch and growing, including C, Rust, and Go. That’s probably the closest thing to the JVM.

  > I can run basically any Perl code back to Perl 4 (March 1991) on Perl 5.40.2 which is current.

Yes, but can you _read_ it?

I'm only half joking. Perl has so many ways to do things, many of them obscure but preferable for specific cases. It's often a write-only language if you can't get ahold of the dev who wrote whatever script you're trying to debug.

I wonder if modern LLMs could actually help with that.

> I wonder if modern LLMs could actually help with that.

From experience, they can.

>Yes, but can you _read_ it?

Java was marketed (at least in its early days) as a WORA language - WRITE ONCE RUN ANYWHERE.

Perl was unmarketed as a WORM language - WRITE ONCE READ MANY (TIMES). ;)

jk, i actually like perl somewhat.

but I think Larry and team went somewhat overboard with that human-style linguistics stuff that they applied to perl.

> I can run THE SAME CODE on DOS, BeOS, Amiga, Atari ST, any of the BSDs, Linux distros, macOS, OS X, Windows, HP/UX, SunOS, Solaris, IRIX, OSF/1, Tru64, z/OS, Android, classic Mac, and more.

No, you really can't. Not anything significant anyway. There are too many deviations between some of those systems to all you to run the same code.

Honestly, the main difference I run into is just file paths, and that’s easy to sidestep ( https://perldoc.perl.org/File::Spec ).

There are differences, but they’re usually esoteric ( https://perldoc.perl.org/perlport#PLATFORMS ).

Interesting about that long list of languages.

There's also Groovy.

I wonder what other languages run on the JVM. What about Perl, Icon, SNOBOL, Prolog, Forth, Rexx, Nim, MUMPS, Haskell, OCaml, Ada, Rust, BASIC, Rebol, Haxe, Red, etc.?

Partly facetious question, because I think there are some limitations in some cases that prevent it (not sure, but a language being too closely tied to Unix or hardware could be why), but also serious. Since the JVM platform has all that power and performance, some of these languages could benefit from that, I'm guessing.

#lazyweb

> Haskell

https://github.com/Frege/frege

https://github.com/typelead/eta

Of the others you mentioned, I bet there's a couple JVM Prologs out there, but haven't encountered any myself.

I often run into problems running Python code under Linux.

I don’t know if it is a me problem or if I’m missing the right incantations to set up the environment or whatever. Never had that much problems with Java.

But I’m a Java and Ruby person so it might really be missing knowledge.

It's not you. Python packaging has regressed into a worse mess than it was 20 years ago. I limit myself to simple scripts that only rely on builtins. Anything more complicated goes to a more dependable language.

I rarely run into issues when using Poetry. If you use pip, add packages to requirements.txt willy-nilly and don't pin versions then you are asking for trouble.

Poetry doesn't fix the fact that python removes modules from the standard library every release.

i like poetry though i've moved to uv - both work really well

I've heard great things about uv. I plan to try it for my next project.

I use pipenv and it kind-of-works. Will try uv or poetry though - which one would you recommend?

UV. Using it as the exec target for python (UV script) is great. Dependencies declared at the top, now I have executable files in something better than bash.

I no longer shy away from writing <500 LOC utility/glue scripts in python thanks to uv.

I don't know about the difference between 20 years ago versus now, but it's certainly doesn't seem to be clear now.

e.g. poetry, venv and pyenv have been mentioned in just the next few comments below yours. and this is just one example. i have seen other such seeming confusion and different statements by different people about what package management approach to use for python.

what languages do you use for the latter?

For anything more than just a one off script, look into venv. I’ve not written any python until this past year and can’t imagine maintaining an ongoing project without it.

Prior to that I would frequently have issues (and still have issues with one-off random scripts that use system python).

Python can be tricky with the big differences between 2 and 3.

As late as 2022, I was at a company still in the middle of "migrating" from 2 to 3. I wouldn't be surprised if the migration project was still going on. The system had gone beyond tech debt and was bordering on bankruptcy.

Python 3 came out in 2008. If the 2 vs 3 differences are still biting you you probably have bigger problems to solve (deprecated, insecure, unmaintained dependencies for example).

And IPv6 came out in 1995

Your point?

Honestly, it isn't just you. I had to hold off on 3.13 for quite a while too, because of various package conflicts. It isn't terrible, especially thanks to things like pyenv, but it is far from perfect.

I just spent 30 minutes trying to get a python package running on my Mac... Not feeling that. Pythons version compatibility is just awful and the mix of native is deeply problematic. Don't get me started on tooling and observability.

I know that what you said is supposed to be true. However in my real world experience it is anything but. Cisco java programs are a disaster and require certain JVMs to run.

The enterprise Java applications we use require specific versions of specific Linux distros. It's possible that they would run on other distros, or even other operating systems, if you got the right JVM. But there's enough question about it that the companies that sell them for a substantial price aren't willing to promise even a little portability.

I've got a jar that does one small thing and does it well that was compiled in 1998. Still works fine, no reason to update it.

> You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24.

This is not my experience with Java at all. I very often have to modify $JAVA_HOME.

Are you using Gradle projects? Gradle is especially difficult for some reason.

Sadly. I would rather avoid Gradle and Java in general. I did not have good experiences with them. :/

That is an excellent point too.

It always made me wonder why I hear about companies who are running very old versions of Java though. It always seemed like backwards compatibility would make keeping up to date with the latest an almost automatic thing.

It is "mostly" backwards compatible. Applets and everything related to them where dropped. A few interface dependencies where changed to improve modularity of the runtime. Widely used hacks like sun.misc.unsafe are getting replaced with official APIs and locked down. Development of some Java EE packages has been taken over by a third party, so they are no longer packaged within the java namespace. To name just a few of the bigger examples.

Java version updates typically change GC behavior. If one has highly tuned setup there is no guarantee that a newer version would not regress.

Another problem is crashes. Java runtime is highly reliable, but still bugs happens.

Are you talking about performance or behaviour? I’ve never seen an issue caused by a GC.

Latency spikes are the issue. Modern Java mostly solved this, but tuning GC settings is still the thing especially when Java runs on a big server.

I have been badly burned, twice, by Python's cavalier attitude to backwards compatibility

Python "the language" or Python "the ecosystem"?

That's not the virtues of Java the language. That's the virtues of Java the backward-compatible platform. That is, you didn't say anything about the language (syntax and semantics), you only talked about backward compatibility.

(It's still a valid point. It's just not the point you labeled it as.)

I have the exact opposite experience. I haven't coded much Java, but when I tried to revisit it, code I wrote 10 or 20 years ago doesn't even remotely compile anymore. While with C++, 20 years later you may need to add a missing #include (that you were always supposed to have), but then it just works as it always has.

Java is, in my opinion, a complete mess. And I think it's weird how anybody could like it past the 1990s.

C++ not being compilable later hasn't been true since pre standard C++. We're talking 1980s now.

https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...

Oh yeah. I still don’t understand why we even moved away from the original JEE model, including the different roles (app dev, deployed, etc).

The whole spec was great with the exception of entitybeans.

It provided things that are still not available it anything else.. why do we store configuration/credentials in git (encrypted, but still).

And the context were easy to configure/enter.

Caucho’s resin, highly underrated app server. Maybe not underrated, but at least not very well known

Entity Beans were terrible, representing the height of JEE over complexity. I remember editing at least 3 classes, a couple interfaces, and some horrific XML deployment descriptors to represent an "entity." A lot of the tooling was proprietary to the specific app server. On top of that, it was slow.

In the early 2000's, I used to work on JEE stuff for my day job, then go home and build PHP-based web apps. PHP was at least 10x more productive.

The worst thing about EntityBeans is they were so bad they made Hibernate look good, which led people to think it was good. After 10 years of hammering against ORM complexity I finally switched to using thin database wrapper layers and have not once ever regretted it.

I you just wanted queries, entity beans were ok.

Just a lot of boilerplate code, but the overal architecture and structure of JEE is still very sound

Hibernate... a real PITA every time the application needed something beyond basic single-table CRUD queries; sadly for me it happened 99% of the times. After some months of torture, plain JDBC with their stupid checked exceptions was refreshing, even without wrappers.

Yes! Hibernate was awful, but still light years ahead of EJBs. I worked on a couple of Hibernate projects and always left asking why...

You have to keep in mind that entity beans were developed in a time before generics, annotations, and widespread use of byte code enhancement that made a lot of the easy, magical stuff we take for granted possible.

I remember. During the same time period, I wrote some Java apps that used plain old JDBC, plus some of my own helper functions for data mapping. They were lighter weight and higher performance compared to the "enterprise" Java solutions. Unfortunately they weren't buzzword compliant though.

I remember Resin.

I grew to be a big fan of JBoss and was really disappointed when the Torquebox project stopped keeping up (Rubyized version of JBoss).

Yeah, JBoss put "it's slow" to bed right away. I was doing my own research at the time and tried some workloads on it. Huge difference.

resin was okay but I never got what it offered over tomcat

Full JEE, not just servlets, performance, reloading, and a bunch of enterprise features. Resin existed.

After about 10+ years Spring kind of took over JEE.

Omg. Spring was just like moving code to xml. Different now, but still.

What I miss from JEE:

- single file ear/war deployment, today that’s a docker image

- the whole resource api from Java (filesystem/jar doesn’t matter). It means you don’t necessarily have to unpack the jar

- configuration / contexts for settings, + UI for it, database connections etc. Docker kind of works, most most images fail to achieve this. Docker compose kind of takes care of things.

- as said before.. all Java still runs everywhere

It is unfortunate the whole JRuby doesn't get more attention and it seems Rails community dont use JRuby much.

JRuby could also run on Graal as well.