[japhib]

Elixir is the closest thing to OCaml that has a chance at semi-mainstream usage IMO.

It has basically all of the stuff about functional programming that makes it easier to reason about your code & get work done - immutability, pattern matching, actors, etc. But without monads or a complicated type system that would give it a higher barrier to entry. And of course it's built on top of the Erlang BEAM runtime, which has a great track record as a foundation for backend systems. It doesn't have static typing, although the type system is a lot stronger than most other dynamic languages like JS or Python, and the language devs are currently adding gradual type checking into the compiler.

[BenGosub]

I think that a better question is why F# isn't a more popular language, since it's much closer to OCaml, than Elixir and you can use the whole Dotnet ecosystem in F#, which is one of the weakest points of OCaml (no libraries).

[schonfinkel]

The answer is (most likely) Microsoft, I kid you not. I've worked with F# professionally for many years is its incredible how they are literally sitting atop a gold mine that is the output of Microsoft research and do basically nothing with it. Even though it's sold as an ecosystem, .NET revolves around C# and its related tooling.

"Type Providers" are an example of such negligence btw, it's something from the early 2010's that never got popular even though some of its ideas (Typed SQL that can generate compile-time errors) are getting traction now in other ecosystems (like Rust's SQLx).

My team used SQL Providers in a actual production system, combined with Fable (to leverage F# on the front end) and people always commented how our demos had literally 0 bugs, maybe it was too productive for our own good.

[DrewADesign]

I think it’s odd that elixir doesn’t get more love. It ticks a lot of boxes that folks here get excited about, has a great ecosystem and tooling, BEAM is great, and it’s much more syntactically familiar than erlang to my eye. I know of a couple companies aside from the perennial goto examples that built sizable saas products backed by it.

[cardanome]

The backend work I do is just super boring.

I always wanted to learn Elixir but never had a project where it could show it strengths. Good old PHP works perfectly fine.

Also corporations like their devs to be easily replaceable which is easier with more mainstream languages, so it is always hard for "newer" languages to gain traction. That said I am totally rooting for Elixir.

[lenkite]

The BEAM VM executing bytecode is slower than a compiled binary. Sure, it is great when compared to Python and other interpreted languages. Not so much when you need fast processing and raw CPU performance. It also loses out to the JVM in performance, but wins in memory consumption.

[pluralmonad]

Elixir is good at managing complexity. I love flattening hierarchy and dealing with edge cases right in function definitions using pattern matching. Every other language without it just feels crippled after getting used to the feature.

[skybrian]

What does deployment look like? Can you get a static binary easily like with Go?

[vvpan]

If it's functional (recursion vs imperative loops) most people/organizations will not use it. At this point that is just the reality.

[bsder]

I really wish people would quit pushing "functional". People equate that with "My programming is now always a recursive logic puzzle."

Talk about "immutable by default". Talk about "strong typing". Talk about "encapsulating side effects". Talk about "race free programming".

Those are the things that programmers currently care about. A lot of current Rust programmers are people who came there almost exclusively for "strong typing".

[zaphar]

Having loops is not the defining feature that separates functional from imperative. Where did this idea come from? I'm suddenly seeing it in a lot of places.

[BenGosub]

Writing OCaml and writing Elixir code is much different for me. OCaml requires more braincells, while Elixir is more flexible.

[belter]

BEAM performance model trades throughput for isolation, which hurts CPU-bound tasks, and ironically, whenever you need speed, you end up using NIFs that break BEAM safety guarantees, and reintroduce the exact fragility Elixir was supposed to avoid.

In 2025, Elixir is a beautiful system for a niche that infrastructure has already abstracted away.

[jimbokun]

> In 2025, Elixir is a beautiful system for a niche that infrastructure has already abstracted away.

Do you mean Kubernetes?

My mental model of Erlang and Elixir is programming languages where the qualities of k8s are pushed into the language itself. On the one hand this restricts you to those two languages (or other ports to BEAM), on the other hand it allows you to get the kinds of fall over, scaling, and robustness of k8s at a much more responsive and granular level.

[creata]

> whenever you need speed, you end up using NIFs that break BEAM safety guarantees, and reintroduce the exact fragility Elixir was supposed to avoid.

That's like complaining that unsafe{} breaks Rust's safety guarantees. It's true in some sense, but the breakage is in a smaller and more easily tested place.

[jlouis]

It's not isolation which hampers throughput. That's a red herring. In fact, isolation increases throughput, because it reduces synchronization. A group of isolated tasks are embarrassingly parallel by definition.

The throughput loss stems from a design which require excessive communication. But such a design will always be slow, no matter your execution model. Modern CPUs simply don't cope well if cores need to send data between them. Neither does a GPU.

[timeon]

I do not think that monads/type system are issue, but yes BEAM runtime is killer feature.

[phplovesong]

Gleam also. But i cant justify a non compiled language in many things i do.

[cultofmetatron]

gleam is compiled... to erlang bytecode

[cyberpunk]

immutability?

    Interactive Elixir (1.19.0) - press Ctrl+C to exit (type h() ENTER for help)
    iex(1)> x = 1
    1
    iex(2)> x = 2
    2
    iex(3)>

What's immutable about elixir? It's one of the things which I MISS from Erlang -- immutability.

[nitros]

This is like saying Haskell doesn't have immutability because it has the state monad, or that rust doesn't because you can shadow with let.

Data is immutable and thats much more important than whether local variables can be modified imo.

[debugnik]

Shadowing is not mutability. The former isn't affected by control flow nor does it affect closures.

[int_19h]

What you wrote is roughly equivalent to this in C:

  {
    const int x = 1;
    {
      const int x = 2;
    }
  }

which is to say, there are two different `x` in there, both immutable, one shadowing the other. You can observe this if you capture the one that is shadowed in a closure:

  iex(1)> x = 1
  1
  iex(2)> f = fn () -> x end
  #Function<43.113135111/0 in :erl_eval.expr/6>
  iex(3)> x = 2
  2
  iex(4)> f.()
  1