Comment by neonsunset

Comment by neonsunset 9 days ago

15 replies

View on Hacker News

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.

igouy 9 days ago

> Erlang is interpreted.

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

Reply View 2 replies
  • neonsunset 9 days ago

    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.

    Reply View 1 reply
    • SirGiggles 9 days ago

      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

      Reply View 0 replies
shakna 9 days ago

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.

Reply View 5 replies
  • neonsunset 9 days ago

    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).

    Reply View 4 replies
mike_hearn 9 days ago

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...

Reply View 5 replies
  • neonsunset 9 days ago

    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.

    Reply View 4 replies
    • mike_hearn 9 days ago

      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.

      Reply View 3 replies
      • neonsunset 9 days ago

        > 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.

        Reply View 0 replies
      • mwcampbell 8 days ago

        > 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.

        Reply View 1 reply
        • mike_hearn 8 days ago

          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 View 0 replies