Hacker News Reader

Comment by xvilka | Hacker News Reader

At least OCaml and Haskell compile into the native code, thus faster by definition.

While it may be faster, the "by definition" part hasn't been true for years. The JVM can do some amazing stuff at runtime to outpace statically executed code.

Regardless, their principles [1] make the trade-offs clear:

- Developer productivity over runtime performance

- Correctness over performance

[1] https://flix.dev/principles/

I’m not an expert but my understanding is that modern JIT can be faster than ahead of time compilation because the JIT has runtime information, so you get profile guided optimization for free.

Warm up takes a while but then it can be very fast. For long running servers this works quite well.

I don't think that is true. For example, Java beats OCaml on some benchmarks at: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

It seems that the situation is not as clear cut as your post suggests.

(I am one of the authors of Flix)

Has anyone tried runnig those benchmarks with AOT Java? Microbenchmarks like these tell absolutely nothing about general performance because they are short-lived. JVM is a beautiful piece of engineering and I believe you guys chose well this platform to host it, always hoped for a ML-inspired language running on the JVM and this looks like it.

> Has anyone tried runnig those benchmarks with AOT Java?

Yes. GraalVM CE 20.0.0 and native-image.

> …because they are short-lived.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Because "general performance" is ill-defined.

Because tiny tiny programs aren't like other programs.

At least this compiles to bytecode, so more interopabe with tons of libraries and Java tools and infrastructure by definition.

There are lots of different goals and tradeoffs...

Reply on news.ycombinator.com