Recent publications:

Self-Hosting: Mattermost (video)
GleSYS sponsored another video on self-hosting. I really like that there are companies willing to support things like this. Slack is getting a lot from network effects and Teams gets the Enterprise by default right now but if you want to walk another path Mattermost seems like a splendid option. Surprisingly featureful.

Opportunities:

Boardclic
(EU only, Stockholm-based, office or remote)
A new company to me. Getting to know them and their work has been very interesting. They build a product that helps company boards and leadership evaluate themselves/their work. If you've ever been in charge you would know that getting transparent communication and measures of actual effectiveness is really hard. That's what the Boardclic product does. Unusually the leadership of the company is majority women.
Small technical team that gets to build for quality. Looking for one senior Elixir dev and potentially a junior-to-mid dev as well. Especially if you are a woman looking to get in to Elixir, I urge you to apply, they are very willing to make that happen. More info over here.

West Arete
(US only, fully remote)
The agency building custom software for higher education
They offer a sustainable and steady workplace and aim to give you the best years of your working life. Currently looking for a Rails dev and potentially some DevOps.
Much more detail on the site.

The promise of FireFly

DockYard is reviving the Lumen project under the name FireFly. I don't think they'd say it was ever dead but as someone who was involved in writing the news on the Lumen site. It was certainly on break. The main dev, bitwalker, was swamped at work and couldn't quite find the time. At least that's what I gathered. Brian Cardarella of DockYard came back into active duty and revived the initiative, along with launching a bunch of things you might have heard of recently. The Beacon CMS and LiveView Native for example.

With DockYard funding development I expect it to pick up pace again. And it is quite far along. With Lumen you could already compile Erlang to static x86 binaries via the LLVM toolchain. Why x86 and not the promised WASM? Let's get into it a bit.

Lumen development was funded by DockYard to attempt to run Elixir in the browser. An expansion on the thread LiveView was already pulling. As CEO of DockYard Brian Cardarella has already spoken significantly about the cost of JS-frontend development where they often double the cost of building something for a client. This combines with the common frustrations with unreliable JS toolchains and the churning ecosystem. Enter WebAssembly, or WASM.

I believe people have compiled the BEAM virtual machine that Erlang and Elixir share to WebAssembly but then you are shipping a ton of code. The BEAM VM is not suitable for web frontends. Rather than try to make this awkward fit work I think they took the thorough approach. A new compiler and toolchain to take Erlang intermediate representations (which both Erlang and Elixir compilers produce) and work it into something you can throw into the LLVM compiler toolchain.

Building this compiler requires making some choices. Most important on the chopping block was hot code updates. Removing that facility from the compiler compared to the BEAM allows dead code elimination and a ton of optimizations like that. This means that we don't have to ship the entirety of Erlang and OTP or the Elixir runtime with  our code. FireFly can make a much smaller artifact. Rather than compiling to bytecode and running on a VM everything will be compiled all the way down to whatever our target is, x86, WASM and potentially more in the future.

Essentially I think FireFly provides both a frontend (Erlang Core goes in) and a backend (WASM or x86 goes out) as there are a lot of specifics about how things need to work to match the BEAM. I'm not compiler-competent so don't quote me on that.

Then there has been a ton of work with the WebAssembly working group to ensure that it isn't all about OOP-style languages and to enable the kind of power FireFly needs to match the BEAM runtime with regards to cheap processes and scheduling. To give you the BEAM experience in WASM.

WASM and WASI is not just for the web. Making it work for these targets will enable low-power embedded devices (ESPs and stuff), edge workers that use WASI for sandboxing, sandboxable Erlang/Elixir stuff overall. And finally, in the browser. The x86 output also spells a potential boon for developing CLI tools and similar in Elixir that earlier would need something like the Burrito project to efficiently ship a binary.

In the end it is a separate compiler and a re-implementation of the BEAM and OTP. It is a significant undertaking and I think it has extraordinary potential for moving this fantastic ecosystem into new possible usages.

Where do you want to use WASM? Do you see any point in FireFly? I clearly do but let me know what you think at lars@underjord.io or on Twitter where I'm @lawik.

Thank you for taking the time to read this. I appreciate it.

- Lars Wikman