4 ms·

I say this all the time to people that say they want to use Node because they hate Java. There are so many languages that you can execute on the JVM. It’s almo

I say this all the time to people that say they want to use Node because they hate Java. There are so many languages that you can execute on the JVM. It’s almost unfortunate that it’s still called the JVM. It think the JVM needs a re-branding. Even if they just change the meaning of the J. I suppose that is what GraalVM is doing, but it’s an awful name and its purpose isn’t being conveyed well. The JDK should just switch to this VM and get rid of the name JVM. These are just my opinions.

viraptor 3y ago
JVM still has some limitations. https://stackoverflow.com/a/2682962/31667 https://stackoverflow.com/a/2682962/31667 Those actually influence either the design or the performance of the higher level language.
- trollied 3y ago
  That post is 13 years old.
  - phoe-krk 3y ago
    The answer is 6 years old if we count the last modification time.
    - bierjunge 3y ago
      And the last modification was only wording, with the same 13 years old content. [0] Always check what changed in SO posts, because this practice is very common. [0] https://stackoverflow.com/posts/2682962/revisions https://stackoverflow.com/posts/2682962/revisions
      - phoe-krk 3y ago
        TIL, thank you!
  - viraptor 3y ago
    Yes it is - that doesn't make it wrong. The type erasure is still a JVM limitation.
    - kaba0 3y ago
      The same way is it for Haskell?
pohl 3y ago
I haven't been in that world since Java 7. What's the startup time on the JVM these days? It used to be a pretty hefty cost, and it didn't seem like it would get much better because of the way class loading was done.
- millerm 3y ago
  Not sure what startup time matters for running a persistent service is, and it's obviously tied to hardware. You can get applications up and running in less than second or so (we were using Micronaut to resolve dependencies at compile time). If you use GraalVM you can compile to native code and now we're talking a few tens of milliseconds to get an application up and running (or execute and exit).
  - pohl 3y ago
    That was always the story back then, too — the assumption that no one writes anything other than services with long uptimes. No CLI tools, no lambdas, no quick-launching GUIs. Sounds like that bias hasn't really changed over the years?
    - kaba0 3y ago
      You pay for what you use. If you bring in a litany of libraries to connect to some endpoint in every conceivable IPC mechanism then sure, it will take some time (but let’s not forget that it would also take considerable time with native machine code). But besides very very frequently run CLI tools like ls, the problem is entirely overblown. Come on, quick-launching GUIs? I hardly even remember that being a thing.
      - pohl 3y ago
        You pay for what you use. Exciting, if true. So, for example, could I choose to not use garbage collection or class loading or JIT compilation and avoid paying their costs?
        3y ago

viraptor 3y ago

JVM still has some limitations. https://stackoverflow.com/a/2682962/31667 https://stackoverflow.com/a/2682962/31667 Those actually influence either the design or the performance of the higher level language.

trollied 3y ago
That post is 13 years old.
- phoe-krk 3y ago
  The answer is 6 years old if we count the last modification time.
  - bierjunge 3y ago
    And the last modification was only wording, with the same 13 years old content. [0] Always check what changed in SO posts, because this practice is very common. [0] https://stackoverflow.com/posts/2682962/revisions https://stackoverflow.com/posts/2682962/revisions
    - phoe-krk 3y ago
      TIL, thank you!
- viraptor 3y ago
  Yes it is - that doesn't make it wrong. The type erasure is still a JVM limitation.
  - kaba0 3y ago
    The same way is it for Haskell?

pohl 3y ago

I haven't been in that world since Java 7. What's the startup time on the JVM these days? It used to be a pretty hefty cost, and it didn't seem like it would get much better because of the way class loading was done.

millerm 3y ago
Not sure what startup time matters for running a persistent service is, and it's obviously tied to hardware. You can get applications up and running in less than second or so (we were using Micronaut to resolve dependencies at compile time). If you use GraalVM you can compile to native code and now we're talking a few tens of milliseconds to get an application up and running (or execute and exit).
- pohl 3y ago
  That was always the story back then, too — the assumption that no one writes anything other than services with long uptimes. No CLI tools, no lambdas, no quick-launching GUIs. Sounds like that bias hasn't really changed over the years?
  - kaba0 3y ago
    You pay for what you use. If you bring in a litany of libraries to connect to some endpoint in every conceivable IPC mechanism then sure, it will take some time (but let’s not forget that it would also take considerable time with native machine code). But besides very very frequently run CLI tools like ls, the problem is entirely overblown. Come on, quick-launching GUIs? I hardly even remember that being a thing.
    - pohl 3y ago
      You pay for what you use. Exciting, if true. So, for example, could I choose to not use garbage collection or class loading or JIT compilation and avoid paying their costs?
      - 3y ago