Erlang/OTP 29.0 Release
43 points by ciprian_craciun
43 points by ciprian_craciun
Excited to see what comes out of native records
Yes, the records feature, plus the native maps (introduced a few releases ago), takes Erlang closer to more modern languages.
Even though I don't see myself programming directly in Erlang, but instead use something like Elixir or Gleam, compiled to BEAM, I still see this as a major advantage because it opens up possibilities in the hosted languages.
If only they would also tackle the problem of packaging, to reach the state where Go / Rust is (i.e. I have my code, run the Erlang compiler, and here is a self-contained binary, which in case of Erlang includes the VM and bytecode), that would be neat!
I know there are OTP releases, which are just glorified TAR files, or one can use containers, etc. However nothing beats an executable that you can just run, and which doesn't require to extract thousands of small files to some temporary folder...
I know there are OTP releases, which are just glorified TAR files, or one can use containers, etc. However nothing beats an executable that you can just run, and which doesn't require to extract thousands of small files to some temporary folder...
I really don't see how extracting an archive is an ordeal. For an OTP app, I extract it somewhere in /opt or in a container. For a Go app, I copy it to /opt or in a container. What's so hard about that?
You can automate the extracting: https://github.com/burrito-elixir/burrito
That's exactly the problem I want to avoid: having to extract something in order to run my application.
There are a few issues with self-extracting executables:
first, it's inefficient because it needs to first extract everything and then to start (via execve) the actual tool; (but, say the extraction is cached, thus only the first time the tool is executed we get a penalty;) (also, I ignore the fact that someone, perhaps the application itself via reflection, finds these "cached files" and clobers them, which means either at each startup the tool has to check hashes, or we ignore this issue;) (I also ignore the various race-condition and corner-cases handling a shared cache;)
however, now we're left with a non-trivial amount of temporary extracted files, which we can't know if they are needed or not anymore, because we can't know if the tool is already running or not; (especially if it's a long-running service;) (should these files be placed in $TMPDIR or in ~/.cache?)
then, we have the requirement for a read-write scratch disk large enough to hold the temporary files; this means it can't run with a fully read-only file-system (thus no tight sandboxing), or on limited-RAM systems that usually boot from an SD-card, it eats the memory that could have been used for actual data; (for example a RaspberryPi Zero 2 W has 512 MiB of RAM;) (in these scenarios, I'm better off without a self-extracting tool;)
What I would like to have is:
glibc; (bonus points if it also includes the NIF *.so required by the various Erlang applications;)priv files, .app and various configuration files are read not from disk (resolved via the PATH-like list) but from memory;)In this way, such an Erlang "self-contained executable" would behave identically with any C/C++/Go/Rust/Zig executable.
Me too! I'm hoping there's the possibility of Elixir migrating to them so all three major BEAM languages can share one record type.