6 ms·

Also a lot of the de-facto Big Data/NoSQL/Distributed Computing stack is Java(/Scala). Hadoop, HBase, Cassandra, Neo4j, Storm, its actually pretty interesting t

Also a lot of the de-facto Big Data/NoSQL/Distributed Computing stack is Java(/Scala). Hadoop, HBase, Cassandra, Neo4j, Storm, its actually pretty interesting to note that most of the popular nosql solutions are in Java. On top of that its the number 3 language on Github. I'm not a huge fan of Java but I'd be pretty surprised if someone was saying Java wasn't relevant. Don't quote me on this, but its also the fastest language you are going to get without pulling out C/C++. When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java.

octo_t 13y ago
JVM crypto (i.e. using encryption libraries) can be faster than native because of function inlining (whereas in C/C++ you don't inline across libraries at link time because an update to the crypto library would require a recompile).
jimmaswell 13y ago
Java and Mono have been shown to be roughly comparable overall in speed, each a bit worse or better than the other in some ways, I've read.
- headius 13y ago
  Shown where? Mono's JIT is nowhere near as good as OpenJDK/Hotspot.
  - jimmaswell 13y ago
    http://stackoverflow.com/a/9138207 http://stackoverflow.com/a/9138207 I think this is the answer I was thinking about.
sjg007 13y ago
It's also because of automatic garbage collection and the fact that programmers today can't handle memory management.
- octo_t 13y ago
  Programmers in the past couldn't handle memory management either.
- nu2ycombinator 13y ago
  Programmers today do not have to handle memory management because of JVM. Programmers yesterday could not handle memory management that's why jvm came into existence.
- asperous 13y ago
  It's because of automatic compilation and the fact that programmers today can't handle register management. It's because of integrated circuits and the fact that programmers today can't handle voltage management.
elithrar 13y ago
> When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java. As a Go "fan": it hasn't. It's close in some things, faster in a few, but the JVM has years (and years) of performance tuning in it, and Go won't unequivocally beat Java for some time (if ever). (This WiFi connection is failing me right now, but there's a good number of Go vs. Java benchmarks out there, for whatever benchmarks are worth)
- eranation 13y ago
  I was only referring to the Web framework benchmark, where Go (1.1 I think) is taking the lead over Servlets on many of the benchmarks. Still impressive.
  - deleted 13y ago
    [deleted]
- nemothekid 13y ago
  That was my reaction as well. We are using Go in production here and I'm very much a Go fan, but I'd be surprised if Go caught up to Java in so little time.
  - eranation 13y ago
    I was referring to this benchmark: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
    - continuations 13y ago
      That benchmark makes it clear Go has not caught up to Java in performance. Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).
      - eranation 13y ago
deleted 13y ago
[deleted]

octo_t 13y ago

JVM crypto (i.e. using encryption libraries) can be faster than native because of function inlining (whereas in C/C++ you don't inline across libraries at link time because an update to the crypto library would require a recompile).

jimmaswell 13y ago

Java and Mono have been shown to be roughly comparable overall in speed, each a bit worse or better than the other in some ways, I've read.

headius 13y ago
Shown where? Mono's JIT is nowhere near as good as OpenJDK/Hotspot.
- jimmaswell 13y ago
  http://stackoverflow.com/a/9138207 http://stackoverflow.com/a/9138207 I think this is the answer I was thinking about.

sjg007 13y ago

It's also because of automatic garbage collection and the fact that programmers today can't handle memory management.

octo_t 13y ago
Programmers in the past couldn't handle memory management either.
nu2ycombinator 13y ago
Programmers today do not have to handle memory management because of JVM. Programmers yesterday could not handle memory management that's why jvm came into existence.
asperous 13y ago
It's because of automatic compilation and the fact that programmers today can't handle register management. It's because of integrated circuits and the fact that programmers today can't handle voltage management.

elithrar 13y ago

> When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java. As a Go "fan": it hasn't. It's close in some things, faster in a few, but the JVM has years (and years) of performance tuning in it, and Go won't unequivocally beat Java for some time (if ever). (This WiFi connection is failing me right now, but there's a good number of Go vs. Java benchmarks out there, for whatever benchmarks are worth)

eranation 13y ago
I was only referring to the Web framework benchmark, where Go (1.1 I think) is taking the lead over Servlets on many of the benchmarks. Still impressive.
- deleted 13y ago
  [deleted]
nemothekid 13y ago
That was my reaction as well. We are using Go in production here and I'm very much a Go fan, but I'd be surprised if Go caught up to Java in so little time.
- eranation 13y ago
  I was referring to this benchmark: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
  - continuations 13y ago
    That benchmark makes it clear Go has not caught up to Java in performance. Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).
    - eranation 13y ago

deleted 13y ago

[deleted]