Hacker News Reader

Comment by neonsunset | Hacker News Reader

Erlang is interpreted. It is in the same class of performance as Python and Ruby. If you want a relatively high-level and performant alternative with great concurrency support your options are C#/F# (you are likely find the tooling pleasant) and perhaps JVM languages once they adopt structured concurrency (but you are likely to find the tooling less pleasant).

Graal Native Image support is very niche and does not provide the same level of experience as .NET’s NativeAOT nor has tricks up its sleeve like static linking with native libraries.

View on HN

> Erlang is interpreted.

https://www.erlang.org/blog/the-road-to-the-jit/

Thanks! I was briefly aware that BEAM has JIT capability but performance numbers usually put it next to other languages with interpreted bytecode so I assumed it was either not enabled or used in some specific scenarios. I should update my knowledge.

It's possible your previous knowledge was based on HiPE, which to my understanding was kind of sucky.

The new JIT in Erlang/OTP 26 is called BeamASM and is based upon asmjit

Really...? In my experience, whilst Erlang is slower than most AOT languages, its an order of magnitude faster than Python or Ruby. Most benchmarks I've seen also back that up.

Unlike Python it scales with cores perfectly, which makes sense given that’s what BEAM is designed for, but the baseline cost of operations is in the same group.

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

It’s a bytecode-interpreted language. If it were JIT and statically typed we would have seen drastically different results. Also JIT output being slower than static compilation is a myth. When compilation happens does not dictate the kind machine code the compiler can produce (mostly, compiler throughput and JIT-time optimizations do influence this, but are not a strict limitation).

Erlang is JIT compiled since 2021.

Grandparent is also correct in that it tends to be faster than Python et al. If we have a deeper look at the benchmarks [1][2], as long as there is no significant amount of bignum arithmetic (where both call C code) or standard IO involved [3] it's consistently faster than Python, and often by a large margin.

[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[3]: Standard IO goes through several indirections to make it work with remote REPLs; other forms of IO do not suffer from this.

For your convenience:

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

> no significant amount of bignum arithmetic

There is none shown in the charts. There is none shown elsewhere apart from where aribitrary precision arithmetic is shown explicitly: pi-digits.

The memory taken and timeouts for Erlang are concerning in those benchmarks. And this is when compared to Python!

Perhaps when programs written for pre-R12 are now at R27.

You can statically link with native libraries if you have static versions of them in GraalVM:

https://www.graalvm.org/latest/reference-manual/native-image...

Does it let you bring your own .a/.lib and statically link it into the final product? In .NET you can pass DirectPInvoke + NativeLibrary build properties and link with anything provided the imports don't conflict (because at the final step it's the system-provided linker that statically links together the components nativeaot binaries comprise of, so you are effectively just adding another compilation object).

For example, I can take a mimalloc.lib/.a, link it into the binary and the pinvokes into its mi_malloc, mi_realloc, etc. will all be just direct calls + branch checks for GC poll if applicable (well, you need to suppress gc frame transition but it's still about three steps in total). It will be just a single static bundle at the end.

I know that conceptually GraalVM Native Image and NativeAOT are similar tools, but they mostly seem that way at a distance and at closer inspection they only partially overlap, much like C# and Java themselves do.

You can yes although the docs don't make that obvious.

https://www.blog.akhil.cc/static-jni

You can also use the FFI to avoid JNI.

I tend to feel that static linking is overrated. The moment you want easy upgrades of your app you need extra infrastructure anyway, and every tool for distributing such programs can handle directories as well as files.

> I tend to feel that static linking is overrated.

I agree. My response was just meant to indicate that NativeAOT has comparatively more effort and focus in .NET ecosystem than GraalVM's Native Image in JVM's, and as a result is an option that is easier to opt into where it makes sense. There's an intention to make it play as nicely as possible with most common scenarios and ideally not require user input when enabling it even with difficult to analyze reflection scenarios.

> I tend to feel that static linking is overrated.

For me, the big win of static linking is startup time. Just mmap the executable and go. No need to slow down the startup process with the very branchy process of resolving and loading DLLs.

That's true, although pre-linking means the bad old days of apps spending most of their time in the dynamic linker during startup are mostly behind us even when a program uses a reasonable number of libraries.

Reply on news.ycombinator.com