I was reading through the Rust website and I noticed they had a section called “Build it in Rust”, which calls out specific “target domains” where Rust shines:
command line apps
WebAssembly libraries
network services
programs on low-level/embedded devices
Yes, I understand this list came out in 2018, and people are using Rust to build many things outside these domains. But that section gave me the impression that “Rust is the best choice for command-line apps.” If I’m new to programming and I want to build command-line apps, I’d probably choose to learn Rust.
My question/thought exercise is: which domains would go in the “Build it in Elixir” section on elixir-lang.org? In other words, if I knew every modern programming language equally well, which types of projects would I choose Elixir for?
Applications that does networking, any kind, and require high availability and scalability while not requiring ultra-high performance. So web servers, telecommunication, purchases management, banking, distributed network management, multimedia streaming.
Resilient apps that don’t crash. Apps that stay responsive under heavy load. Those are afterthoughts in most other languages, but they’re core to the original design decisions of BEAM.
General web applications, healthcare, telecom + messaging, gambling, managing a fleet of embedded devices, anything that needs soft realtime information updates (analytics, cars/planes moving on a map, collaborative document editing).
Thanks for the replies! I’d agree that web servers and are a great use case. I wish the story around deploying these servers to your own infrastructure (i.e. not Gigalixir, Render, Heroku) was a bit better, but I’m sure people are working on that.
Communication tools and analytics dashboards are good shouts, too.
From what I’ve read (and I could be wrong), managed solutions and container-based deployments can handicap the BEAM, plus they add complexity. I’d like to see more resources around setting up one (or several) Elixir apps on a VPS with as little overhead as possible. Maybe some daemon service to keep it running and some automation to minimize manual tinkering on your server, but that’s it.
I found this deployment guide from Distillery, but I’d like to use Elixir releases instead (I’m aware the guy who built Distillery also helped build Elixir releases).
I’m also not very experienced with DevOps or deploying apps to Linux servers, so maybe include some best practices for secrets management on small projects, setting up a simple Git deployment hook to build your release and switch out the running application on the server, and other minor things like that.
Maybe these resources already exist somewhere and I just can’t find them or they looked too complicated or inappropriate on first glance. Maybe my needs and desire to learn this stuff are outside the scope of Elixir’s responsibilities. But when I initially deployed my first Phoenix app, I couldn’t find much to meet my needs so I settled for a managed solution.
I used to use edeliver with distillery to deploy Elixir applications to AWS EC2 boxes. Unfortunately I’m not working with Elixir anymore, but I was using this scheme until one year ago and it worked very well, it was pretty simple.
This isn’t the case. It can actually reduce complexity because you can utilize the same tools and infrastructure you are using for other deployments. So if you already have systems deployed using containers it doesn’t make sense to add complexity by adding another separate deployment solution simply for OTP Releases.
Obviously this doesn’t mean it is the right solution, not everyone has existing infra, other languages to deploy or experience with containers. I’m just speaking to the idea that it adds complexity simply by being managed or contained-based.
I was speaking from my personal perspective: I want to deploy 1 (or more) Elixir apps on a new VPS for a web app, maybe connect it to an existing database, and that’s it. I would fall squarely into:
Mix releases are what’s what I’ve been using on Render and I want to use on my own VPS (see my earlier comments). Yet I’m still looking for good answers/best practices to questions about Elixir-specific DevOps, such as:
how do you update your old release with a new one?
how do you handle environment variables?
I get this is out of scope for Elixir. But I don’t want to assume that new developers learning about Elixir are DevOps experts. Maybe they can start with a managed solution (like I did with Render), but is it possible to create a good path which teaches those people about how a self-managed solution specifically for Elixir might work? I think that would be really valuable.
I suggest you read the mix release documentation carefully. I deploy on a bare VPS with nothing other than what I learn from there. Since you control the VPS, I suggest you install everything you need on the VPS, then do the mix release from there. Then just hook up the release with whatever init system you like. If you use systemd, you want to write a simple unit file. something like:
Back when I first deployed my application, I remember reading through that documentation and trying for several days to get a forked example app working on an AWS EC2 instance with systemd. Maybe I was messing up something easy but I couldn’t figure it out. Eventually I ran out of time or patience and used a hosted version. For someone new to DevOps, I think it was too much information at the time, and I think other people may feel the same way. I’ll definitely reference the documentation in the future once I figure the other server stuff out.
I’m glad you found something that works for you, though!
to be honest with you I don’t use systemd, at least not directly. It is a very powerful tool with a million options and can be overwhelming. I use this:
Which is much simpler. Debian has a package for it. It is loaded by systemd so you can load your own services with it. It is not main stream and you still have to learn how to hook your service up. It has a much smaller scope though; anyone with basic unix sysadmin knowledge can figure it out in one hour.
Funnily enough, I started doing some research this week and came to the same conclusion about systemd (plus I’ve heard some nasty things about it). I decided to use Void Linux for my VPS…which includes Runit by default! I’m going to start playing around with the VPS this weekend, so maybe I’ll make some progress. If I figure out something that works for me I’ll definitely post about it.
I am working on the example application and blogpost describing how to use Elixir releases with systemd in more integrated way. runit is nice, but sometimes, in more advanced scenarios, it can be a little bit more dedious to configure in a way that will make it readable (for example private /tmp or stuff like that, which is quite easy with systemd). However I like runit as well, it is quite decent and interesting solution.
In addition to what the others have said, Elixir is generally extremely suitable for massively parallel workflows. Amazing libraries like flow and broadway help you create data ingestion / processing / storage pipelines in an almost brain-dead easy manner.
I did the same workflows in Rust several times and even though the performance there is absolutely out of this world I still prefer Elixir because of the fault tolerance and the programmer ergonomy (i.e. less coding lines, and the code is much more readable).
So in general, ETL workflows are a very natural fit for Elixir. And anything and everything that needs to be parallel and does not transparently map to using OS threads. Which is… a lot of projects.
