5 ms·

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

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?

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?