5 ms·

If you want to use any language, what makes the JVM important? Just use whatever that tech stack uses. Node uses v8, for example.

nickbauman 7y ago
I don't think you can compare V8 with the JVM. For starters, last time I checked, V8 is still single threaded, isn't it? Also it seems like future versions of JS are embracing things that make it look like they're envying Java, which seems like it's going in the wrong direction.
- t0astbread 7y ago
  You can do parallel computing in Node and the browser using workers. Also what features do you mean that "envy Java"?
  - nickbauman 7y ago
    static typing seems to be on the horizon (facepalm)
    - t0astbread 7y ago
      Well yeah, Microsoft developed TypeScript to resemble C#'s type system so naturally it will look a bit like Java? TS is far from being the de-facto standard though (maybe because it's centred around OOP?)
  - nickbauman 7y ago
    workers are clunky compared to how parallel/async computing is implemented in Clojure, for example.
  - doteka 7y ago
    Compared to any language that has threads, workers are a usability nightmare and come with a million caveats. (For example they have major limitations in Electron, which is one place where having threads would be very convenient. The current best practice is to spin up an entire new hidden browserwindow instead which is frankly insane.)
    - vips7L 7y ago
      We offload anything that would need a thread to another process on the JVM for electron. I know a few other projects offload to a GO process.
hderms 7y ago
I'm not an expert on this subjectrobably the best thing the JVM has going for it is two things: many world class extremely tunable garbage collectors and acres of software written for it already. V8 has tons of software written for it but the focus is somewhat different (see Apache projects)
bpicolo 7y ago
The ecosystem of supporting libraries for Java is bigger than any other ecosystem. There's a mature library for every concept in existence. The Node ecosystem has a lot, but for server-side libs it still doesn't reach the coverage of Java. Apache, for example, supports a ton of Java libraries for which there's little competition, certainly not well distributed across language ecosystems. PDFBox, Lucene, etc. When you're in the nitty gritty of automating business processes, that sort of thing is invaluable. For CRUD-style web services, any language will do the trick. (I say this as not a big fan of Java the language) Python also has a similarly wide ecosystem, and does better specifically in some regions than any other language, like ML, but a different set of focus areas. It's probably the other top contender for business-process automation, but big enterprises prefer OOP/static typing for typical work. C# probably comes close in many areas, but there's still a split between the .net core and not-core ecosystems for the long tail of libraries, and no open-source powerhouse quite like Apache in the mix. (C/C++ might fall here somewhere too, but I don't know nearly enough about those language ecosystems to comment)
- MaxBarraclough 7y ago
  > There's a mature library for every concept in existence If you'll forgive a light trolling: how about ahead-of-time compilation, allocating small objects on the stack, UTF-8, compile-time asserts, or SIMD support? (Was going to include await/async, but then I remembered EA Async.) I realise this is a little off topic, but the JVM isn't without limitations. (Or perhaps all my examples are wrong - disproof welcome!)
  - bpicolo 7y ago
    Yeah, I'm thinking higher level, for sure, rather than limitations of the language - fair to call out. You can specify UTF-8 as the default charset (unless you mean for identifiers?) and Grall does exist for AOT.
    - MaxBarraclough 7y ago
      I thought Java's String was hard-coded to UTF-16. Is that mistaken?
lunias 7y ago
I'm not sure they meant any language. It sounds like they're advocating for using a non-Java language that compiles to bytecode to be run on the JVM. E.g. Kotlin, Scala, Clojure, Groovy, Jython, JRuby etc. The goal of the JVM is "write once, run anywhere". v8 achieves the same, but for languages that compile to Javascript. E.g. Dart, Elm, Typescript, CoffeeScript, ClojureScript etc. I think the real choice to be made is ecosystem. There are languages to suit every programming style in either camp. The availability and quality of packages in the Java ecosystem is higher IMO (use Spring and it just works). Node has non-blocking I/O by default; it's possible to implement the same in Java, but you have to make a conscious decision to do so. Java has threads, but Node has workers. Java can have a longer startup time and is better suited for servers with high uptime, Node starts up quick and is easier to use in on demand situations etc. I don't really know why you would, but there is RingoJS if you want to run Javascript on the JVM for some reason.
pron 7y ago
It has an unmatched combination of stability, productivity, performance, observability and ecosystem size. There are few if any platforms that offer. E.g. very few platforms, if any, offer the kind of low-overhead, always-on, in-production deep profiling that Java has [1], certainly not platforms with similar performance. [1]: https://blogs.oracle.com/javamagazine/java-flight-recorder-and-jfr-event-streaming-in-java-14 https://blogs.oracle.com/javamagazine/java-flight-recorder-a...

nickbauman 7y ago

I don't think you can compare V8 with the JVM. For starters, last time I checked, V8 is still single threaded, isn't it? Also it seems like future versions of JS are embracing things that make it look like they're envying Java, which seems like it's going in the wrong direction.

t0astbread 7y ago
You can do parallel computing in Node and the browser using workers. Also what features do you mean that "envy Java"?
- nickbauman 7y ago
  static typing seems to be on the horizon (facepalm)
  - t0astbread 7y ago
    Well yeah, Microsoft developed TypeScript to resemble C#'s type system so naturally it will look a bit like Java? TS is far from being the de-facto standard though (maybe because it's centred around OOP?)
- nickbauman 7y ago
  workers are clunky compared to how parallel/async computing is implemented in Clojure, for example.
- doteka 7y ago
  Compared to any language that has threads, workers are a usability nightmare and come with a million caveats. (For example they have major limitations in Electron, which is one place where having threads would be very convenient. The current best practice is to spin up an entire new hidden browserwindow instead which is frankly insane.)
  - vips7L 7y ago
    We offload anything that would need a thread to another process on the JVM for electron. I know a few other projects offload to a GO process.

hderms 7y ago

I'm not an expert on this subjectrobably the best thing the JVM has going for it is two things: many world class extremely tunable garbage collectors and acres of software written for it already. V8 has tons of software written for it but the focus is somewhat different (see Apache projects)

bpicolo 7y ago

The ecosystem of supporting libraries for Java is bigger than any other ecosystem. There's a mature library for every concept in existence. The Node ecosystem has a lot, but for server-side libs it still doesn't reach the coverage of Java. Apache, for example, supports a ton of Java libraries for which there's little competition, certainly not well distributed across language ecosystems. PDFBox, Lucene, etc. When you're in the nitty gritty of automating business processes, that sort of thing is invaluable. For CRUD-style web services, any language will do the trick. (I say this as not a big fan of Java the language) Python also has a similarly wide ecosystem, and does better specifically in some regions than any other language, like ML, but a different set of focus areas. It's probably the other top contender for business-process automation, but big enterprises prefer OOP/static typing for typical work. C# probably comes close in many areas, but there's still a split between the .net core and not-core ecosystems for the long tail of libraries, and no open-source powerhouse quite like Apache in the mix. (C/C++ might fall here somewhere too, but I don't know nearly enough about those language ecosystems to comment)

MaxBarraclough 7y ago
> There's a mature library for every concept in existence If you'll forgive a light trolling: how about ahead-of-time compilation, allocating small objects on the stack, UTF-8, compile-time asserts, or SIMD support? (Was going to include await/async, but then I remembered EA Async.) I realise this is a little off topic, but the JVM isn't without limitations. (Or perhaps all my examples are wrong - disproof welcome!)
- bpicolo 7y ago
  Yeah, I'm thinking higher level, for sure, rather than limitations of the language - fair to call out. You can specify UTF-8 as the default charset (unless you mean for identifiers?) and Grall does exist for AOT.
  - MaxBarraclough 7y ago
    I thought Java's String was hard-coded to UTF-16. Is that mistaken?

lunias 7y ago

I'm not sure they meant any language. It sounds like they're advocating for using a non-Java language that compiles to bytecode to be run on the JVM. E.g. Kotlin, Scala, Clojure, Groovy, Jython, JRuby etc. The goal of the JVM is "write once, run anywhere". v8 achieves the same, but for languages that compile to Javascript. E.g. Dart, Elm, Typescript, CoffeeScript, ClojureScript etc. I think the real choice to be made is ecosystem. There are languages to suit every programming style in either camp. The availability and quality of packages in the Java ecosystem is higher IMO (use Spring and it just works). Node has non-blocking I/O by default; it's possible to implement the same in Java, but you have to make a conscious decision to do so. Java has threads, but Node has workers. Java can have a longer startup time and is better suited for servers with high uptime, Node starts up quick and is easier to use in on demand situations etc. I don't really know why you would, but there is RingoJS if you want to run Javascript on the JVM for some reason.

pron 7y ago

It has an unmatched combination of stability, productivity, performance, observability and ecosystem size. There are few if any platforms that offer. E.g. very few platforms, if any, offer the kind of low-overhead, always-on, in-production deep profiling that Java has [1], certainly not platforms with similar performance. [1]: https://blogs.oracle.com/javamagazine/java-flight-recorder-and-jfr-event-streaming-in-java-14 https://blogs.oracle.com/javamagazine/java-flight-recorder-a...