3 ms·

The true benefit of the JVM is the ecosystem. There is a load of ancillary stuff like database drivers and web frameworks, to more exotic stuff like rendering P

The true benefit of the JVM is the ecosystem. There is a load of ancillary stuff like database drivers and web frameworks, to more exotic stuff like rendering PDFs, that every application needs. It doesn't add value to work on this stuff yourself but you can just about guarantee there will be on the library on the JVM that does what you want. It might not be pretty but it will exist somewhere. This is particularly the case in the big data space, where all the major frameworks are run on the JVM. For many people, interfacing with legacy Java code is also important. And yes, I advocate using Scala much like Haskell. (There is also the performance of the JVM, which is pretty good, but this is only a point worth mentioning when comparing to languages like Ruby and Python. Most functional languages have good compilers and runtimes.)

lomnakkus 12y ago
Honestly, the IME the JVM ecosystem isn't that great. I think you could probably find a bigger/better ecosystem for C/C++ at this point in time. (Even going as far as Big Data or PDF support, but I know nothing of the former.) I recognize that the JVM has (for several years at least) been sold on this premise, but I just don't think it's true, or at least not true to the extent that the PR says. Don't get me wrong... it's good but not great (in my conception of things). Even if you find some indispensable JVM-based library, then why not just shell out to an executable jar (or whatever) that does what you need? At least you'll avoid classpath-hell that way.
- nostrademons 12y ago
  Outside of Google, the big-data options for C++ are actually pretty disappointing. There are some toy MapReduce frameworks, but nobody's really put the work into building a solid, production-ready big-data framework the way Hadoop or Spark has. In some ways it's a little surprising and disappointing, as C++ really does have significant efficiency advantages over Java for big-data work, and a company that did invest in this could easily realize a factor of 3x or so improvement in their data-processing costs. (Perhaps that's why we haven't seen it, and there are companies that have developed their own frameworks internally but don't want their competitors to use them.)
- noelwelsh 12y ago
  Maybe, maybe not, but I had three criteria and C/C++ certainly don't meet the other two. (There are other criteria we use when making these kinds of decisions, like performance, speed of development, availability of developers etc, but I thought we were talking about modern functional languages so I didn't bring these up.) I think the language that hasn't the biggest chance of upsetting the JVM is Rust. Mozilla talk about Rust as a C/C++ replacement, but I actually expect they'll see more interest from JVM focused developers. A lot of current systems programming uses the JVM (all the aforementioned big data systems like Kafka, Cassanda, HBase, etc.) A number of these systems have issues with the JVM, particularly GC performance on large heaps, and Rust would be very attractive here. Scala developers in particular are used to modern language idioms and so could relatively easily switch to Rust.
  - lomnakkus 12y ago
    > (There are other criteria we use when making these kinds of decisions, like performance, speed of development, availability of developers etc, but I thought we were talking about modern functional languages so I didn't bring these up.) Oh, indeed -- and I might even agree on the non-platform arguments. And I'm not discounting those -- I'm just saying that the JVM (not Java/Scala/Groovy/whatever) argument is overstated :). IMO, as always. Agreed about Rust as well, I think. Java programmers are already used to the verbosity (tongue firmly in cheek ;)). EDIT: Actually, come to think of it... many of the criteria you mentioned would apply to JavaScript developers, wouldn't they?

lomnakkus 12y ago

Honestly, the IME the JVM ecosystem isn't that great. I think you could probably find a bigger/better ecosystem for C/C++ at this point in time. (Even going as far as Big Data or PDF support, but I know nothing of the former.) I recognize that the JVM has (for several years at least) been sold on this premise, but I just don't think it's true, or at least not true to the extent that the PR says. Don't get me wrong... it's good but not great (in my conception of things). Even if you find some indispensable JVM-based library, then why not just shell out to an executable jar (or whatever) that does what you need? At least you'll avoid classpath-hell that way.

nostrademons 12y ago
Outside of Google, the big-data options for C++ are actually pretty disappointing. There are some toy MapReduce frameworks, but nobody's really put the work into building a solid, production-ready big-data framework the way Hadoop or Spark has. In some ways it's a little surprising and disappointing, as C++ really does have significant efficiency advantages over Java for big-data work, and a company that did invest in this could easily realize a factor of 3x or so improvement in their data-processing costs. (Perhaps that's why we haven't seen it, and there are companies that have developed their own frameworks internally but don't want their competitors to use them.)
noelwelsh 12y ago
Maybe, maybe not, but I had three criteria and C/C++ certainly don't meet the other two. (There are other criteria we use when making these kinds of decisions, like performance, speed of development, availability of developers etc, but I thought we were talking about modern functional languages so I didn't bring these up.) I think the language that hasn't the biggest chance of upsetting the JVM is Rust. Mozilla talk about Rust as a C/C++ replacement, but I actually expect they'll see more interest from JVM focused developers. A lot of current systems programming uses the JVM (all the aforementioned big data systems like Kafka, Cassanda, HBase, etc.) A number of these systems have issues with the JVM, particularly GC performance on large heaps, and Rust would be very attractive here. Scala developers in particular are used to modern language idioms and so could relatively easily switch to Rust.
- lomnakkus 12y ago
  > (There are other criteria we use when making these kinds of decisions, like performance, speed of development, availability of developers etc, but I thought we were talking about modern functional languages so I didn't bring these up.) Oh, indeed -- and I might even agree on the non-platform arguments. And I'm not discounting those -- I'm just saying that the JVM (not Java/Scala/Groovy/whatever) argument is overstated :). IMO, as always. Agreed about Rust as well, I think. Java programmers are already used to the verbosity (tongue firmly in cheek ;)). EDIT: Actually, come to think of it... many of the criteria you mentioned would apply to JavaScript developers, wouldn't they?