Is it possible to use Erlang VM just by copying it? Or is there an Erlang VM that can be used this way?
(Docker and similar tools are great, but are not in the context of the question)
What do you mean by “copying”?
Isn’t running the installer or installing a package “just copying” files from one place to another?
Or do you mean, you want to build a fully selfcontained package which has everything included and can be run everywhere? Well, this is possible by building releases and embedding the erlang runtime. They still will have some dependencies on dynamically linked libraries as glibc/musl, openssl, wx and others, depending on your build host.
Assuming that imaginary EVM resides in a directory named evm, then it would be copied to a directory on the server named evmx.
Then it would be possible to run $ ./evmx/bin/iex some-code-or-script.ex or $ ./evmx/bin/erl ....
what is the purpose? running different erlang/elixir versions? deployment? other?
Ease of deployment. In the same sense it is possible to deploy a single Go binary.
Seems it is not possible because of external dependencies.
At the end, the erlang virtual machine doesn’t care for where it can find its bits and pieces, as long as it can find them.
Some environment variables here, some config there, and a symlink everywhere, perhaps something else elsewhere.
But in general I’d advise to just use your distributions package manager to ensure everything is set up and placed correctly.
This is possible, as I said, through OTP-releases.
The dependencies that arise are pretty standard on most systems (glibc and musl are base building blocks on every linux, and even in go you have to pick the correct one or everything will fail).
OpenSSL should be available on most platforms as well, at least you want to SSH into that machine, don’t you?
WX is rarely a requirement.
In Go you have to maintain dependencies as well as soon as you use some C bindings (which are used in the erlang and elixir world more often).
Personally I do not like the fact that go implements vital parts itself, I’d be much happier if it were just using OpenSSL (or whatever is available) to make me able to update it when necessary, without needing to update the complete compiler chain when holes get public…
Statically linked binaries are fine, but golang does it too much…
2 Likes
this…
