11 ms·

Looooong after the other languages have done it, Java comes around to doing it. Seriously, the best thing about Java is the JVM where you can choose a better la

Looooong after the other languages have done it, Java comes around to doing it. Seriously, the best thing about Java is the JVM where you can choose a better language than Java to program with it and get all the benefits of the JVM.

JMTQp8lwXL 6y ago
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 6y 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 6y ago
    You can do parallel computing in Node and the browser using workers. Also what features do you mean that "envy Java"?
    - nickbauman 6y ago
      static typing seems to be on the horizon (facepalm)
      - t0astbread 6y 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 6y ago
      workers are clunky compared to how parallel/async computing is implemented in Clojure, for example.
    - doteka 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago
        I thought Java's String was hard-coded to UTF-16. Is that mistaken?
- lunias 6y 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 6y 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...
vips7L 6y ago
The Java implementations are typically better than their counter parts. See Kotlins when vs switch expressions in Java.
- nickbauman 6y ago
  Kotlin's optional implementation is much better tho. It's not a universal.
- s-km 6y ago
  What about switch expressions in Java is better than Kotlin's when? I haven't personally used switch expressions in Java yet, but I've read the JEP and I don't see anything special or interesting.
pron 6y ago
That's like a compulsive hoarder seeing a guy buying a lawn chair and saying, oh, nice to see you finally catching up! That the Java language is slow to evolve while the Java platform evolves quickly has been one of the central strategies of Java since inception. In fact, James Gosling wrote back in 1997 how Java should only adopt language features loooong after they've been tried in other languages. It's worked very, very well. There's obviously a portion of users (<10%) who prefer a faster-moving, feature-rich language, and they have good options on the Java platform, but the Java language philosophy has been more attractive to a much larger group of developers. What is more interesting is not which features Java has chosen to adopt, but which ones it hasn't and won't: yes to lightweight threads but no to async/await; yes to pattern-matching but no to extension methods.
- Something1234 6y ago
  Can you list some of the interesting features that were not adopted in Java?
  - renewiltord 6y ago
    * Lambda syntax took years after it was mainstream. * I don't think Java still has string interpolation. * List, Map literals are not a thing Java has either. * Value types aren't in yet. * If as expressions. You have to use ternary. These aren't complaints. I know what I'm getting with Java. No hate.
    - vips7L 6y ago
      What's wrong with List.of(1,2,3) or Map.of("a", 1, "b", 2)? Switch expressions can do what if expressions do.
      - renewiltord 6y ago
        Nothing's wrong with that or with `String.format`. I just find it less ergonomic. Like I said, no complaints anywhere. You can just as well use `ExecutorService`s instead of async/await and all that.
bitcharmer 6y ago
Your use case doesn't have to be everyone else's. As opposed to Kotlin or Scala, Java is a great choice for performance-sensitive applications because there's (almost) no syntactic sugar that produces throw-away objects and induces unnecessary memory pressure.
- saagarjha 6y ago
  > (almost) no syntactic sugar that produces throw-away objects Strings and automatic boxing come to mind.
ashtonkem 6y ago
The thing I love about Java is that they continue to improve the language without: A) Throwing the kitchen sink in and making mistakes. B) Changing anything that already works. There are very few languages that continue to improve and provide such long term stability. More often than not more feature full languages end up forcing me to re-test or rewrite sections of my old code base for forwards compatibility.

JMTQp8lwXL 6y ago

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 6y 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 6y ago
  You can do parallel computing in Node and the browser using workers. Also what features do you mean that "envy Java"?
  - nickbauman 6y ago
    static typing seems to be on the horizon (facepalm)
    - t0astbread 6y 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 6y ago
    workers are clunky compared to how parallel/async computing is implemented in Clojure, for example.
  - doteka 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago
      I thought Java's String was hard-coded to UTF-16. Is that mistaken?
lunias 6y 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 6y 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...

vips7L 6y ago

The Java implementations are typically better than their counter parts. See Kotlins when vs switch expressions in Java.

nickbauman 6y ago
Kotlin's optional implementation is much better tho. It's not a universal.
s-km 6y ago
What about switch expressions in Java is better than Kotlin's when? I haven't personally used switch expressions in Java yet, but I've read the JEP and I don't see anything special or interesting.

pron 6y ago

That's like a compulsive hoarder seeing a guy buying a lawn chair and saying, oh, nice to see you finally catching up! That the Java language is slow to evolve while the Java platform evolves quickly has been one of the central strategies of Java since inception. In fact, James Gosling wrote back in 1997 how Java should only adopt language features loooong after they've been tried in other languages. It's worked very, very well. There's obviously a portion of users (<10%) who prefer a faster-moving, feature-rich language, and they have good options on the Java platform, but the Java language philosophy has been more attractive to a much larger group of developers. What is more interesting is not which features Java has chosen to adopt, but which ones it hasn't and won't: yes to lightweight threads but no to async/await; yes to pattern-matching but no to extension methods.

Something1234 6y ago
Can you list some of the interesting features that were not adopted in Java?
- renewiltord 6y ago
  * Lambda syntax took years after it was mainstream. * I don't think Java still has string interpolation. * List, Map literals are not a thing Java has either. * Value types aren't in yet. * If as expressions. You have to use ternary. These aren't complaints. I know what I'm getting with Java. No hate.
  - vips7L 6y ago
    What's wrong with List.of(1,2,3) or Map.of("a", 1, "b", 2)? Switch expressions can do what if expressions do.
    - renewiltord 6y ago
      Nothing's wrong with that or with `String.format`. I just find it less ergonomic. Like I said, no complaints anywhere. You can just as well use `ExecutorService`s instead of async/await and all that.

bitcharmer 6y ago

Your use case doesn't have to be everyone else's. As opposed to Kotlin or Scala, Java is a great choice for performance-sensitive applications because there's (almost) no syntactic sugar that produces throw-away objects and induces unnecessary memory pressure.

saagarjha 6y ago
> (almost) no syntactic sugar that produces throw-away objects Strings and automatic boxing come to mind.

ashtonkem 6y ago

The thing I love about Java is that they continue to improve the language without: A) Throwing the kitchen sink in and making mistakes. B) Changing anything that already works. There are very few languages that continue to improve and provide such long term stability. More often than not more feature full languages end up forcing me to re-test or rewrite sections of my old code base for forwards compatibility.