7 ms·

This is fascinating. Combined with all the other languages that are now supported, along with its incredible capabilities, GraalVM is shaping up to be a truly m

This is fascinating. Combined with all the other languages that are now supported, along with its incredible capabilities, GraalVM is shaping up to be a truly modern “common language runtime” — what the .NET CLR and DLR once promised to be but so far have failed to deliver. And for what it’s worth, TruffleRuby on Truffle/GraalVM (reportedly derived from JRuby) is supposed to be incredibly fast.

dehrmann 6y ago
I could see GraalVM being a part of whatever replaces Docker.
- pjmlp 6y ago
  Most of the stuff people use Docker for, I was already doing in 2006 with WebSphere and EAR "images".
  - matsemann 6y ago
    No, it was miserable as f and no way comparable. Getting WAS to run locally could take a day or two of configuring. And since everything was manually done and had to be tweaked when loading in new stuff. And if you broke something (or it broke by itself) it was easier to just wipe it and reinstall everything from scratch, again wasting a few days of work. 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.
    - a_imho 6y ago
      My experience with running images on k8s is way worse than what you describe. It is a clusterfuck of dependencies and configuration when in reality people just want to run java -jar.
      - johnnycerberus 6y ago
        That java -jar usually requires a clusterfuck of dependencies and configuration.
        gjvc 6y ago
        maven "shaded" jars seem to be something of a help here.
        a_imho 6y ago
        Personally I disagree, but even if that was true, why add more unnecessary complexity to the mix? Deploying a jar vs deploying jar packaged as a docker image brings little benefits at a non negligible cost.
    - gjvc 6y ago
      Absolutely. It was hellish. Very few people understood how intricate this was, how bad the logging/messages were when you got it wrong, and paid little or no mind to being able to be portable between application server implementations from the word go.
      - gjvc 6y ago
        Just to be clear, I was talking about J2EE deployments of the time in general, not WebSphere in particular. I was mainly stuck on JBOSS 2.x/3.x and I was keen on using Resin instead. Yuck.
    - vbezhenar 6y ago
      I did not have any problems getting WAS to run locallly and I was very Java newbie at that time. I guess I was just lucky. It was literally the first thing I did on my first Java work: I installed WAS and started writing some servlets.
      - matsemann 6y ago
        For just getting something simple/singular up and running it was passable. 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.
        pjmlp 6y ago
        The story with certificates is still quite up-to-date with docker, k8s and other stuff nowadays. Just last December I was having similar fun with certificates and "modern" approaches.
    - pjmlp 6y ago
      Sorry but I will take Websphere over Docker/Kubernetes any day of the week.
    - geodel 6y ago
      Exactly! Sometime WS would fail to start a local instance in IDE in 5 minutes and timeout. It was hilariously bad software.
    - speed_spread 6y ago
      Without regard to the merit of each tech, I've made the J2EE to K8S comparison before and am glad to see here I am not the only one who saw the resemblance. 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.
      - pcdavid 6y ago
        > 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. Yes, it's called an operating system :-)
      - gjvc 6y ago
        > I'm sure this was also done somehow in the mainframe world. LPAR -- https://en.wikipedia.org/wiki/Logical_partition https://en.wikipedia.org/wiki/Logical_partition Upon understanding this, I realised that there is / was nothing new under the sun.
        pjmlp 6y ago
        Even safe systems programming languages, with unsafe code blocks. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/NEWP 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.
pjmlp 6y ago
Plenty of languages (commercially) target the CLR, however given its Windows focus, many UNIX FOSS based researchers never cared about it, even in the presence of mono.
- jolux 6y ago
  The CLR has been cross-platform as CoreCLR since 2016.
  - pjmlp 6y ago
    Indeed, and here I am targeting .NET Framework 4.7.2, because the ecosystem isn't fully compatible with Core. Plus on UNIX, Java has 25 years of history, not 4 (not counting WIP mono here).
    - jolux 6y ago
      I'm well aware :) just wanted to clarify since this comes up a lot. 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.
      - geospeck 6y ago
        > 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. [1]https://github.com/clojure/clojure-clr/commits/master https://github.com/clojure/clojure-clr/commits/master
        jolux 6y ago
        I don't have a huge amount of insight into the project but the commits over time don't look super healthy: https://github.com/clojure/clojure-clr/graphs/commit-activity https://github.com/clojure/clojure-clr/graphs/commit-activit... Either way it's pretty clearly not a core platform for Clojure.

dehrmann 6y ago

I could see GraalVM being a part of whatever replaces Docker.

pjmlp 6y ago
Most of the stuff people use Docker for, I was already doing in 2006 with WebSphere and EAR "images".
- matsemann 6y ago
  No, it was miserable as f and no way comparable. Getting WAS to run locally could take a day or two of configuring. And since everything was manually done and had to be tweaked when loading in new stuff. And if you broke something (or it broke by itself) it was easier to just wipe it and reinstall everything from scratch, again wasting a few days of work. 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.
  - a_imho 6y ago
    My experience with running images on k8s is way worse than what you describe. It is a clusterfuck of dependencies and configuration when in reality people just want to run java -jar.
    - johnnycerberus 6y ago
      That java -jar usually requires a clusterfuck of dependencies and configuration.
      - gjvc 6y ago
        maven "shaded" jars seem to be something of a help here.
      - a_imho 6y ago
        Personally I disagree, but even if that was true, why add more unnecessary complexity to the mix? Deploying a jar vs deploying jar packaged as a docker image brings little benefits at a non negligible cost.
  - gjvc 6y ago
    Absolutely. It was hellish. Very few people understood how intricate this was, how bad the logging/messages were when you got it wrong, and paid little or no mind to being able to be portable between application server implementations from the word go.
    - gjvc 6y ago
      Just to be clear, I was talking about J2EE deployments of the time in general, not WebSphere in particular. I was mainly stuck on JBOSS 2.x/3.x and I was keen on using Resin instead. Yuck.
  - vbezhenar 6y ago
    I did not have any problems getting WAS to run locallly and I was very Java newbie at that time. I guess I was just lucky. It was literally the first thing I did on my first Java work: I installed WAS and started writing some servlets.
    - matsemann 6y ago
      For just getting something simple/singular up and running it was passable. 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.
      - pjmlp 6y ago
        The story with certificates is still quite up-to-date with docker, k8s and other stuff nowadays. Just last December I was having similar fun with certificates and "modern" approaches.
  - pjmlp 6y ago
    Sorry but I will take Websphere over Docker/Kubernetes any day of the week.
  - geodel 6y ago
    Exactly! Sometime WS would fail to start a local instance in IDE in 5 minutes and timeout. It was hilariously bad software.
  - speed_spread 6y ago
    Without regard to the merit of each tech, I've made the J2EE to K8S comparison before and am glad to see here I am not the only one who saw the resemblance. 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.
    - pcdavid 6y ago
      > 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. Yes, it's called an operating system :-)
    - gjvc 6y ago
      > I'm sure this was also done somehow in the mainframe world. LPAR -- https://en.wikipedia.org/wiki/Logical_partition https://en.wikipedia.org/wiki/Logical_partition Upon understanding this, I realised that there is / was nothing new under the sun.
      - pjmlp 6y ago
        Even safe systems programming languages, with unsafe code blocks. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/NEWP 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.

pjmlp 6y ago

Plenty of languages (commercially) target the CLR, however given its Windows focus, many UNIX FOSS based researchers never cared about it, even in the presence of mono.

jolux 6y ago
The CLR has been cross-platform as CoreCLR since 2016.
- pjmlp 6y ago
  Indeed, and here I am targeting .NET Framework 4.7.2, because the ecosystem isn't fully compatible with Core. Plus on UNIX, Java has 25 years of history, not 4 (not counting WIP mono here).
  - jolux 6y ago
    I'm well aware :) just wanted to clarify since this comes up a lot. 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.
    - geospeck 6y ago
      > 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. [1]https://github.com/clojure/clojure-clr/commits/master https://github.com/clojure/clojure-clr/commits/master
      - jolux 6y ago
        I don't have a huge amount of insight into the project but the commits over time don't look super healthy: https://github.com/clojure/clojure-clr/graphs/commit-activity https://github.com/clojure/clojure-clr/graphs/commit-activit... Either way it's pretty clearly not a core platform for Clojure.