Why use a knife when you can use our EveryThingCutter-9000 that requires a week of training to operate.

Yes it is. Though until the last paragraph everything is done more or less to be an idiomatic approach to this task rather than "just optimisation". The VM flags part though is solely "optimizing for the benchmark, by cutting features that we would have needed in real-world scenarios". The "RemoteCall" code is pretty idiomatic approach to such problem.

i have the feeling the very first optimization ( not using the VM real green thread, but something lighter that doesn't provide debugging tools) is also something you wouldn't like to have in the real world..

It is using VM green thread, just more primitive one. Just to be more like other implementations (except anode) in original article that do bare minimum to run. Also, this isn't that unusual to use just `spawn/1` for simple and short "one-off" processes.

It is in the original article [1], though I was made aware that Go implementation is also incorrect as `defer` in it make the memory usage to substantially raise. So instead of:

        defer wg.Done()
        time.Sleep(10 * time.Second)

In original article it should be:

        time.Sleep(10 * time.Second)
        wg.Done()

And memory usage will drop about 2x. I am no Go nor Java developer so I cannot say anything more.

[1]: https://pkolaczk.github.io/memory-consumption-of-async/

Author here. If you have any questions, here I am.

But what would be a point of doing that?

That section was removed as it was leftover from the early drafts.

I have removed that part as it was accidental leftover from the early drafts that I forgot to remove.

I know about Podman, I just wanted to focus on systemd without additional tooling.

Erlang VM startup is ok, but it is not ultra fast, and it can be easily slowed down with many modules in releases or slow applications. Additionally as it was said - Erlang works best in case of long-running instances where the VM is handling spawning and managing of short lived internal processes.

First draft of this article also included the socket activation and FD passing section, but these were making the article way to long, so I moved them to the Part 2 where I will have more space for them. With socket activation Erlang VM startup time is negligible problem.

At the beginning I wanted to add all that information and options, but I thought that it can be overwhelming in this article. I wanted to focus on Erlang <-> systemd communication and basic options.

However it may be nice follow-up article where I will describe full hardening process.

Oh, I didn't know about `SocketBindDeny=` and `SocketBindAllow=`. This option may be a little troublesome in case of Distributed Erlang, but in recent versions it can be circumvented. Thanks, I will add it as a better option than adding capabilities.