Switching to Elixir

I'm building a static analyzer for Solidity in F# and the data shape of Solidity AST nodes overlaps frequently enough that explicitly specifying types is necessary just to get things to compile.

I can't imagine building something like this in a dynamically typed language. The way I see it, static typing is like writing inline unit tests to save yourself many, many headaches later.

I've been using Ruby since about 2007. Every time I attempt to switch to the next "cool" thing, I ended up switching back, because Ruby is what I love and am the fastest with, and that's all that matters.

However, I've been starting to see a lot more Elixir buzz, and I love the looks and sounds of it. Looks like I'll need to start a new side project soon to give it a try.

> You'll always run into situations where the shape of data is not clear

If you're using typespecs, then I think the deficiency is with tooling. I think the language servers (like ElixirLS) were quite buggy for a while, but it's getting better at code completion and inspection. But if the type has no spec then you're in the same situation as any gradually typed language.

> looking at the magic of LiveView (and LiveBook)

What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch.

Liveview is incredibly straightforward.

Real talk. HN posts on anything OTP continue to be the same echo chamber of responses, with most readers just leaving them to it. Many people have been trying to nicely point out that "uses Elixir in some places" is not the same as "built on Elixir". ie It's exceedingly rare for any system to have a secret sauce called Elixir and none of them have sparked a race to use it. How many decades before someone points out it's a dead horse?

From my few years off-and-on, Elixir is a nice syntax on top of Erlang. Erlang is intrinsically a flow-based system. Just because you can prove something is turing complete, doesn't make Elixir/Erlang a good general language choice. The no-side effect philosophy is a dead end. You just store state somewhere else anyway, so what have you gained? The current type system is problematic, at best, and everyone knows that. Decades have passed and the same tired phrasing appears in every paper and every talk. "dynamic, scalable language built on Erlang VM, designed for building maintainable, high-concurrency apps". It's clear that this isn't special anymore and it reads as desperate for relevancy, or left to rot. Either way, Elixir/Erlang is a specialty tool like Apache Nifi or CockroachDB. Niche, at best, a sub-optimal choice at worst, for most projects.

It's oft repeated that Elixir/Erlange tooling is "established". Whenever I have used the tooling or a framework (looking at you Phoenix), it's been primitive (Observer has gotten better), poorly implemented (IDEA, VScode), or requires a large amount of memorization to "learn" it. Not the language, the tooling. It's not enough to know Elixir or Erlang. You better understand BEAM (to some extent), shell scripting (just run it in a docker on windows), some glue technologies (something to build the UI, maintain state, etc), and then you can get down to building your backend application.