Comment by Alupis

Comment by Alupis 14 hours ago

The BEAM is fascinating for many reasons, including being register-based.

I really just wish the BEAM was portable in the way the JVM is. The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball.

This means you either must use your distro package manager's version, or compile from scratch. If you want to control the exact version that's being used across your team (via `asdf` or similar), this practically means you'll end up compiling the BEAM over and over...

MisterTea 34 minutes ago

> The BEAM is fascinating for many reasons, including being register-based. > I really just wish the BEAM was portable in the way the JVM is.

Inferno is both register based and highly portable using the same tool chain as Plan 9 which runs seamlessly across multiple architectures. This eventually evolved into the Go tooling as Rob Pike came up with the Plan 9 design and worked on it with Ken Thompson. https://seh.dev/go-legacy/

Unfortunately Inferno was never fully completed and bit-rotted a bit but it still builds on systems with 32 bit support. There are various forks and even an attempted 64 bit version. To me its a great design as it not only runs on bare metal but also has a hosted option so it runs under Plan 9, Windows, MacOS/Unix/BSD/Linux. Talk about a portable OS...

Reply View 1 reply

ux266478 24 minutes ago

To be clear, Inferno is the operating system. The virtual machine is Dis. There exist a few examples[1] of 64-bit Dis, but usually the problem people run into is making the Limbo[2] compiler spit out 64-bit code.
It's rather unfortunate, Inferno is a really nice system with a lot of interesting reference stuff implemented like a typed shell[3]. It's also Plan 9 in a box with all the accoutrements, and knowers will have jumped out of their seat at the implication. I can't understate how cool the Inferno system is.
[1] - https://github.com/Plan9-Archive/9ferno
[2] - https://en.wikipedia.org/wiki/Limbo_(programming_language)
[3] - https://inferno-os.org/inferno/man/2/alphabet-intro.html

Reply View | 0 replies

valorzard 12 hours ago

You want https://github.com/burrito-elixir/burrito

Reply View 2 replies

Alupis 10 hours ago

This is very neat, thanks for the link!
Digging into it, you can get "universal" BEAM tarballs from here[1]. It links against muslibc and appears to bring it's own openssl. Very cool.
[1] https://beammachine.cloud/

Reply View | 0 replies
harrisi 11 hours ago

Burrito works very well in my experience. I've used it for distributing an implementation of breakout in Elixir with OpenGL and Metal rendering backends as a binary. Pretty neat!

Reply View | 0 replies

lpil 6 hours ago

> The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball.

This isn't true, one can statically compile the BEAM for Linux exactly the same as the JVM. Here's an example: https://github.com/yoshi-monster/static_erlang/

Reply View 0 replies

hamandcheese 12 hours ago

Perhaps you should give Nix a try :)

Reply View 4 replies

Alupis 12 hours ago

Correct me if I'm wrong, but you'd still have to compile it from source on nix, no?
On my relatively powerful workstation, Erlang/BEAM takes about 7 minutes to compile.
We're working around this currently by having a fat devcontainer image, pre-built with Erlang inside (from source) by our CI. It chews through CI minutes unavoidably due to how docker layer caching works.
It would be awesome to just download and unpack a tarball, regardless of which distro you're using.

Reply View | 1 reply
- Cyph0n 11 hours ago
  
  Nix is centered around the local Nix store and binary caching.
  As long as the specific version of Erlang you’re using is present in either your Nix store or the global cache for your OS and arch (at cache.nixos.org), you should not need to compile anything.
  And if you rely on custom builds, you can just setup your own binary cache. This is similar to remote caching in Bazel.
  Some more details on Nix caching here: https://zero-to-nix.com/concepts/caching/
  
  Reply View | 0 replies
IshKebab 7 hours ago

Nix is enormously complicated, kind of unstable and not well documented.
I get that if you've gone through the pain of learning it you get a system with some very nice properties. But casually suggesting "maybe try nix" is a bit like telling someone who wants to listen to Mozart "maybe try playing a piano".

Reply View | 1 reply
- 331c8c71 3 hours ago
  
  How is it unstable? It's one of the most reliable pieces of software I have used honestly.
  In any case 'nix-shell -p erlang|elixir' does not seem too complicated to me.
  
  Reply View | 0 replies