Switching to Elixir

I have no trouble understanding the concepts, its the nomenclature that is different. It is the same with Haskell or other niche languages - once you are familiar with the terminology then you start to feel comfortable.

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.

Why do you think riak was well ahead of its time? (actual question, I'm not arguing)

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 was pretty bad at ops. Leaving and joining nodes took ages and god forbid you tried to use any of the added features like solr search. If you settled on a very small subset of all features it worked nicely... it just wasn't very useful if anything went wrong due to app or user error.

I was gonna say the actor model stems from state machines I believe. It's a nice way to manage state and communication. It reminds me of supervisors and processes in general but not program language specific.

I believe José deserves a lot of credit. For example, the Elixir Conference looks well-produced. No doubt there is a large team behind that, but it is obvious his influence guides that process. I'm particularly thinking of the LiveNative talk where the founder of the company talks about his own vision for extending LiveView to mobile and desktop. He mentions several times when José has interacted with him to help guide the project to stay inline with Elixir's overall goals. Of course, there is also the hints of frustration of a commercial business having to wait for community consensus. But that kind of direct involvement in the community is extremely encouraging.

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.

I switched jobs and working as an elixir dev now. I love elixir don't get me wrong, but some of the documentation especially some of the more advanced features in ecto are very confusing.

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.

Elixir is actually the easiest language to read (for me), once I knew it. You can make it difficult to follow if you want to, but when people are using it to pass around plain old data structures, it's very legible. Speaking only for myself. YMMV.

an instance of simple vs easy

Elixir is definitely a better Nodejs... that JS developers don't know about.

The whole reason Nodejs exists is because programmers eternally re-invent the wheel instead of accepting that there are already some pretty good wheels that they probably have no chance of matching.

> 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

I find LiveView either straightforward or a bit complicated, compared to other solutions, depending on the exact use cases. It's not necessarily easy initially to grow you own way to properly handle some scenarios, and some people can find the mental switch not that easy (but in general, it has been very useful to me!).

If you want a language and VM that makes it easy to run jobs on different compute then boy do I have great news for you ;)

Running heterogenous loads on an elixir cluster is almost trivial. Certainly trivial compared to other languages. No external deps required.

You're creating a really difficult distributed systems problem then. What happens if the async request gets swallowed? Are you coordinating telemetry and tracing across these compute units?

Not all of us can afford elaborate ops teams

> I want background work to live on different compute capacity than http requests

The magic of Elixir/Erlang is that all of this logic can live in one codebase and you can choose when deploying your distributed cluster of Elixir/Erlang nodes which nodes run which tasks. The nodes are all aware of each other and when something happens that requires execution of that task it happens on the correct nodes because they're the only ones running those processes. Automagically.

You can actually have "background jobs" in very different ways in Elixir.

> I want background work to live on different compute capacity than http requests, both because they have very different resources usage

In Elixir, because of the way the BEAM works (the unit of parallelism is much cheaper and consume a low amount of memory), "incoming http requests" and related "workers" are not as expensive (a lot less actually) compared to other stacks (for instance Ruby and Python), where it is quite critical to release "http workers" and not hold the connection (which is what lead to the creation of background job tools like Resque, DelayedJob, Sidekiq, Celery...).

This means that you can actually hold incoming HTTP connections a lot longer without troubles.

A consequence of this is that implementing "reverse proxies", or anything calling third party servers _right in the middle_ of your own HTTP call, is usually perfectly acceptable (something I've done more than a couple of times, the latest one powering the reverse proxy behind https://transport.data.gouv.fr - code available at https://github.com/etalab/transport-site/tree/master/apps/un...).

As a consequence, what would be a bad pattern in Python or Ruby (holding the incoming HTTP connection) is not a problem with Elixir.

> because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure.

Unless you deal with immediate stuff like reverse proxying or cheap "one off async tasks" (like recording a metric), there also are solutions to have more "stateful" background works in Elixir, too.

A popular background job queue is https://github.com/sorentwo/oban (roughly similar to Sidekiq at al), which uses Postgres.

It handles retries, errors etc.

But it's not the only solution, as you have other tools dedicated to processing, such as Broadway (https://github.com/dashbitco/broadway), which handles back-pressure, fault-tolerance, batching etc natively.

You also have more simple options, such as flow (https://github.com/dashbitco/flow), gen_stage (https://github.com/elixir-lang/gen_stage), Task.async_stream (https://hexdocs.pm/elixir/1.12/Task.html#async_stream/5) etc.

It allows to use the "right tool for the job" quite easily.

It is also interesting to note there is no need to "go evented" if you need to fetch data from multiple HTTP servers: it can happen in the exact same process (even: in a background task attached to your HTTP server), as done here https://transport.data.gouv.fr/explore (if you zoom you will see vehicle moving in realtime, and ~80 data sources are being polled every 10 seconds & broadcasted to the visitors via pubsub & websockets).

there's nothing stopping you from doing this but its a real game changer for an early stage startup to need a new service and the steps to getting that out is one file and an extra line in your config.

Big time this ^, I really need static typing in hobby projects (I like C#/Typescript) but at work we use Elixir and it doesn't end up being a problem because of pattern matching. It's partially because it ends up being run-time type checking, and partially because it makes the code _read_ like a statically typed language.

Behaviours might be what you're looking for, they're the closest thing to inheritance in Elixir.

And you're absolutely right about genservers being objects :)

> A lot of gems use exceptions for control flow

Do you happen to have an example of such control flow to link to? Not that I don't believe you but I wonder if there's a difference in what is meant by "control flow" between commenters.

  begin
    do_stuff!
  rescue MyFirstLibraryError => error
    # handle first
  rescue MySecondLibraryError => error
    # handle second
  end

I know Ruby != Rails but the example wasn’t mine. It was from the paragraph I quoted from the post, which conflates the two.

It may be true in Python--I don’t use it much--but I know Ruby well. It was my primary language for 13 years, at multiple companies. I taught it to over a thousand engineers at Airbnb over the course of five years. I still disagree that it is common to use exceptions for control flow.

Maybe it’s a matter of the interpretation of the word “common.” ¯\_(ツ)_/¯

dynamic but still strongly typed