Erlang/OTP 29.0 Release

43 points by ciprian_craciun

joladev

Excited to see what comes out of native records

ciprian_craciun

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...
- calvin
  
  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?
- mt
  
  You can automate the extracting: https://github.com/burrito-elixir/burrito
  - ciprian_craciun
    
    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:
    
    a single executable that is actually the BEAM VM, plus as described below;
    
    (optionally) this executable should have linked statically all other libraries required by the VM which are not part of glibc; (bonus points if it also includes the NIF *.so required by the various Erlang applications;)
    
    (mandatory) then, as part of the executable, in some section, it should have stored the actual BEAM code (plus configuration files, and other private files); (the BEAM VM when starting, should see if perhaps there isn't such a section, and if found, execute it directly;) (this requires special code from the OTP, so that priv files, .app and various configuration files are read not from disk (resolved via the PATH-like list) but from memory;)
    
    (mandatory) if the BEAM VM is started in this way (i.e. with embedded byte-code), then any arguments it receives, should be considered application arguments, not VM arguments (plus application); (customization should be embedded in the executable in another special section;)
    
    In this way, such an Erlang "self-contained executable" would behave identically with any C/C++/Go/Rust/Zig executable.
- lpil
  
  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.