-Seeing that the Graalvm offers support for many programming languages and has a guide on adding your own langauge. I’m thinking that it could open doors with respect to extending Elixir functionality by using tooling provided from another ecosystem.
-Anyone familiar with the graalvm and their technologies feel that there’s anything their ecosystem can provide us with (I read it supports already ruby/js/python/lua). Do you think Elixir can leverage using the Graalvm in any way for things that we might not use Elixir for exclusively like cli/desktop tools/big data etc (like maybe if I’d want to have a desktop tool developed in Elixir, but my use case prefers it to have a faster startup time that isn’t always an option with beam)?
I don’t know if it’s possible to even do this, but I am looking forward to yours ideas/opinions on the subject.
It is probably an interesting project but I’d not bet my production budget on it for now. The more targets you add the more problems you have… and if you need that sort of performance why not write the code in an already supported language.
Good point, and i do certainly agree on using the better tool for the job at hand. It just seems to me especially with the emergence of Nx (already able to use pluggable compilers from other languages) that Elixir wants to broaden its horizon from being a pure web dev shop and maybe use Graalvm for offline tooling or something.
Note that a lot (most?) of the power of Elixir lies in the pre-emptive scheduling of BEAM. GraalVM doesn’t have green threads / coroutines, just relying on OS threads. This means that you would have to practically reimplement BEAM on the JVM/GraalVM to get the same kind of guarantees that we have, or opt for something like Akka. There is some prior art (Erjang) for reimplementing but it’s not a simple task.
I’m with you on this. I see what you’re getting at. I’m not disregarding the beam and its benefits, I’m just looking at the perspective of how we could benefit from their ecosystem in places you wouldn’t use elixir
One thing to keep in mind is that (last I checked) GraalVM is very memory-hungry. Strap a language on top which uses persistent data structures, and the result will eat memory quickly. Some savings will probably be found because separate GC heaps aren’t required (so no redundant copies), but I cannot guess how that will affect a typical application.
At least within the domain I work – backend systems – memory is by far the limiting factor, not CPU.
I’m unsure how much startup time reduction something like GraalVM would provide; it’s a big deal in the Ruby space because you can ahead-of-time compile Ruby files, which does reduce startup time. The BEAM already compiles to its own bytecode.
BEAM-on-Graal would have some of the same problems as Ruby-on-Graal, especially around native functions. TruffleRuby pulled this off by writing a C interpreter to handle running native extensions. Nowadays, you’d probably ALSO need a Rust interpreter
there’s a lot of things implemented in C as part of the BEAM (processes, parts of ETS, networking, etc) that would need to be completely rewritten (or interpreted, see above) into Java. truffle-erlang pulls in Akka to do some of that.
To add to that, based on what @KronicDeth shared in this ElixirMix podcast on Lumen (I hope I’m not misreferencing the source) when they initially tried to get a BEAM implementation in web assembly one of the biggest performance issues was the non-existing support for multiple call stacks and immutability, as the standard was mostly evolving at that point by parties not interested in functional programming (and so the Lumen team decided that they should get involved with the committee). I’m not actually familiar with GraalVM, but I would not think it improbable that an OO-oriented VM would not have good support for what Elixir needs to make it more than a toy implementation.