I've been writing Elixir on-and-off since 2017 for personal projects and since 2024 professionally, at a big tech company.
The two experiences couldn't be more different. While I loved the great development speed for my personal projects, where I am writing more code than reading it,
joining an existing project needs the opposite, reading more code than writing it.
And I can only repeat what many people say, dynamic typing makes this so much more difficult. For most code changes, I am not 100% certain which code paths are affected without digging a lot through the code base. I've introduced bugs which would have been caught with static typing.
So in my conclusion, I'm bullish on gleam, but also on other (static) languages embracing the cooperative green-thread/actor model of concurrency like Kotlin (with JVM's virtual threads).
(On another note, I personally also dislike Phoenix LiveView and the general tendency of focusing on ambiguous concepts like Phoenix Context's and other Domain Driven Design stuff)
I worked a year or so at an Elixir shop, and this mirrors my experience. I had to navigate to call sites to understand what I was being passed and type hints were not sufficient. Dynamic typing fails larger orgs/teams/codebases.
Fun to develop and solo administer. Small teams with a well known codebase can do amazing things. I work at orgs with multiple teams and new hires who don't know the codebase yet.
There are type hints for function parameters. With some care and guards, Dialyzer can be somewhat helpful.
What actually drove me nuts was absence of guards and meaningful static analysis on return values. Even in my small but nontrivial personal codebase I had to debug mysterious data mismatches after every refactor. I ended up with a monad-like value checking before abandoning Elixir for my compiler.
Fully agree with this based on similar experiences. IME most devs hired without previous Elixir/Phoenix experience don’t end up liking the tech stack very much, even though they become productive quite quickly and don’t struggle too much with Elixir. A lot of Elixir/Phoenix fans make the mistake of thinking that everyone is going to love it as much as they do once they get up to speed.
Isn't there some kind of optional typing in Elixir?
What you're describing are the same uncertainties I've used to have writing PHP a long time ago, but since using optional types and PHPStan checker, it kind of serves as a compiler pass that raises those issues. The benefit being that I still can be lazy and not type out a program when I prototype the problem on my first pass.
>Isn't there some kind of optional typing in Elixir?
It’s in the works and recent versions of the compiler already catch some type errors at compile time, but it’s nothing remotely close to what you get from Typescript, or from any statically typed language like Go, Rust, Java, etc.
it's just an internal I/O-bound project, where BEAM concurrency makes lots of sense. Grown from an engineer's side project as it was useful and working well, not a company-wide effort to bet on Elixir
Am I the only one who never tried Elixir just because it has no strict typing?
Seems very hard for me to go back to a language with dynamic typing. Maybe I'm just wrong and I should give it a try.
It is alleviated quite a bit bz its pattern matching capabilities combined with the "let it crash" ethos.
They have a success typing system (which isn't very good) and are working on a fuller system (which isn't very mature).
If typing is the only thing keeping you out, have a look at Gleam.
Having worked with Elixir professionally for the last six years now, it is a very mature platform, very performant and offers many things that are hard in other languages right out of the box.
I see this phrase around a lot and I wish I could understand it better, having not worked with Erlang and only a teeny tiny bit with Elixir.
If I ship a feature that has a type error on some code path and it errors in production, I've now shipped a bug to my customer who was relying on that code path.
How is "let it crash" helpful to my customer who now needs to wait for the issue to be noticed, resolved, a fix deployed, etc.?
Thanks for your answer!
I already checked Gleam several times and it looks amazing. The ecosystem just doesn't feel mature enough for me yet. But I can't wait for it to grow.
There is also pattern matching and guard clauses so you can write something like:
def add(a, b) when is_integer(a) and is_integer(b), do: a + b
def add(_, _), do: :error
It’s up to personal preference and the exact context if you want a fall through case like this. Could also have it raise an error if that is preferred. Not including the fallback case will cause an error if the conditions aren’t met for values passed to the function.
Writing typespecs (+ guards) feels really outdated and a drag, especially in a language that wants you to write a lot of functions.
It reminds of the not-missed phpspec, in a worst way because at least with PHP the IDE was mostly writing it itself and you didn't need to add the function name to them (easily missed when copy/pasting).
I’d recommend it. I used to think I needed statically typed languages to write sound code, but after enough time with Elixir (10 years professionally and going) I really don’t believe that to be true… A huge portion of my change of heart is due to Elixir (and Erlang) being functional and only having a handful of types:
There are a few others but they are generally special cases of the ones above. Having so few data types tends to make it much more obvious what you’re working with and what operations are available. Additionally, because behavior is completely separate from data it’s infinitely easier to know what you can and can’t do with a given value.
Ruby being dynamic drove me insane at times, but Elixir/Erlang being dynamic has been a boon to productivity and quality of life. I recently had to write some TypeScript and was losing my mind fighting the compiler, even though I knew at runtime everything would be fine. Eventually I slathered enough “any” on to make the burning stop… But! That’s something I haven’t had to do in years, and it was 100% due to type system chicanery and not preventing a bug or making the underlying code more sound.
There are still some occasions where having some static typing would be nice— but they’re pretty rare and often only for things that are extremely critical or expensive to fix. And IMHO even in those cases, Elixir’s clarity and lack of (implicit) state generally make up for it.
Here's my take as TS dev. You just never learned to use types in the first place where there is very little ambiguity on any types anywhere because there is close to no any's used. Sounds like you guys get high and mighty on your tunnel-visioned copium—I mean I used to write JS for god's sake and thought it was okay. And I remember when I first tried TS felt annoyingly hampered by having to actually use interfaces properly.
Sure, the nature of Elixir probably makes it easier but I find little joy in dynamic whack-a-mole and mental gymnastics to infer types instead of fricking actually being able to see them immediately.
I could go commando in TS as well and switch to JS and JSDoc, leaving everything gradually typed and probably be fine but I'd feel terribly sorry for anyone else reading that code afterwards. It'd be especially silly since I can now just infer my auto-generated Postgres zod schemas with little effort. Moreover, a good type system basically eliminates typing-related bugs which you guys apparently still have.
So please, don't over-generalize just because you think you got it figured out.
I tried it for a job interview, and it was awful - because of no static typing. I spent most of my time tracking down dumb type errors, compounded by various language footguns (I can't remember exactly, but I think for example making a typo on a field name in a for loop condition is treated as "condition false" and so the for loop just doesn't do anything, no error).
It seems like the Elixir/Erlang community is aware of this, as is Ruby, but it's a rather large hole they have to dig themselves out of and I didn't feel particularly safe using the tools today.
I've heard a lot of good things about the Erlang runtime and I did really like Elixir's pipe operator, so it was unfortunate.
There's also tooling like dialyzer, and a good LSP catches a lot too. The language itself has some characteristics that catch errors too, like pattern matching and guard clauses.
With all that said, I'm still very keen for static typing. In the data world we mostly start with Python without mypy, and it's pretty hard to go back.
Type systems in this space seem to take a long time and never quite reach completeness. At least that's the experience I've taken away from occasionally glancing at Erlang's Dialyzer project every now and again which I don't think has ever reached any semblance of the maturity of something like TypeScript.
But pattern matching in Erlang does do a lot of the heavy lifting in terms of keeping the variable space limited per unit of code which tends to reduce nesting and amount of code to ingest to understand the behavior you care about at any moment.
Generally I find static typing to be overrated, even more so with elixir due to pattern matching and immutability. I think elixir’s set-theoretic types will be a nice addition and will provide some compile-time safety checks without needing to explicitly define types for everything. It remains to be seen how far they’ll take this approach.
Biggest benefit of typing in TS is just autocomplete that knows to filter down suggestions to field name of the object type before the dot. That and constants without typos. That, exhaustive maps and interface implementations are really good to not forget things that have to be done outside of the currently open file.
really you wind up making only a handful of type errors that make it into prod.
there are other things that contribute to this like pretty universal conventions on function names matching expected outputs and argument ordering.
it does suck hard when library authors fail to observe those conventions, or when llms try to pipe values into erlang functions, and yes, it WOULD be nice for the compiler to catch these but you'll usually catch those pretty quickly. you're writing tests (not for the specific reason of catching type errors), right? right?
I liked the article, but I found it a bit strange that it presented pure functions as a feature of Elixir rather than as a general good practice. Surely there's nothing particularly unique about Elixir in this regard compared to other languages?
> But honestly, I’ve always felt like this objection was overblown. I’ve got nothing against static typing; some of my best friends use statically-typed programming languages.
Elixir is a strongly typed language (as opposed to a weakly typed language like JavaScript or Perl). You cannot, for example, do `"4" - 1` in Elixir. Dynamic vs static typing is a mostly orthogonal scale, where Elixir is (mostly) dynamically typed.
There are some very sharp Computer Scientists who believe static typing is unnecessary. Joe Armstrong (co-designer of Erlang) once said: "a type system wouldn't save your system if it were to get hit by lightning, but fault tolerance would"
I've never had a system crash from a lightning strike, fault-tolerant or otherwise. I have had systems crash from null pointer errors though, and fault-tolerance did nothing to fix that except turn a crash into a crashloop.
I have the same attitude toward overly permissive type systems that I do toward the lack of memory safety in C: People sometimes say, "if you do it right then it isn't a problem," but since it objectively IS a problem in practice, I would rather use the tool that eliminates that problem entirely than deal with the clean-up when someone inevitably "does it wrong."
Seems a bit strange to posit fault tolerance as an alternative to a type system. Personally, I view type systems as a bonus to DX more than something strictly designed to prevent errors
Yes you are. First of all there isn't such a thing as "strict typing", types are either static/dynamic and/or strong/weak. I suppose you meant Elixir has no static types. It is however a strongly typed language.
And just like it usually happens, static typing enthusiasts often miss several key insights when confronting dynamically typed languages like Clojure or Elixir (which was inspired by ideas implemented in Clojure).
It's not simply "white" and "black", just like everything else in the natural world.
You have to address:
- Runtime flexibility vs. compile-time safety trade-offs — like most things, things have a price to it, nothing is free.
- Different error handling philosophies. Sometimes, designing systems that gracefully handle and recover from runtime failures makes far more resilient software.
- Expressiveness benefits. Dynamic typing often enables more concise, polymorphic code.
- Testing culture differences. Dynamic languages often foster stronger testing practices as comprehensive test suites often provide confidence comparable to and even exceeding static type checking.
- Metaprogramming power. Macros and runtime introspection enable powerful abstractions that can be difficult in statically typed languages.
- Gradual typing possibilities. There are things you can do in Clojure spec that are far more difficult to achieve even in systems like Liquid Haskell or other advanced static type systems.
The bottom line: There are only two absolutely guaranteed ways to build bug-free, resilient, maintainable software. Two. And they are not static vs. dynamic typing. Two ways. Thing is - we humans have yet to discover either of those two.
You act like OP has never experienced dynamic type programming.
They clearly said they "can't go back to" it, meaning they've experienced both, are aware of the trade-offs, and have decided they prefer static types.
> Gradual typing possibilities. There are things you can do in Clojure spec that are far more difficult to achieve even in systems like Liquid Haskell or other advanced static type systems.
That's great for clojure and python and PHP, but we're not talking about them.
Runtime flexibility is not restricted to dynamically typed languages, it just happens to be less available in some of the popular statically typed languages.
Error handling, expressiveness, testing culture, meta-programming and gradual typing have nothing to do with static vs dynamic typing.
The main "advantage" of dynamically typed languages is that you can start writing code now and not thing about it too much. Then you discover all the problems at runtime...forever.
Statically typed languages force you to think about what you are doing in advance a lot more which can help you avoid some structural issues. Then when you do refactor computer helps you find all the places where you need to change things.
Dynamically typed languages force you to write more tests that are not required in statically typed languages and that might prompt you to write other tests but if also increases the chance you just give up when you start refactoring.
Finally, after some time has passed and few updates have been applied to the language and libraries, you may not have a working project anymore. With statically typed languages you can usually find and fix all the compile errors and have the fully working project again. With dynamically typed languages, you will never know until you explore every line of code, which will usually happen at runtime and on the client computer.
> The bottom line: There are only two absolutely guaranteed ways to build bug-free, resilient, maintainable software. Two. And they are not static vs. dynamic typing. Two ways. Thing is - we humans have yet to discover either of those two.
That's true but some languages don't let you ship code to prod that multiplies files by 9, or that subtracts squids from apricots
I think a lot of people feel repulsed by dynamic typing for the same reason I used to: they wrote a lot of JS, and now they write a lot of TS. The experience of working in a JS codebase vs working in a (well-typed and maintained) TS codebase is a wide, wide gulf. I love working in TS, and I absolutely despise working in JS.
For a while I extrapolated my experience to mean “static typing is awesome and dynamic typing is horrible”, but then I started learning clojure, and my opinions have changed a lot.
There are a ton of things that make a codebase nice to work with. I think static typing raises the quality floor significantly, but it isn’t a requirement. Some other things that contribute to a good experience are
- good tests, obviously. Especially property based tests using stuff like test.check
- lack of bad tests. At work we have a very well-typed codebase, but the tests are horrible. 100 lines of mocks per 20 lines of logic. They’re brittle and don’t catch any real bugs.
- a repl!!
- other developers and managers who actually care about quality
All four of these examples seem pretty easy to find in the clojure world. Most people don’t learn clojure just to get a job, which is maybe a hidden feature of building your company with a niche language.
At the same time, I recognize that most of those examples are “skill issues”. Static typing does a good job of erasing certain skill issues. Which is great, because none of us are perfect all the time!
I wouldn’t say that static types remove the need for unit tests… but they do significantly reduce that need.
Static types and unit tests are not equivalent either. A static type check is a proof that the code is constructed in a valid way. Unit tests only verify certain input-output combinations.
If you're trying to hot swap a function for a version with a different type signature, how was the new code going to run successfully anyway? Unless the type signature changes aren't reflecting the runtime behaviour changes?
I mean, lots of extremely talented and successful engineers, e.g., DHH, think strict typing is actually a negative. I think if you think strict typing is an absolute disqualifier, you should steelman the opposing side.
His "argument" for strict typing on the Lex Fridman podcast was also that it's mostly if you have "hundreds or (of?) thousands of engineers collaborating", which "strictly" puts his opinion in the bin in my case. I have absolutely, positively become more productive as a single developer due to strict typing. Parsing various kinds of binary data was enough to convince me. A.k.a. each to their own. On the whole, Elixir and BEAM seem really cool though, and there's work being done on typing, as well as the new Gleam language.
Note: I've not yet done any serious web-development, mostly command line tools, which I realise is not DHH's main focus.
I tried both and I respect different opinions about this. I feel like TS' type system makes me crazy because it's going too far. But no typing makes me anxious. I guess there is a sweet spot to find for me personally.
It combines the "opinionated" aspects of ruby and rails and the power of erlang. The BEAM is like no other runtime and is incredibly fun to work with and powerful once you get how to use genservers and supervision trees.
We use Elixir for Mocha, and my one issue with it (I disagree with OP on this) is that live-view is not better than React for writing consumer grade frontends. I wish Phoenix took a much stronger integration with React approach, that would finalize it as the top choice for a web stack.
My current project is using React Native (for native and web) and getting GraphQL setup was initially a pain, but having React and GraphQL subscriptions gives me enough of the "live" functionality, but without having to worry about connection issues. With gql-tada, I get fully typed experience on the front-end too.
Yeah it’d be nice if they had a mix task to include your js frontend of choice and it “just worked”. Many have used inertia with success. I’m taking a different approach and pairing svelte with Phoenix channels.
Yes, it’s always a surprise to me that, given how great Elixir is, it didn’t take over backend development. It seems so much better suited to doing something similar to microservices without a lot of the overhead you’d think people would love it. It always seems that fads win and projects with extremely tight concepts remain niche.
While Elixir is my current favorite language to hack in, it is very alien and downright hostile to integrating with existing systems. For example, relational database support was postgres focused for a long time (to the exclusion even of SQLite and continued inability to talk to Oracle). Then you have articles like https://dashbit.co/blog/you-may-not-need-redis-with-elixir pushing ETS over Redis. While it's a valid argument, it's not adoption-friendly.
Clojure brings about half the novelty of Elixir, runs on the JVM and still struggles to replace Java.
Pretty sure there has been BEAM connectivity for Oracle for at least five years. SQLite3 is one of the defaults in Phoenix and have been for a long time. I do mix phx.new curious_idea --database=sqlite3 at least once a week, it's a sub-minute effort to a mostly generated base for a prototype (with OK auth/user management) I can just throw on a VPS and show someone.
If you want an in memory store without interfacing over HTTP, that is less foreign than ETS, try Duckdbex. Mix.install or add to mix.exs, then it's two lines and you get a connection to an ephemeral database with a SQL interface. Can probably do the same with SQLite but I've never done it. If your needs are simple you can just boot a GenServer with a K-V structure as state.
Pattern matching, the capture operator and functional programming style are the really "hostile" parts, in my experience.
One thing the author didn't mention is how incredibly polished the primary ecosystem of documentation, standard library, and tooling is. The Elixir standard library is incredibly consistent in order to support Elixir's piping operator, such that the first argument will basically always be the information you want passed from the function before it. In comparison, I frequently have to check the docs to confirm argument order on any lesser-used function in Python, Javascript, or C#. Then there's the fact that the second-layer of standard library, the OTP inherited from Erlang, which is expansive to the point of containing most things you'd want to do on a server. The documentation, in turn, is the gold standard that I (typically negatively) compare all other language docs to. It's organized, discoverable, and covers not just the "what" but the "How" and "Why" exceptionally well, not just at the function level, but the module layer as well. Frankly, only MDN comes close. All combined, it's just an incredibly productive language.
Hi! I recently tried to get into Elixir as an antidote to an acute javascript-fatigue...
To my surprise this there isn't really a good mobile story to build mobile apps for both Android and iOS with it, although it looks like it could be a great option for quick turnaround mobile apps with a web- or native frontend...
I know that there is something being worked on, eg. LiveView native: https://native.live/ , but that seems to target two entirely different frontend frameworks, one for each platform...
I started using capacitor as a wrapper for a HTML frontend, but I think I might potentially run into trouble when I'd try to move into production builds...
I think there's some space for research and maybe some nice starter packs / tutorials there... Because I think it is a big and pretty relevant market for browser-based apps, which Elixir seems to be very well suited to!
I'm grateful for any additional pointers, peace out! :)
This language and its upsides (that come from the VM) really are not for application development in this manner. I'm sure you can make it work somehow but its like using a tank to get groceries. Reliability, scalability, aren't concepts relevant to apps on mobile phones. If an app crashes to the homescreen thats fine, if your entire service goes down that's another. Would be fun if someone could prove me super wrong here but if you want to learn Erlang/Elixir/Gleam or anything BEAM I'd pick a backend project.
Uh, yeah, it's primarily a backend language, with any frontend stuff being either a thin layer or experimental, AFAICT. OTOH, doing a more traditional backend-heavy web app might be just the thing for JS fatigue. :)
I've been using Elixir for about a year on a side project and I've been enjoying it more than any other backend I've used (Node, Rails and C#). I recently discovered Ash and I feel like after that initial learning curve my productivity (and code quality) has improved quite a bit.
I wish Elixir had more mindshare beside just LiveView and "real time" type functionality. Even building a GraphQL/JSON endpoint without real-time requirements, the functional nature (no side effects), pattern matching and ruby inspired syntax makes writing plain old JSON controllers a joy.
While Elixir might not have a package for every use case under the sun, the low level primitives are there.
Yes, the learning curve is a extremely high. It took a few false starts over time, but after the "Ash book" came out, I gave it a more serious try and it finally started to click for me.
I think it helped that at the time I was trying to build some pretty advanced filtering functionality using Ecto and was having a pretty tough time. While searching for solutions I saw a few mentions of Ash and that it could solve the problem out of the box.
After a few days of experiments, I found that it was able to do the filtering I wanted out of the box and was even more functional than what I was trying to build.
For reference, I was trying to add some tagging functionality to a resource and I wanted to be able to filter by that tag, including multiple tags. Can I do that in Ecto? Of course, but Ash provided that out of the box after modeling the resource.
Except that it's not like Rails in the sense that in Rails, you will eventually develop extremely difficult to debug race conditions thanks to mutability that Elixir lacks.
Source: Has worked on million-line Ruby on Rails codebase
Readit News
The two experiences couldn't be more different. While I loved the great development speed for my personal projects, where I am writing more code than reading it, joining an existing project needs the opposite, reading more code than writing it. And I can only repeat what many people say, dynamic typing makes this so much more difficult. For most code changes, I am not 100% certain which code paths are affected without digging a lot through the code base. I've introduced bugs which would have been caught with static typing.
So in my conclusion, I'm bullish on gleam, but also on other (static) languages embracing the cooperative green-thread/actor model of concurrency like Kotlin (with JVM's virtual threads). (On another note, I personally also dislike Phoenix LiveView and the general tendency of focusing on ambiguous concepts like Phoenix Context's and other Domain Driven Design stuff)
Fun to develop and solo administer. Small teams with a well known codebase can do amazing things. I work at orgs with multiple teams and new hires who don't know the codebase yet.
For me, the sweet spot is Go.
What actually drove me nuts was absence of guards and meaningful static analysis on return values. Even in my small but nontrivial personal codebase I had to debug mysterious data mismatches after every refactor. I ended up with a monad-like value checking before abandoning Elixir for my compiler.
What you're describing are the same uncertainties I've used to have writing PHP a long time ago, but since using optional types and PHPStan checker, it kind of serves as a compiler pass that raises those issues. The benefit being that I still can be lazy and not type out a program when I prototype the problem on my first pass.
It’s in the works and recent versions of the compiler already catch some type errors at compile time, but it’s nothing remotely close to what you get from Typescript, or from any statically typed language like Go, Rust, Java, etc.
Sort-of. Developers provide typespec which is like a hint and use dialyzer to find issues before runtime.
A blog post by them about this: https://building.nubank.com/tech-perspectives-behind-nubanks...
They have a success typing system (which isn't very good) and are working on a fuller system (which isn't very mature).
If typing is the only thing keeping you out, have a look at Gleam.
Having worked with Elixir professionally for the last six years now, it is a very mature platform, very performant and offers many things that are hard in other languages right out of the box.
I see this phrase around a lot and I wish I could understand it better, having not worked with Erlang and only a teeny tiny bit with Elixir.
If I ship a feature that has a type error on some code path and it errors in production, I've now shipped a bug to my customer who was relying on that code path.
How is "let it crash" helpful to my customer who now needs to wait for the issue to be noticed, resolved, a fix deployed, etc.?
There is also pattern matching and guard clauses so you can write something like:
def add(a, b) when is_integer(a) and is_integer(b), do: a + b
def add(_, _), do: :error
It’s up to personal preference and the exact context if you want a fall through case like this. Could also have it raise an error if that is preferred. Not including the fallback case will cause an error if the conditions aren’t met for values passed to the function.
It reminds of the not-missed phpspec, in a worst way because at least with PHP the IDE was mostly writing it itself and you didn't need to add the function name to them (easily missed when copy/pasting).
atom, binary, boolean, function, list, map, pid, reference, integer, float, and tuple
There are a few others but they are generally special cases of the ones above. Having so few data types tends to make it much more obvious what you’re working with and what operations are available. Additionally, because behavior is completely separate from data it’s infinitely easier to know what you can and can’t do with a given value.
Ruby being dynamic drove me insane at times, but Elixir/Erlang being dynamic has been a boon to productivity and quality of life. I recently had to write some TypeScript and was losing my mind fighting the compiler, even though I knew at runtime everything would be fine. Eventually I slathered enough “any” on to make the burning stop… But! That’s something I haven’t had to do in years, and it was 100% due to type system chicanery and not preventing a bug or making the underlying code more sound.
There are still some occasions where having some static typing would be nice— but they’re pretty rare and often only for things that are extremely critical or expensive to fix. And IMHO even in those cases, Elixir’s clarity and lack of (implicit) state generally make up for it.
Sure, the nature of Elixir probably makes it easier but I find little joy in dynamic whack-a-mole and mental gymnastics to infer types instead of fricking actually being able to see them immediately.
I could go commando in TS as well and switch to JS and JSDoc, leaving everything gradually typed and probably be fine but I'd feel terribly sorry for anyone else reading that code afterwards. It'd be especially silly since I can now just infer my auto-generated Postgres zod schemas with little effort. Moreover, a good type system basically eliminates typing-related bugs which you guys apparently still have.
So please, don't over-generalize just because you think you got it figured out.
It seems like the Elixir/Erlang community is aware of this, as is Ruby, but it's a rather large hole they have to dig themselves out of and I didn't feel particularly safe using the tools today.
I've heard a lot of good things about the Erlang runtime and I did really like Elixir's pipe operator, so it was unfortunate.
https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
There's also tooling like dialyzer, and a good LSP catches a lot too. The language itself has some characteristics that catch errors too, like pattern matching and guard clauses.
With all that said, I'm still very keen for static typing. In the data world we mostly start with Python without mypy, and it's pretty hard to go back.
The eng department velocity will slow as code complexity grows and teams change. Dynamic typing makes this worse.
They are actively shipping a type system for Elixir though, which as far as I understand is pretty similar to TS so, great!
But pattern matching in Erlang does do a lot of the heavy lifting in terms of keeping the variable space limited per unit of code which tends to reduce nesting and amount of code to ingest to understand the behavior you care about at any moment.
there are other things that contribute to this like pretty universal conventions on function names matching expected outputs and argument ordering.
it does suck hard when library authors fail to observe those conventions, or when llms try to pipe values into erlang functions, and yes, it WOULD be nice for the compiler to catch these but you'll usually catch those pretty quickly. you're writing tests (not for the specific reason of catching type errors), right? right?
lol
There are some very sharp Computer Scientists who believe static typing is unnecessary. Joe Armstrong (co-designer of Erlang) once said: "a type system wouldn't save your system if it were to get hit by lightning, but fault tolerance would"
I have the same attitude toward overly permissive type systems that I do toward the lack of memory safety in C: People sometimes say, "if you do it right then it isn't a problem," but since it objectively IS a problem in practice, I would rather use the tool that eliminates that problem entirely than deal with the clean-up when someone inevitably "does it wrong."
As such fault tolerance does not guarantee that you MRI scanner does not kill your patients.
You likely want both.
You get zero help and punished hard for failing.
Yes you are. First of all there isn't such a thing as "strict typing", types are either static/dynamic and/or strong/weak. I suppose you meant Elixir has no static types. It is however a strongly typed language.
And just like it usually happens, static typing enthusiasts often miss several key insights when confronting dynamically typed languages like Clojure or Elixir (which was inspired by ideas implemented in Clojure).
It's not simply "white" and "black", just like everything else in the natural world.
You have to address:
- Runtime flexibility vs. compile-time safety trade-offs — like most things, things have a price to it, nothing is free.
- Different error handling philosophies. Sometimes, designing systems that gracefully handle and recover from runtime failures makes far more resilient software.
- Expressiveness benefits. Dynamic typing often enables more concise, polymorphic code.
- Testing culture differences. Dynamic languages often foster stronger testing practices as comprehensive test suites often provide confidence comparable to and even exceeding static type checking.
- Metaprogramming power. Macros and runtime introspection enable powerful abstractions that can be difficult in statically typed languages.
- Gradual typing possibilities. There are things you can do in Clojure spec that are far more difficult to achieve even in systems like Liquid Haskell or other advanced static type systems.
The bottom line: There are only two absolutely guaranteed ways to build bug-free, resilient, maintainable software. Two. And they are not static vs. dynamic typing. Two ways. Thing is - we humans have yet to discover either of those two.
They clearly said they "can't go back to" it, meaning they've experienced both, are aware of the trade-offs, and have decided they prefer static types.
> Gradual typing possibilities. There are things you can do in Clojure spec that are far more difficult to achieve even in systems like Liquid Haskell or other advanced static type systems.
That's great for clojure and python and PHP, but we're not talking about them.
That's true but some languages don't let you ship code to prod that multiplies files by 9, or that subtracts squids from apricots
For a while I extrapolated my experience to mean “static typing is awesome and dynamic typing is horrible”, but then I started learning clojure, and my opinions have changed a lot.
There are a ton of things that make a codebase nice to work with. I think static typing raises the quality floor significantly, but it isn’t a requirement. Some other things that contribute to a good experience are
- good tests, obviously. Especially property based tests using stuff like test.check
- lack of bad tests. At work we have a very well-typed codebase, but the tests are horrible. 100 lines of mocks per 20 lines of logic. They’re brittle and don’t catch any real bugs.
- a repl!!
- other developers and managers who actually care about quality
All four of these examples seem pretty easy to find in the clojure world. Most people don’t learn clojure just to get a job, which is maybe a hidden feature of building your company with a niche language.
At the same time, I recognize that most of those examples are “skill issues”. Static typing does a good job of erasing certain skill issues. Which is great, because none of us are perfect all the time!
There are really good arguments both ways.
Just use what you need or go with whatever your current project dictates. Over time you will probably feel drawn to both, for different reasons.
Static types and unit tests are not equivalent either. A static type check is a proof that the code is constructed in a valid way. Unit tests only verify certain input-output combinations.
Erlang OTP relies on being able to swap to new functions to do upgrades without downtime.
Far from it.
Note: I've not yet done any serious web-development, mostly command line tools, which I realise is not DHH's main focus.
It combines the "opinionated" aspects of ruby and rails and the power of erlang. The BEAM is like no other runtime and is incredibly fun to work with and powerful once you get how to use genservers and supervision trees.
We use Elixir for Mocha, and my one issue with it (I disagree with OP on this) is that live-view is not better than React for writing consumer grade frontends. I wish Phoenix took a much stronger integration with React approach, that would finalize it as the top choice for a web stack.
If I didn't need native functionality, I'd probably just use the recently released `phoenix_vite`: https://github.com/LostKobrakai/phoenix_vite
Clojure brings about half the novelty of Elixir, runs on the JVM and still struggles to replace Java.
For what it’s worth, I’ve been using Elixir professionally for a few years now and haven’t touched Redis once.
Not sure why telling people they don’t need another service is bad for adoption?
If you want an in memory store without interfacing over HTTP, that is less foreign than ETS, try Duckdbex. Mix.install or add to mix.exs, then it's two lines and you get a connection to an ephemeral database with a SQL interface. Can probably do the same with SQLite but I've never done it. If your needs are simple you can just boot a GenServer with a K-V structure as state.
Pattern matching, the capture operator and functional programming style are the really "hostile" parts, in my experience.
It was never marketed that way though, and then Typescript took over which makes things even harder.
is there a popular pattern, perhaps as used by whatsapp, i guess?
To my surprise this there isn't really a good mobile story to build mobile apps for both Android and iOS with it, although it looks like it could be a great option for quick turnaround mobile apps with a web- or native frontend...
I know that there is something being worked on, eg. LiveView native: https://native.live/ , but that seems to target two entirely different frontend frameworks, one for each platform...
I started using capacitor as a wrapper for a HTML frontend, but I think I might potentially run into trouble when I'd try to move into production builds...
I think there's some space for research and maybe some nice starter packs / tutorials there... Because I think it is a big and pretty relevant market for browser-based apps, which Elixir seems to be very well suited to!
I'm grateful for any additional pointers, peace out! :)
How Elixir Powers the BBC From PoC to Production at Scale - Ettore Berardi | ElixirConf EU 2025 https://www.youtube.com/watch?v=e99QDd0_C20&ab_channel=CodeS...
I wish Elixir had more mindshare beside just LiveView and "real time" type functionality. Even building a GraphQL/JSON endpoint without real-time requirements, the functional nature (no side effects), pattern matching and ruby inspired syntax makes writing plain old JSON controllers a joy.
While Elixir might not have a package for every use case under the sun, the low level primitives are there.
It's like Rails except that there's much more resources for Rails to find if you made a mistake in the DSL
I think it helped that at the time I was trying to build some pretty advanced filtering functionality using Ecto and was having a pretty tough time. While searching for solutions I saw a few mentions of Ash and that it could solve the problem out of the box.
After a few days of experiments, I found that it was able to do the filtering I wanted out of the box and was even more functional than what I was trying to build.
For reference, I was trying to add some tagging functionality to a resource and I wanted to be able to filter by that tag, including multiple tags. Can I do that in Ecto? Of course, but Ash provided that out of the box after modeling the resource.
Source: Has worked on million-line Ruby on Rails codebase