And for what it’s worth, TruffleRuby on Truffle/GraalVM (reportedly derived from JRuby) is supposed to be incredibly fast.
Plus on UNIX, Java has 25 years of history, not 4 (not counting WIP mono here).
I spent most of last year maintaining a Web Forms app. It's no fun. Ironically, there used to be many more CLR languages, because Microsoft paid for their development. IronPython and IronRuby stand out. I wish ClojureCLR weren't dead too.
Is there any reason for saying that? Checking the commits history on Github[1], the project seems still alive.
Either way it's pretty clearly not a core platform for Clojure.
A google search would tell you otherwise.
https://groups.google.com/g/clojure-clr/c/2v9xls5hreE
Last commit 6 days ago: Last code change 11 days ago: https://github.com/clojure/clojure-clr/commits/master
Microsoft abandoned IronRuby and IronPython around 10 years ago. Meanwhile TruffleRuby on GraalVM is the fastest Ruby implementation by far.
From Microsoft itself, F**, F#, VB.NET, C#, Sing#, System C#, Managed C++, C++/CLI, Cω, Axum, and who knows what else they have done internally.
From Microsoft partners, COBOL, Eiffel, Ada, Fortran.
From FOSS community and university researchers, not so much because it is M$ and better not use Mono because of patents, so was the saying.
That means the DLR is effectively dead, I think -- along with all languages for which the CLR's static call sites mean slowed performance.
And if you tried running your own EAR files, it could take an hour from a code change to actually test it. Building it, installing it, reloading the server, and then getting to the correct state of testing. If you discovered a bug, you had to patch the code, build the file again and start over, wasting another hour. Some of it was evaded by using JRebel, but if the changes couldn't be swapped you were SOL.
No way WAS+EAR can be compared to running stand-alone images. It was a clusterfuck of dependencies and dependent configuration.
Yuck.
The problem was when it was used for multiple services (as his comparison with EAR and docker implies). Lets say you had a service for something packaged as EAR. You would then have to log in to the dashboard, add the package and configure it manually. If something changed with the package, you would probably have to reinstall it in WAS, you couldn't just pull the newest from git in your repo and be done. And if that needed any config changes, everyone on the team had to do the same locally and manually in the control panel. When you got multiple moving parts, you would spend more time bringing them in and configuring everything correctly than actually developing whatever you were supposed to.
But what I wasted most time on was certificates. Everything had to be signed and stuff, mostly self signed by randoms and more theater than security. Sooo many times stopped working because the certificate for some module expired, or the CAS was unknown and had to be manually loaded into everyone's local install etc.
Just last December I was having similar fun with certificates and "modern" approaches.
It mostly goes to show that containerizing application code for execution in a managed environment in nothing new. I'm sure this was also done somehow in the mainframe world.
As to whether K8S is a superior embodiment of the concept, I'd say that the problem is rather that a large majority of adopters are just cargo-culting without having a real need for what it actually provides, externalizing the costs of complexity it brings. I have nothing against K8S itself, but its adoption curve is telling of CV-driven architecture at it's worst. Mind you, the same might have been said of J2EE back in the day.
Yes, it's called an operating system :-)
LPAR -- https://en.wikipedia.org/wiki/Logical_partition
Upon understanding this, I realised that there is / was nothing new under the sun.
https://en.wikipedia.org/wiki/Burroughs_large_systems
https://en.wikipedia.org/wiki/NEWP
If you follow NEWP manual from Unisys (nowadays still selling Burroughs as ClearPath), you will see UNSAFE code blocks and how its use tainted binaries, which requires admin permission for execution.