My hunt for Elixir CTOs to talk to has concluded for now. If you are one and want to know what I'm conspiring to do, send me an email and I'll add you to the list and notify you when things happen. Preliminary results are positive. I wanted to talk to at least 10 people about the idea and I have scheduled 14 calls. 5 or 6 are done and everything so far points to doing the thing.

Thanks everyone who helped make these conversations happen. They've been good fun and I've felt the support.

Recently published

Alex McLain talks Nerves (podcast)
This particular Alex has been a delightful supporter of my efforts at various points. From sending me a keybow kit when they were out of stock as we had interviewed his buddy in the Nerves Keyboard project (currently paused).

More recently he helped me get somewhere with ordering speakers for the office. You'll find out why he had opinions on that if you listen to his backstory in this podcast episode.

Anyway, good conversation with a very friendly Nerves-person.

What should I learn as a Programmer? (video)
Another short one. Trying to answer an incredibly common and reasonable question that is completely hopeless to address.

Share it around if you enjoy it :)

Elixir job opportunities

Senior developer, Erlang Solutions
(Nordic countries only)

I don't have a proper write-up on the company yet so this is the early announcement.

Erlang Solutions are well-known in the community and ecosystem. They arrange many of our conferences through CodeSync.

They are hiring consultants to work with their clients, remote but for the Stockholm branch. 3-5 years of Elixir or Erlang is the recommended experience level. You can indicate your interest here and I'll reach out :)

Requires occasional trips to Stockholm, Sweden.

Local maxima

Brooklyn Zelenka is a great speaker. She pushed for burning your laurels in her Code BEAM keynote this year. The opposite of resting on them.

I don't trust that no-trust computing is the path forward and I'm firmly skeptical of the entire Web3 space that hangs off of it like a parasite. What I'm optimistic about is the kind of work that Brooklyn, Martin Kleppmann and a slew of others are doing in that adjacent space. I think that can give new possibilities. I think it is also getting tainted with the crimes of blockchains and I can only hope we get more benefit than what it cost in the end. The foundational computer science going on there is incredibly interesting though.

In the talk Brooklyn tells us that what got us here might not take us to where we want to go. She explains local maxima. The BEAM is fantastic but for her ambitions more is needed. I want to press on a related topic. Pragmatism will only take us so far.

There is a strong pragmatic streak in Elixir that I really like. People have shit to get done and they often choose the path that is well-trodden, established and keep things simple. This is good and reasonable, especially for businesses. We all draw the specific lines differently but for many this means they default to Postgres. Most people don't build particularly stateful applications, they simply rely on the database. Most apps are treated as a traditional n-tier app. Only some bother with clustering. I typically do clustering. I love having it (and that's the best part about Fly.io).

Erlang and OTP give us an incredibly powerful platform capable of building absolutely mind-boggling applications that are wildly capable. In the name of pragmatism we leave most of the really unique stuff on the cutting-room floor. With some hosting providers you can't get into the runtime in production in a practical way. We don't generally consider hot code updates an option with Elixir. The enormous space of capability carved out by Erlang is mostly left unexplored. Elixir and Phoenix carve out this safe middle of the road.

That's pragmatism. Use the best parts, keep things simple. Bang for the buck.

This is not how we discover new things or really push the current ones further. It is conservative, not progressive and in a technical setting it certainly has its place.

Chris McCord tried to do LiveView style things in Ruby and it was not very well suited to that. He pushed that runtime to failure searching for .. something. LiveView is an extreme. It is pushing the actor model as close to the client as possible without tipping over and spilling state management over into the client. It could have been a dead end. I find it very compelling.

Nx does not make traditional sense for the BEAM. Seems to work pretty well though. Livebook was not on any radar and is now a uniquely powerful tool.

Push. What can we make this runtime do. What parts are we not exploring?

I can't push these concepts hard with my clients. That kind of experimentation would be unethical for building their line-of-business software. However, nothing stops me in my own projects. I say build things that you consider art projects. They are not for fulfilling a purpose with the most efficiency. They are intended to express, explore and extend.

I have an art project on my mind and in my laptop. I hope to share more about that sometime soon and invite everyone to collaborate in exploring what we can make our BEAM do. How far is too far with actors? How hard is it really to do hot code updates? Can you crowd-source your nines?

What do you want to see if we can make possible?

Push the boundaries of your communication if you like at lars@underjord.io, on Twitter via @lawik or apparently on the fed where I'm @lawik@fosstodon.org.

Thank you for your attention. I appreciate it.