Hacker News Reader

Comment by smabie | Hacker News Reader

Languages like Ocaml and Haskell are both around Java speed, though. And even though both languages have more primitive GCs than Java, in practice, they tend to use less memory and have lower latency.

I can only think of one situation when using Ocaml that I had to think about the GC (I was allocated huge floating point arrays), while I can't even count the number of times I had to deal with a runaway heap or unacceptably long pauses. The last JVM version I've really used was 7, though. Perhaps things have gotten better?

View on HN

This point has to be noted. There are languages other than Go with optimizing compilers, and those compiling to C. Go has focus on fast compiles and doesn't do much optimization. And no generics means many things are done using reflection / reimplemented poorly and can be slow.

OCaml, Haskell, SML with MLTon, Nim, D, Crystal etc.. have better performance than Java unless one benchmarks a tight numerical loop. Not to mention memory consumption.

JITs are oversold. JIT may be great for optimizing Python or Lua. Moreover java is just poorly designed from a performance standpoint - no value types, virtual by default.

Value types are coming, EA are available and virtual by default has long stopped being a problem thanks to StrongTalk optimization regarding de-virtualization across shared libraries and call caches.

That "better performance" isn't reflecting in market share.

Performance and market share are different things.

Not when adoption is at play.

What point are you trying to make?

That the beauty of "OCaml, Haskell, SML with MLTon, Nim, D, C" and lack effectiveness of JIT compilers have done very little for them to take market share from Java in any significant way.

In case of C, on the contrary it lost to Java the majority of the roles it owned during 90's enterprise distributed computing applications.

Yes, things have gotten a lot better. G1GC is the default now and we have free options like ZGC and ShenandoahGC for low latency options. Of course there are the IBM options and Azul as well.

Scalar replacement got better, and with Graal partial evaluation gives reduced heap allocation rates. Which can have big impacts.

Future is even more bright with inline (value) types going towards even less allocations and better memory layouts.

You mean partial escape analysis and scalar replacement for reduced heap allocation rates. Partial evaluation is something else, also pretty useful but for other reasons.

Yes I did ;) Thanks for the helpful correction

Reply on news.ycombinator.com