To say that Lars (a.k.a @lawik) is only, as he describes himself, an “Elixir consultant with too much enthusiasm” will be an understatement. The guy is all over the place, writing software, helping businesses move forward, writing inspiring stories about the future of the BEAM, and co-hosting an Elixir podcast. That is how I first got to know Lars.
Based in Sweden, Lars started his programming journey by building websites with Notepad, then learning PHP and eventually taking his hobby pro through contract work, a failed startup, a couple of product teams and onward into independent consulting. He lives along the west coast of Sweden - a little way out of the city, where he attempts to grow vegetables with his wife and baby. The baby is terrible at growing vegetables.
In 2016 Lars discovered Erlang/Elixir, and this changed his view on developing software.
What brought you to Elixir?
Lars: At first, it was a bit of hype. I had a colleague who was quite a good talker and he went on at length about the legendary resilience of Erlang and hot updates for buried telephone switches. He spoke very well of Ecto changesets and was generally, very positive about Elixir. I ended up looking at talks about Phoenix. This was when Channels was the new hotness and just before Presence took the keynote stage. Looking at what the community was putting out made me give Elixir a try. When I went into business for myself, I was expecting to do a lot of Python, but I intended to try and get into Elixir.
I enjoy toying around with Raspberry Pi, so it was just a matter of time before I started playing with Nerves. I wanted to use the Inky eInk display with Nerves but the library was only available for Python. So, I decided to make a pure Elixir reimplementation. It proved to be a rabbit hole, but the Nerves community was very welcoming and helpful, and I was sold on Elixir for good. Love that crew!
I feel like I’ve written at least four blog posts about why I remain interested in and excited by Elixir and the BEAM. I like Python. I understand why people like Node.js but I can’t quite get excited about it. Either you go higher level on top of good abstractions, as the BEAM has, or you go lower level for unconstrained performance and flexibility.
Elixir and Erlang differ significantly from other mainstream programming languages. What did you find most challenging when starting with the stack?
Lars: Immutability and the functional programming paradigm. Much of my early code did nothing or only did things by accident because I expected that the Map functions would mutate the map, not return a new one. Grasping map, reduce and all of their derivatives in the Enum module took me a bit. It was an adaptation process.
I guess it has also taken a while to disentangle use, require, import and alias. I still wouldn’t take bets on my understanding of require ;)
I’ve found the community incredibly welcoming at every step. I’ll call out Emilio Nyaray for helping me with some major refactoring and absorbing idiomatic Elixir. I hope everyone has such a good reception and it feels like the general feel of the community is very positive.
Tell us a bit about your most recent project. Why did you choose Elixir for it?
I used Plug and some code I found that the Nerves people had put together. The state is managed by a GenServer which keeps track of the connections as they come in, asking for the ”image”. It would add them to the list, render a new frame with some text on it, and send it to everyone connected. That would have been incredibly finicky in most runtimes. In my case, the biggest challenge was hitting the front page of Hacker News, where my Nginx config became a bottleneck for concurrent connections. I might have also needed to tweak my Plug a bit. It all maxed out at 450 or so concurrent connections, and I think it should be able to do way more.
I am about to add some upgrades to the Beambloggers Webring soon that follow the same vein. I don’t like running a database if I don’t need one. So the MJPEG thing is just in-memory data and a temporary state. I restart it, the connections are gone, and start building up again. Similarly, I want Beambloggers to bring in some fresh information about the different blogs. So I’ll have it run a GenServer that pulls in RSS feeds and parses out some recent items that I can link to. In-memory, background work.
Such use cases are something I’d hesitate to do in Python, for example. If I build something stateful in Python, I feel like it is bound to leak somewhere. Elixir and Erlang have abstractions that allow me to do such things with confidence.
You also do Elixir consulting. What kinds of applications do your clients choose the BEAM for, as opposed to other tech stacks?
Lars: Distributed applications that run indefinitely. Those line up with the absolute majority of work I’ve ever done. Servers, services, and web applications. If I were building large amounts of CLI tooling, I wouldn’t pick it. If I needed native desktop bindings, I wouldn’t pick it. But generally, I’m in the web application world.
As the cultural successor to Ruby on Rails, I am seeing Phoenix being used all over the place and quite popular with startups. I have seen a lot of companies picking up Elixir without necessarily knowing much about OTP. I think this is fine, and mostly speaks to the maturity of Phoenix and Ecto that people don’t need to.
In the era of Kubernetes and Microservices, where do you see monolithic BEAM applications fit into the picture?
Lars: It is interesting. The way Erlang structures things in multiple applications on a node as part of a cluster brings in some infrastructure concerns. I think some people worry that this unconventional approach is a problem when working in a polyglot environment, for example. I don’t think so. Lots of people put the BEAM in their containers and ship it out to the Kubernetes cluster in the same way as every other stack. Microservices tend to be about the contracts you expose, not the internals of how the application runs. Therefore, the fact you run a BEAM application or even a cluster of BEAM applications as one service is perfectly fine.
Where I believe much of the power of BEAM is though, is if you don’t rely on microservices and a polyglot-heavy environment. You might then be able to cut off a lot of dead weight. Or at least, manage the complexity using tools you know, rather than write YAML until it goes away. Some of the tools are there by design; others are perhaps, what we should be building in the future. I’ve gotten into it to some extent in my blog post The BEAM marches forward.
For an in-between path, I would take a look at Nomad which seems to be a slightly lighter Kubernetes competitor that can run things without containers. I think it suits the BEAM very well, as Elixir releases handle many of the perks of containerization. I haven’t tried it but if you do, let me know. I am curious about how Nomad differs from Kubernetes.
As someone listening to podcasts for over 15 years, I can’t help but ask. How does one get the courage to host a podcast?
Lars: I don’t think I’m particularly brave. You should see how uncomfortable I am on ladders.
I think I picked up a habit of pressing through discomfort partly in my teens and partly running a startup with a mentor of mine. When I was around 14, my dad passed away, essentially a heart attack out of the blue. That experience totally shifted my threshold for pain or discomfort and deeply changed how I approached life. That change in attitude was probably part of why I was keen to do the startup. And the startup led to everything else. Turns out that running a business when I barely knew what I was doing as a technical lead was a constant exercise in being okay with discomfort.
I don’t recommend overworking. I don’t recommend burning yourself out on a startup. Yet, the discomfort is part of the learning sometimes. If you spend a lot of time outside your comfort zone, you are likely to learn more. Being aware that you are choosing discomfort and staying with it is powerful.
Oh, a podcast? Well, you get asked on as a guest and enjoy it. And then, when the OG host goes off to start a new one, you get contacted as one of the potential new hosts. And since you try not to worry too much and are willing to tackle discomfort, you fret about it for a bit, ask too many questions, and then give it a shot.
What would you like to share to people new to Erlang and Elixir?
Lars: It might feel daunting at first. Don’t feel pressure to understand the BEAM, Erlang, OTP, and all of that good stuff right away. If you are an inexperienced developer, any language can seem imposing. We all end up being beginners when we move over to a new ecosystem. I think we will all be happier if we concede that we will not master everything and will only learn a portion of it. What one should focus on instead is building software well.