I wasn’t sure where exactly to put this. On a mailinglist I would’ve just mailed it to the best ‘advisory’ related list. Move it if Q/H is not fitting.
a couple years back I started out on the purely functional operating systems path. During my years of contributions to Guix and GuixSD I started designing a different approach. Guix is mostly Guile (Scheme) based with some (fading) remains of Nix daemon code.
It took a while (longer than I initially hoped for) to gather first hand, practical expertise about these OS and their managers (they manage more than just packages). So pretty close to releasing a first demo of plant (and infotropique OS), I have started an evaluation of Nix(OS) and Guix(SD). Their implementations and so on. Let’s say that the people I work with, including myself, would like to have a final check if there’s a better suited language than Guile.
I’m not looking at just Erlang and Elixir alone, but since I’m new to both languages there’s a certain appeal in them. I’m not sure if people are familiar with these (relatively) new Operating Systems (albeit ‘functional OS’ is not a completely new research field): https://grosskurth.ca/bib/2006/dolstra-thesis.pdf.
Finances play (almost) no role, but: is the idea of implementing the relevant parts of the thesis in Elixir an impossible act and it’s just my gut feeling playing tricks on me by making Elixir look like a tempting language?
I am biased by how it is all stitched together in Guix. My work so far outside of it is stripping it down into the smallest parts possible with a future focus on a modular OS building framework (with many extras). Obviously there are times when Elixir and the BEAM are not the best tools for the job. Other than gaining experience through reading and discussions with more experienced Elixir programmers, how do you figure out if Elixir is “right” or “wrong” before you can fully grasp the ways you’d need to rewrite (or start from scratch) your application/OS without sacrificing its core ideals and functionalities?
I just have ideas and experience outside of Elixir and Erlang, so I hope these rather general questions are not too early (I will probably have a document to point to in a couple months), too open.
For the casual by-passers who might be familiar with my name: this is mostly a theoretical question - my work, no matter how the evaluation ends up, is with an emphasis on collaboration and sharing of ideas, and extending ideas.
I’m not at all familiar with Guix, so forgive me if my comment is completely naive.
I think of BEAM as nearly an OS itself. BEAM really just needs the OS to provide memory, a few threads, and do IO when asked. There’s even the Erlang on Xen project that runs a customized Erlang VM as a guest OS on the Xen hypervisor. Given that Elixir will give you the BEAM it almost seems like cheating to implement an OS with it.
As far as knowing when Elixir is “wrong” and needs a rewrite, I can only speak from an application perspective. If you have concurrent activities and want fault tolerance, it’s hard to beat Elixir (or any BEAM language to be fair). However, if you have CPU-heavy activities, you may want to write them in some other language and use Elixir to coordinate calls to them.
My first impression of Elixir and Erlang after looking a bit into existing OS for it last week already had this covered (Erlang on baremetal, boot into Elixir, …).
What I am looking at here is hard to put into a short post, so let me be very brief and say that I am not looking for a plain erlang on metal deployment. I have an exam upcoming, so in 3 days I can fill you in about what GuixSD and NixOS and how they differ from the majority of current ‘regular’ Unix-like systems (for good reasons).
It is not so much about writing an entire OS with the underlying languages (Guile, Nixlang,…), but the ability to construct the OS with tooling written in the language picked and get reproducible results.
Since Nerves seems to rely heavily on Buildroot: It is my understanding at this point, that buildroot is not sufficient (for us).
Compared to Guile, the Elixir+Erlang community is much larger. It is larger in name recognition, community, LoC in production. Large is not always good, but I’m looking at many factors including ‘social bubble around language’.
Ah, yes. To implement tooling, Elixir would be great and you are already aware of the Nerves community who have been doing some work in that direction. I’m not familiar enough with Nerves’ requirements, but it’s probably worth investigating further. I’d guess that buildroot is a default, but I would not expect it to be a hard requirement.
Since my original design for the system has changed quiet a lot after the first experiments,
I am currently looking again into the past (which happens too rarely these days), and beyond that the possibility of using other languages.
Regardless of the result I might end up returning with more questions, so far I’m just reading books, papers, etc.
The combined living documentation of Elixir and Erlang communities and community-documentation like material is already far better than the specific Scheme implementation Guile Scheme which I have been using for the last couple of years.
I realize this is an old thread. Never the less @ng0 yes, to your point, if someone put in the work, elixir would be a fantastic language to do the job that guile does in guix, and nix does in nix.
But you could also end up implementing an elixir version of hydra, a cache server, and more. It would be a large amount of work, but it would be incredible. Caveat that the whole nixpkgs library would need to be ported over or have an equivalent too. This is done differently but equally large and complex puzzle piece in guix.
But yes, it’s a great idea that I too have considered.
elixir would be a fantastic language to do the job that guile does in guix, and nix does in nix
I personally wouldn’t chose Elixir for this job (though it’s my favorite language). Elixir is not lazy, Elixir is module-oriented. Elixir has no primitive for paths, no primitive for maps with priorities. Elixir’s processes are useless for this kind of task.