Earlier quoted context omitted.
>if I need to do low latency If the JVM is considered low latency I shudder to think what is high latency.
Java is pretty fast. Second most popular language in HFT. Can get it to a few tens of micros. Not as fast as C++ at sub 5 micros. So good enough for many latency sensitive apps.
Don’t call it a comeback: Java is still champ
241–250 of 557 posts
Re: Don’t call it a comeback: Java is still champ
#242Earlier quoted context omitted.
> Not as fast as C++ at sub 5 micros. Try sub 5 nanos. I was curious awhile ago at how fast C++ hash set lookup was compared to C#, and it consistently performed a lookup at 1 nanosecond. I tested with up to 6GB of data and then stopped because it was taking longer to generate random data then it was to run the benchmark 10,000 times. C++ benchmarks here[0]. It's a bit more complicated then just a pure lookup since I…
> and it consistently performed a lookup at 1 nanosecond. TBH I'm skeptical that you are measuring what you think you are measuring. There are a lot of micro-benchmarking pitfalls, like dead code elimination, loop-invariant code motion, unrolling, and other issues. Unless you actually looked at the machine code coming out of the compiler, you're measuring something you don't understand. E.g. 1 nanosecond is roughly 3…
Don't take my word for it though, you can take a look at the Robin Hood benchmarks[0]. Robin Hood unordered map is a competitive hash map that's performed much better than the STL for me in many cases. They average a 4 nanosecond lookup speed for a hash map with 2000 elements and an integer key.
> Did you benchmark against Java's HashMap?
I benchmarked against C#, which has a runtime that performs similar if not better than the JVM. The C# code was a ~~few microseconds~~ around 130 nanoseconds. Which is still very fast, but up to 100x slower. (And yes, this was after warming up the code. I used benchmark dot net[1] here.). This is a really easy benchmark to set up. If you doubt me you can write a couple of benchmarks in under an hour and compare yourself.
[0]: https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-04-0...
Re: Don’t call it a comeback: Java is still champ
#243Earlier quoted context omitted.
Indeed. Shutoff Garbage collection completely and it can work. (And make sure your Java code creates no garbage - which is a new type of programming in and of itself)
Maybe I’m taking your comment wrong, why is this a bad thing? What other GC’d language just lets you turn it off?
Re: Don’t call it a comeback: Java is still champ
#244Earlier quoted context omitted.
Have you ever had to maintain an old enterprisey Java thing? It's pure hell. Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml…
> Have you ever had to maintain an old enterprisey thing? It's pure hell. FTFY. And yes, I have worked on old Java apps, they are not worse than any other app that lived for a similarly long timeframe (and the fact that there seem to be more old monstrosity in Java may just mean that it actually manages to do its work written in java, and not fail in some other language). Why don’t you have a bin repo for old junit v…
If you, or a third-party exposed a "Optional", then it's the API mistake. You're never supposed to expose an Optional as either input or output; they're clunky implementation details of the Java Maybe monad.
Re: Don’t call it a comeback: Java is still champ
#245The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…
Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…
Re: Don’t call it a comeback: Java is still champ
#246The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…
The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Please explain. What kind of crazy jack write servers in C? (Real question, trying to learn here)
Re: Don’t call it a comeback: Java is still champ
#247Earlier quoted context omitted.
Even if you don't care about performance and only care about simplicity OOP is really hard to rationalise about.
Java has supported (mostly) functional programming constructs since 1.8 (which was 2014), so you can realistically use it without doing too much OO. I've observed, though, that people who complain about OO in Java usually write top-down procedural code rather than functional-style code, which is far, far worse.
Re: Don’t call it a comeback: Java is still champ
#248Earlier quoted context omitted.
I might be wrong but I think they stopped working on major new versions for a decade. There seems to be Java 6 or 1.6 or whatever for a really long time. Like Netscape's version 4.
Who stopped what? Java 19 is the upcoming release.
I’m sure most people on HN are aware there are new versions of Java now.
Edit: ‘there seems’ in my original comment should be ‘there seemed’ which may have caused confusion.
Re: Don’t call it a comeback: Java is still champ
#249Earlier quoted context omitted.
I read this was semi-standard memory management in the early lisp machine days, because that gc was so slow.
Early Lisp (even pre-lispm) had no GC at all -- it just allocated until it ran out. Memory reclamation was done by saving the heap to tape and then reading it back -- only live objects were saved. So it was kind of GC with extra steps; the first GC algorithms removed the steps.
Re: Don’t call it a comeback: Java is still champ
#250Being taught intro Java in high school (mid 2000s for me) was excruciatingly boring and caused me to write off majoring in computer science or working as a programmer. Today I'm a software engineer with experience in JavaScript, Ruby, Python, Elixir... maybe it's time for me to give Java another try.