Elixir v1.20: Now a gradually typed language

Post by bbkane » Thu, Jun 04, 2026, 12:00 PM UTC

neya wrote: post #307

nesarkvechnep wrote: post #301

Earlier quoted context omitted.

Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now. > Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as…

Post by klibertp » Thu, Jun 04, 2026, 12:13 PM UTC

sevenzero wrote: post #239

klibertp wrote: post #151

Earlier quoted context omitted.

> Elixir is having to handle (possibly) hundreds of thousands of processes OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something? No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens…

I learned it for almost a full year by trying to build a live chat app. I went through Elixir in Action and the official guides and yet those questions were never really answered. I never said I want hundreds of thousands of processes, but thats definitely a thing you need to account for. Errors are often simply swallowed.

    - functions can return {:ok, value} or {:error, error}
    - functions can raise errors (similar to exceptions) that can be caught
    - processes can be monitored from the outside, you get notified when they die
    - processes can be linked and exits can be trapped, also notifying you on failure
    - supervisors can handle process deaths in a configurable manner
    - higher-level behaviours often expose their own error handling callbacks

Post by Kaliboy » Thu, Jun 04, 2026, 12:19 PM UTC

bbkane wrote: post #311

neya wrote: post #307

Earlier quoted context omitted.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now. > Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as…

I haven't used Elixer but tt's generally a good idea for the UI to have a different data model than the database (even if it means you initially type almost the same thing twice and have to write a tedious translation layer). This lets you evolve each part independently and use the "native" types frontend vs backend, which happens surprisingly frequently as the app grows

Post by Kaliboy » Thu, Jun 04, 2026, 12:26 PM UTC

yeetosaurusrex wrote: post #213

veqq wrote: post #207

Earlier quoted context omitted.

If you're only willing to use languages with the same features, what's the point? Learning how a different paradigm manages without types can be more insightful.

Yeah I agree learning new paradigms can give you new insights. There's also a balance between learning new languages for fun and for the insights they give, and wanting to ship. As an example: Prolog was mind-bending for me when I tried it and I had a lot of fun with it, but I can't imagine using it to build a product (I'm sure other people have though). Perhaps my first comment sounded more critical than intended. I…

Post by sa1 » Thu, Jun 04, 2026, 12:43 PM UTC