There is a real need to push Elixir outside its initial circles and it's being done a bit at the moment (I feel).

Both Chris & José are doing a lot of work for exposure outside the initial Elixir circles, and some people in the community are doing the same at their own levels.

Hiring is not that complicated actually, because a fair bit of people want to work in the language (I experience that first-hand), and a good developer will be up-to-speed quite quickly too.

But the "niche" aspect must be tamed in my opinion, and is both a risk (for the language itself) and a short-term reward (being proficient in a niche something is usually quite good).

It doesn't help you can define your ecto instructions in multiple flavors too (inline vs piping)

You can't mix inline with pipe operators without creating an additiona variable too hold the original query.

If we want to make it less niche, there's definitely good working points there. Once people understand how to hit a database from elixir it magically clicks and the other stuff is more trivial.

And agree that there are both excellent documentation, _and_ things that are kind of "assumed" and would need better "beginner" stuff (in my opinion).

Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc.

But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest.

Sadly i do not have solutions rn but if people have ideas please come offer them.

You also make a very good point about the risk and reward metric. One of the reasons I have been focusing on Elixir as opposed to other niche languages is the progress the community is making is inspiring. I recall an essay by Paul Graham where he talks about Lisp being a contributor to his success with the startup that made him wealthy. He believed that being faster to market with features due to his platform choice was decisive in that success. In that way, something like Elixir (and really, the BEAM) could be a decisive component to some startups success. Given that they are focusing on important contemporary ideas, that is possible. LiveBook for example and Nx/Axon/etc for ML may actually be a killer feature.

Of course, time will tell. I don't have a crystal ball. But I am very interested in watching it all unfold.

Stuff like LiveView though looks like magic because it is magic. There are a lot of moving parts involved in getting it working. It’s the result of work that has been going on for the past decade across multiple communities though. The ideas are mature even if there is a lot of abstraction.

Stuff like Riak was well ahead of its time. They basically had the idea of being able to create robust distributed systems much the same way you would a GenServer.

IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)

Riak the database used Riak Core, but it could be used independently of the database.

I hadn’t thought about Core in a long time, I should take another look.

Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/

I had some similar issues with rabbitmq

On the other hand, Phoenix channels were much more flexible about membership

The key characteristic is not a state machine, but that:

- first class processes send messages to each other

- messages are queued

- each process is single execution flow. If you want to reenter code, start another process and send messages to it

- process execution can be preempted

- values passed in messages are for the most part, immutable.

- first class support for “links”, where one process gets notified when another process crashes (basis for supervision trees)

The consequences of this design are:

- for the most part, you don’t need mutexs

- spin locks are cheap

- every process can be suspended indefinitely when nothing is in the message queue. This is better than an async reactor.

- processes don’t get “lost” (I am looking at you, Nodejs)

- processes can receive control messages to suspend or shutdown, restart, etc. Most other platforms have to externalize that to say, K8S and such controls are crude.

- errors don’t get “lost” (Nodejs again …)

- repl in production, can inspect the whole system live, under load

- overloaded systems degrades gracefully instead of locking up

Looks like I misread it. While the Actor model was conceived before Erlang, the Erlang actor model was developed in parallel. It isn’t a pure implementation of Actors (everything is an Actor, making it closer fo Smalltalk). Only processes are Actors. It also implies that Akka is not a true Actor model as conceived in the originao ‘73 paper.

This goes into greater detail on the history: https://www.labouseur.com/courses/erlang/history-of-erlang-a...

In any case, there are not many contemporary systems that uses these ideas.

However, I just consider some things in the world outside of Elixir/Erlang/BEAM to be a bit more common. For example, using Docker with Kubernetes/ECS/etc as a deployment story. Or connecting micro-services using REST/gRPC/GraphQL. Or using queue systems like SQS or Kafka (to be fair, literally yesterday an ElixirConf talk about using Kafka with Elixir was posted). The advantage of BEAM is that you can avoid that stuff in some cases because it is built in to the platform - but that is a double edged sword since now you aren't doing those things.

Even if I have used Akka for Actors in Scala/Java/Kotlin, something about the BEAM based languages still feels like I am stepping onto the Galapagos Islands and seeing a ecosystem that has been evolving in its own isolation for decades. Sure, there are birds, but they just don't look like any birds I've seen before.

On the point of hard to hire and hard to find tutorials. It is true. It is way harder to find for example someone that done what you wanna do in elixir vs javascript. When it comes to libaries it isnt so big problem. There are lots of libraries and so far I havent really encountered any problems. Only thing would be if you interact with an API they might provide a client library for javascript and python (but less common for Go) but not elixir. But honestly it is usually not so hard to use an API with just a http-client.

I am writing Nodejs because I have to, not because I want to. Having used it now, I will never ever start a new project with it.

Nodejs's concurrency controls, ability to scale, tools for reliability and observability are so far behind from the BEAM ecosystem. I sometimes think people think Elixir is too good to be true because they're too used to platforms not designed to be resilient.

One justification for this was that it is supposed to make it easier to reason. It made it more difficult for me to reason -- maybe single-threaded async reactor is a poor substitute for immutability.

Unhandled promise rejection is an example of a consequence of this design. That's not really a thing in Elixir by design. But in the Nodejs world, people don't even see it as a design flaw. It makes reasoning about reliability much more difficult.

It’s a valid justification because it makes it substantially easier to reason compared to mutable multithreaded languages/runtimes such as C(++), Java and C#.

Eg a semaphore in JS doesn’t exist. It’s just a boolean. Interlocked Increment doesn’t exist. It’s just someVar++. And so on, it’s very nice.

That doesn’t mean that there aren’t other setups (such as immutable data with message passing) that are even easier to reason about. Every new tech compares itself to the current mainstream.

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.

I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be?

There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward".

This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward.

1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS...

2. https://www.youtube.com/watch?v=7yZwxsG7tVs

Where this gets messy is mixing LiveView and client side JS, and I need to experiment further with this (or find people who have).

However, it is absolutely awesome for the "slightly javascript" case of a lot of UIs. Two examples, from my work:

Forms with "live" display of validation errors, using one single set of validation on the backend, rather than the duplicated frontend and backend having to match. It's completely trivial to implement with LiveView.

Status displays - We built some development hardware based on a Xilinx Zynq FPGA (FPGA + ARM running Linux) and used LiveView to report a lot of the hardware state - primarily the status of all of the registers. A little fiddling with HTML+CSS for the register widget, but then everything else could not have been easier - render your widget once per register, and rerun that whole thing any time pubsub provides an updated register value.

When someone says that liveview is straightforward, they aren't comparing it to stable backend languages that almost exclusively run on one operating system and one architecture and they certainly aren't referring to the many hacks every JS library incorporates to make the library more useful.

People say this every time Elixir comes up, but, I would like to hear evidence of this being true.

I worked at a startup for a couple of years and had never used Elixir. The majority of the engineers who worked there, whilst I did, also hadn't. We had a few who were experts in the language and a couple who had well-known open source packages.

Genuinely from my experience, each of the things in your list are simply not true.

> But I get concerned looking at the magic of LiveView (and LiveBook).

What magic? Again, genuinely questioning this.

https://pragprog.com/titles/liveview/programming-phoenix-liv...

More interesting to me is his physical theories about computation. For example, he hints often at his idea of the blackhole as the most powerful computer. As we think about the distribution of computational systems, I wonder how often we consider the density of computational systems.

In fact it's kind of crazy how much of it I understand given I haven't tried. The community is just all about simple tools and understanding them.

I think it is a bit confusing actually, since they differentiate between Erlang (the language), ERTS (Erlang Runtime System) and the BEAM. It isn't clear to me what "Open Source Erlang" refers to with respect to those distinctions, or what the licenses are for each of them.

1. https://www.erlang.org/faq/implementations