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.
ludicity · 53m ago
It's not so bad in Elixir for various reasons. Firstly, they're doing some work on set-theoretic types.
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.
lknuth · 5h ago
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.
Einenlum · 5h ago
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.
lknuth · 1h ago
True. There is inter-op with both Elixir and Erlang, but thsts like early TypeScript.
If you're at all interested, I'd suggest doing the basic and OTP tutorials on the Elixir Website. Takes about two hours. Seeing what's included and how it works is probably the strongest sails pitch.
bsder · 2m ago
One of the problems with strict typing is that it makes it very difficult to hot upgrade a function to a different signature.
Erlang OTP relies on being able to swap to new functions to do upgrades without downtime.
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.
jamauro · 5h ago
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.
throwawaymaths · 4h ago
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?
victorbjorklund · 3h ago
I let the LLM write my tests. And when they fail it just rewrites the tests to pass.
williamdclt · 5h ago
I used it being a big proponent of the TS type system and I definitely missed it greatly.
They are actively shipping a type system for Elixir though, which as far as I understand is pretty similar to TS so, great!
codyb · 5h ago
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.
victorbjorklund · 3h ago
Maybe try Gleam? 80% of the goodies of Elixir is the BEAM anyway and you get that in Gleam too.
> 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.
lol
rendaw · 5h ago
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.
kingofheroes · 3h ago
Pattern matching makes up for the lack of static typing to me. It provides nearly all the same benefits especially when used with guard clauses.
the_gastropod · 5h ago
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"
tossandthrow · 5h ago
While I greatly appreciate elixir it is completely malplaced to contrast fault tolerance and type systems - they solve very different needs.
As such fault tolerance does not guarantee that you MRI scanner does not kill your patients.
You likely want both.
OkayPhysicist · 4h ago
It's likely Armstrong conflated the two there because a significant part of the fault tolerance of Erlang comes from the loose coupling via message passing between components, which in no small part is tied to the dynamic typing. It's a Postel's law thing, being generous in what you accept and strict about you send.
Elixir's seamless pattern matching paradigm, IMO, largely negates the need for strict typing. If you write your function signatures to only accept data of the type / shape you need (which you are incentivized to do because it lets you unpack your data for easy processing), then you can write code just for the pretty path, where things are as expected, and do some generic coverage of the invalid state, where things aren't, rather than the norm in software development of "I covered all the individual failure states I could think of". This generic failure mode handling, too, greatly benefits from dynamic typing, since in my failure state, I by definition don't know exactly what the structure of my inputs are.
tossandthrow · 4h ago
Yep, I have written and maintained several large scale applications In elixir and live the computation model.
However,elixir depreately needs proper types. IMHO the needs for types are in no means negated by pattern matching, and I also see hints at why you would say so.
> If you write your function signatures...
The point of types is worry less refactoring.
If you work at a place where you can define the arhicture for the entire lifecycle of the application without ever needing to Refactor, then sign me up! I want to work there.
throwawaymaths · 5h ago
no, but effort is a finite resource so it justifies why they didn't bother.
tossandthrow · 4h ago
Well, the people behind elixir seems to have accepted that typing is necessary.
I see this story on an on: some hacker makes a language, they hate types because they want to express themselves. The languages gets traction. Now enterprise application and applications with several devs use it and typing gets essential - types will then gradually be added.
throwawaymaths · 3h ago
sure, a few years behind typescript/mypy isnt really so bad for a language without a microsoft or a google behind it, is all im saying.
tossandthrow · 2h ago
> isnt really so bad for a language without a microsoft or a google behind it, is all im saying
What? Elm was literally the result of a single grad students side project - elm incorporates both a sound type system and FRP.
This has nothing to do with time. It was a decision not to support it.
bccdee · 4h ago
Okay? But "the features you need would have taken effort to implement, so we didn't implement them" is not a very good sales pitch when you're trying to convince me to use your tool to do my job.
throwawaymaths · 3h ago
ok. don't use it then. but be aware: your attitude is why things get stuck in (sometimes really awful) local minima in tech.
bccdee · 2h ago
Any tool that justifies the choice not to implement an important and highly-requested feature with "effort is a finite resource" alone is not viable for serious development work. It's not prioritizing, it's a refusal to prioritize.
coffeeindex · 5h ago
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
pmarreck · 5h ago
It's in line with the erlang philosophy of letting things crash trivially and restart instantly. Due to the universal immutability, starting a new process from a given state in Erlang/Elixir is nearly instantaneous and has extremely little overhead as they are not OS threads, they are BEAM VM threads.
Very opposite the Go model, btw.
tossandthrow · 4h ago
Letting you wrong computations crash does not make them right.
pmarreck · 2h ago
LOL. This only makes sense if you can know all the ways your code will fail... which you cannot.
Erlang/Elixir's approach is to simply say, "It's gonna fail no matter how many precautions we take, so let's optimize for recovery."
Turns out, this works fantastically in both cellphone signaling, which is where OTP originated, as well as with webserving, where it is perfectly suited.
tossandthrow · 1h ago
I don't know who are arguing with? Everyone loves the otp.
It just does not catch logics errors.
em-bee · 1h ago
whether that matters or not depends on whether the logic error occurs because of a rare combination of events or as a result of a certain state and whether that state remains after recovery. if there is for example a logic error that causes the app to crash after say 10 minutes of runtime, or eg. at a certain message size, then a recovery will reset the runtime and it will work again. it will of course invariably fail again after another 10 minutes or when the same message is resent, because it is a logic error, and logic dictates that the error won't go away no matter how often you restart, but it will work in the meantime.
in other words, any error that doesn't occur right at start can be recovered from at least for all those operations that do not depend on that error being fixed.
tossandthrow · 42m ago
This sound like a wild and very contrived argument.
Both because that memory leaks are normal is types languages - and does usually not matter in most serious applications - and because this class of errors is usually not what types catch.
Types have value when you 1) refactor and 2) have multiple people working on a code base.
The error you see when you don't have types is something like a BadArityError.
never_inline · 4h ago
To restart and fail again? How does that help with logic errors caused by wrong type objects?
pmarreck · 2h ago
It doesn't prevent the error, but it also won't take down your server when malicious users (or just lots of normal users) start to bang on that input with the problem, and your non-BEAM VM pool starts to run out of available preloaded stacks... You get a new Erlang process in well under a millisecond on modern hardware
It WILL log the error, with a stacktrace, so you have that going for you
Note that even with typing, you cannot avoid all runtime errors
Also note that this tech was first battle-tested on cellphone networks, which are stellar on the reliability front
victorbjorklund · 3h ago
Depends on the error. Lets say it is an error that happens once every 1 million users.
bccdee · 4h ago
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."
bluesnowmonkey · 15m ago
We had a cluster of servers, dynamically scaling up and down in response to load, and one day started seeing errors where an enum string field had an impossible value. Imagine the field is supposed to be "FOO" or "BAR" but one day in the logs you start seeing "FOO", "BAR", "GOO", and "CAR". Impossible. "GOO" and "CAR" did not exist in the code, nothing manipulated these strings, yet there they were.
Long story short, a particular machine that joined the cluster that morning had some kind of CPU or memory flaw that flipped a bit sometimes. Our Elixir server was fine because we were matching on valid values. Imagine a typed language compiler that makes assumptions about things that "can't" happen because the code says it can't... yet it does.
dminik · 5h ago
Tbh, the strongly typed and dynamically typed combination seems like the worst option.
You get zero help and punished hard for failing.
em-bee · 4h ago
how so? most dynamically typed languages are also strongly typed. that includes python, ruby, common lisp, smalltalk... if it was the worst option, this would not be the case.
dminik · 4h ago
A casual look at the history of basically anything will tell you that the best option isn't necessarily always the one that succeeds.
em-bee · 4h ago
sure, but when the majority of popular languages use that paradigm then it surely can't be the worst option either. what is it that makes it a bad combination?
dminik · 4h ago
Please, smalltalk and common lisp don't qualify as popular languages.
At this point I'm reaching into the low percentages. I think it's pretty clear that Strongly + Statically typed languages are massively over-represented on the list.
Both Strongly and Weakly Dynamically typed languages are similarly represented.
Note: I'm open to editing the comment to move languages from and to various categories. I haven't used many of them, so correct me if I'm wrong.
iLemming · 24m ago
> smalltalk and common lisp don't qualify as popular languages.
Sure, Smalltalk isn't, but Lisp is a different story. In this context I assume we all mean to say "Lisp" and not "Common Lisp" specifically.
Lisp (as the entire family of PLs) is quite massively popular.
Standard rankings have major blind spots for Lisp measurement, they miss things like, for example, Emacs Lisp is everywhere. There's tons of Elisp on GitHub alone, and let me remind you, it's not a "general-purpose" language, its sole function is to be used to configure a text editor and there's mind-boggling amount of it out there. AutoLISP is heavily used in CAD/engineering but rarely discussed online. Many Lisp codebases are proprietary/internal. Also, dialect fragmentation artificially deflates numbers when measured separately - many rankings consider them different languages.
If you count all Lisp dialects together and include: Emacs Lisp codebases, AutoLISP scripts in engineering, Research/academic usage, Embedded Lisps in applications, Clojure on JVM and other platforms - babashka scripts, Flutter apps, Clojurescript web apps, etc;
...Lisp would likely rank much higher than typical surveys suggest - possibly in the top ten by actual lines of code in active use.
em-bee · 4h ago
smalltalk and common lisp don't qualify as popular languages
not anymore. they were very popular in the industry at one point. very few other languages have so many independent implementations as smalltalk and lisp. a testament to their wide spread use in the past.
that doesn't make sense. typescript is javascript with types, it can't be both strong and weak at the same time.
but i believe we have a different definition of weak. just because javascript, php and perl have some implicit type conversions doesn't make them weakly typed. i believe it takes more than that. (in particular that you can't tell the type by looking at a value, and that you can use a value as one or another type without any conversion at all)
C is weakly typed, it was always a major criticism, C++ too i think (less sure about that).
once you correct for that you will notice that all languages in the strong and static category are less than 30 years old and many are much younger. (java being the oldest. but there are older ones like pike which is also strong and static and goes back to 1991)
the strong and dynamic category goes back at least a decade more. (if you include smalltalk and lisp)
what this does show is that static typing has experienced a renaissance in the last two decades, and also the worst is really using any form of weak typing.
i still don't get what makes strong and dynamic a bad combination, other than it's bad because it is not static.
dminik · 3h ago
I mean, if you define weak like that, then yeah. But also, what languages are you left with? Assembly? Then again, it does fit with your definition of popular being popular 45 years ago. Tbh, I'm not sure if smalltalk was ever even popular. It was certainly influential, but popular?
I know that there are discussion about what strong vs weak even means, but I think most people would place the weak distinction way above yours on a possible weak-strong spectrum.
C can certainly be argued to be weak. My understanding is that it's mostly due to pointers (and void* especially). C++ is much better in this regard. I mostly just did not want to add a Weak + Static category just for one language.
Well, now that you've defined Strong to also include all of the languages I consider Weak, then yeah, no issues at all.
throwawaymaths · 5h ago
nah you just get log lines. crash is not as bad as you think it is.
dminik · 4h ago
I mean, it is a kind of a bug that is easy to prevent with a static type checking, but also one that will always (or almost always) get triggered.
Log lines are whatever, but a system that goes into a crash loop or fails on most requests isn't great.
michaelterryio · 5h ago
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.
Einenlum · 5h ago
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.
Towaway69 · 5h ago
I prefer something like specs[1] that define a function’s signature but isn’t enforced by the compiler, instead the linter enforces them.
This is what Erlang has and it’s very convenient since once a design is fixed, I end up writing a spec to remind me what types the function expects.
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.
nichochar · 6h ago
Elixir and Phoenix are very underrated.
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.
4b11b4 · 5h ago
Any thoughts on Inertia for including React into the picture?
andy_ppp · 6h ago
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.
tl · 5h ago
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.
hangonhn · 6h ago
I've been wanting to learn Elixir for a long time but is it worth learning it without knowing Erlang first? I'm not against learning Erlang but just curious if Erlang is a good thing to know before tackling Elixir.
heeton · 5m ago
~5 year pro elixir here, various systems in production, I don't know any erlang.
cybrox · 1h ago
We've been running Elixir in production for 5+ years and most of our team only know some very basic erlang data structures for working with the :dbg module on live systems.
Erlang knowledge is not needed for building products with Elixir at all unless you want to go very in-depth.
spike021 · 5h ago
I only learned Elixir because the company I currently work for is an Elixir shop. I've basically ignored Erlang since I started here, other than the occasional library being Erlang.
I don't think it's really impeded my ability to learn or use Elixir. But I could also see how learning it and the underpinnings for Elixir could aid understanding too.
Towaway69 · 6h ago
Erlang is definitely worth learning but definitely not required by Elixir.
Learning the concepts that embody Erlang such as tail recursion and function matching, make Erlang worth learning. Erlang is also a special mix of Prolog and Lisp.
pivo · 4h ago
To add to this, Erlang is a very simple language that you can learn in just a few days. I don't know Elixir but I assume that, as is the case with Erlang, the more difficult thing to learn is OTP and not the language itself.
For me Erlang was worth learning because it's so interestingly different to many other languages because of its Prolog roots.
arrowsmith · 3h ago
It is absolutely 100% _not_ necessary to learn any Erlang at all before learning Elixir. I've been developing with Elixir for 5 years and still have never written a line of Erlang.
You don't need to learn OTP at first either — it'll just slow you down and confuse you. Learn Elixir syntax and semantics, learn how to build a Phoenix app or whatever, then dive into OTP once you're comfortable with the basics.
runjake · 6h ago
You don't need to learn Erlang first.
thibaut_barrere · 6h ago
Yes, it is worth it to learn Elixir without learning Erlang, absolutely.
_acco · 6h ago
I consider myself expert-level at Elixir and did not learn Erlang first. Couldn't write a single line of Erlang today unaided if I tried.
I picked up Joe's Erlang book years after out of pure joy/curiosity.
Especially with LLMs, totally unnecessary.
parthdesai · 5h ago
You can get very very far in Elixir without even knowing about an acronym called OTP.
moritz · 3h ago
Maybe not Erlang the language, but it’s useful to know its "philosophy" and what the BEAM is all about.
cultofmetatron · 5h ago
I built a whole startup in elixir from 0 to 1000+ active subscriptions. I don't know a lick of erlang.
davidw · 38m ago
That's pretty cool - what is it if you don't mind talking about it? How do you feel Elixir made it possible or easier. Or is it just something you happened to choose and you could have used Node or Rails or whatever else.
OkayPhysicist · 5h ago
You do not need to know much, if any, Erlang to be productive in Elixir. Some libraries you might call will be written in Erlang, but those tend to have been around long enough that you don't need to look inside. Being able to read the Erlang docs can be helpful, because the OTP has a ton of helpful functions, but that's mostly just learning what Erlang calls its types.
OkayPhysicist · 5h ago
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.
ngruhn · 6h ago
The only thing putting me off is the lack of static typing. But I'm open to be convinced that this doesn't matter.
_acco · 6h ago
It doesn't matter as much as you think. I believe this is in part due to how assertive most Elixir code tends to be. [1] These assertions not only aid the LSP and can cause compiler warnings/errors, they also help LLMs just like types do.
Still, every release now contains new type system features. Next up is full type inference. [2] After that will be typed structs.
Pattern matching makes up for the lack of static typing for me. Combined with guard clauses it feels even stronger than static typing.
foxygen · 6h ago
They are working on a type system.
danman114 · 4h ago
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! :)
KevinMS · 4h ago
Some don't use it because the performance on anything other than IO is just bad. This isn't just because its "not compiled", but because it has a scheduler taking up cycles and it enforces immutability, when can be brutal for some tasks when mutability can really speed things up.
cpursley · 6h ago
Fwiw, Claude 4 is really good with Elixir, including whipping up quality test suites.
Jonovono · 34m ago
Ya, it one shotted a Server driven ui app using elixir backend, expo with phoenix channels. Was impressed.
spike021 · 5h ago
Can agree with this. I have had some funny hallucinations, though, where it mixes up Elixir keywords with totally unrelated to programming things and then acts very confident that said things are in Elixir. So you just need to be a bit skeptical and double-check it. But that goes with the LLM territory anyway.
ch4s3 · 6h ago
> whipping up quality test suites.
YMMV, but I think it writes fine unit tests, but really sub par functional or end to end tests that need to check business logic. I think that's just a hard case for LLMS and not an elixir issue though.
mike1o1 · 6h ago
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.
realusername · 6h ago
Personally while I enjoy Elixir/Phoenix, I didn't like Ash because there's way too many keyword DSL to learn.
It's like Rails except that there's much more resources for Rails to find if you made a mistake in the DSL
mike1o1 · 6h ago
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.
pmarreck · 2h ago
So if you're comfortable with Ecto and SQL, you can safely skip over Ash?
borromakot · 18m ago
That is like 0.5% of what Ash helps with :)
pmarreck · 5h ago
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
throwawaymaths · 6h ago
if the author is reading this a minor edit should be that whatsapp uses erlang, not elixir.
kingofheroes · 3h ago
I just started learning Elixir recently and I'm honestly loving it. Pattern matching is awesome and how it approaches concurrency and async work was so easy to wrap my head around. Pragmatic Studios has a great tutorial.
dzonga · 6h ago
I have come to the simple conclusion that yeah if a tech is great and people are not launching products internally or as startups then maybe it's time to introspect.
if using elixir supposedly gives a competitive advantage, why aren't companies using to launch new products - both existing and startups.
a lot of those things quoted in the article are present on the jvm platform or through containers.
and btw some of those companies listed have migrated away from elixir e.g brex and discord.
thibaut_barrere · 6h ago
Companies _are_ launching products with it ; that you aren't hearing about it is more about communication & leverage, than about their existence.
A while back there was an effort to give more publicity on precise cases here https://elixir-lang.org/cases.html ; I think the effort is now moving to advertising the platform outside Elixir circles (e.g. more generalist conferences).
FWIW, I'm working on https://transport.data.gouv.fr, Elixir-based since 2016, the National Access Point to transportation data, which includes a business specific reverse proxy with a 3x YoY growth, with no plans to migrate :-)
cosmic_cheese · 4h ago
I’m not so sure that popularity has any kind of correlation with capability, quality, viability, etc. That has more to do with marketing, social media trends, buzzword compliance, and what’s caught the eye of the current crop of resume-driven developers and managers.
Tools like Elixir which are focused on solving problems, aren’t flashy or easy for web dev influencers (yes, they’re a thing) to tout, and have a bit of higher barrier to entry are probably at a disadvantage in this way, even if they’re actually quite good.
This is why the industry is stuck on a revolving door of JS frameworks and the n-hundreth React self-reinvention. It’s not about how good any of this actually is, it’s about how well it scratches the itch for that new car smell while also being easy to pick up and make grand declarations on social media about.
em-bee · 4h ago
maybe it's time to introspect
to learn what? that the language was not good enough? that it wasn't marketed well enough? that there was not enough community support? not enough word of mouth?
lisp users say they have a competitive advantage, as do smalltalk users. even pike at a time had a competitive advantage in that it was/is more performant than other similar languages.
some of us in the pike community kept asking ourselves why pike is not more popular. the syntax is not obscure. roxen was a killer webdev server, 10 years ahead of its time. but no takers. why? (probably a mix of lack of marketing and community support/encouragement from the financial backers, but other languages become popular without backing, so what gives?)
my point is that most times there is nothing you can do. unless you have the marketing power of sun (java) or google (go, etc), popularity of a language is mostly a case of luck and serendipity (ruby, python) or filling a unique need that no other language could (javascript, rust)
Elixir also does not stand alone - the storied history of Erlang/BEAM in mission-critical distributed systems needs no introduction. Elixir lives within, and benefits from, that same ecosystem of libraries and tools.
So yeah I'm not sure what you believe there is to "introspect" about, nor to what end.
weatherlight · 5h ago
3 out of 5 of all the phone calls you've ever made was managed by a box somewhere running the Erlang VM (BEAM) which Elixir gets all its concurrency and parallelism from.
And no, Discord has not moved away from Elixir. While they have adopted Rust for certain parts of their infrastructure, Elixir remains a core part of their backend, particularly for real-time communication and chat infrastructure.
I have a ton of respect for José Valim and the Elixir core team, I have to say: Elixir just doesn’t mesh well with the kind of infrastructure tooling that’s become standard today. The ecosystem has been growing impressively and there’s a lot to admire, but its philosophy often feels at odds with containerized, Kubernetes-based deployments.
Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly.
This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.
ch4s3 · 6h ago
If you can't get Elixir to work well in k8s, you're simply doing it wrong. Yeah you can build a lot of what k8s offers on the BEAM on a bare server but you don't have to at all. Elixir offers modern telemetry that works really well with pretty much any monitoring tool, and give you a lot of introspection into the internals of the VM if you need it. "Let it fail" works just fine in k8s, you can run a supervision tree in a container and have it manage process restarts internally just fine, its just an added layer of fault tolerance. Sure, you can't easily have long running stateful processes if you're doing a lot of blue-green deployments, but you probably don't need to do that most of the time.
If you don't know Elixir and the BEAM well, of course you're going to have a bad time. That's true of any language.
benmmurphy · 5h ago
phoenix live view is effectively built around the assumption that the server process never dies and never restarts. its a very dubious model for a production deployment.
> what happens when the server restarts / connection is lost / server dies?
> you lose all of the current client state but you can work around this by persisting all the client state somewhere.
> oh, so why am i using live view again?
ch4s3 · 5h ago
> phoenix live view is effectively built around the assumption that the server process never dies and never restarts.
Not exactly, it's built to hold state in memory by default but doesn't assume how you want to handle deploys or server restarts. There's a built in restore mechanism for forms and it's trivial to shuffle state off to either the client/redis/your db[1]. You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice. Or you conversely have the problem that refreshing the page trashes client state.
So there are two thinks here, you don't have to use live_view to use elixir or phoenix, and if you do you just need to actually think about how you're solving problems. The state can get trashed anywhere for any number of reasons. Tossing on the client and forgetting about it just moves the problem.
Elixir has a Ruby on Rails approach which is kind of all in one. Not everyone’s cup of hot chocolate.
Erlang is low level, lightweight processes and message passing - perfect for micro-services and containerisation.
What Erlang lacks are high level web-oriented packages, i.e. markdown conversion, CSS and JavaScript packaging, REST (not quite true: cowboy is fantastic) - for which though Erlang was never intended.
However the cool thing is that you can combine both in the same project, allowing you to have high level Elixir and low-level process management in one project. This is possible because both use the same virtual machine - BEAM.
davidw · 18m ago
Erlang isn't really that much lower level than Elixir. The Elixir syntax is just a bit different and they've improved a few things like string handling. Processes are still processes.
jon-wood · 6h ago
Sure, if your a company which is fully bought into ephemeral containers running on Kubernetes then Elixir is probably not going to be a great fit for you. I have once introduced it into a company like that and eventually the same thing happened, the application got rewritten in a language that fits the paradigm better.
If I were starting a new company today though I'd probably go with Elixir, and then I simply wouldn't bother with containers, Kubernetes, and schedulers. Just run some servers and run the application on them, let them cluster, and generally lean into the advantages.
em-bee · 4h ago
most people/companies who think they need kubernetes don't actually need it. you are not google or amazon. and with erlang/elixir that's likely even more true.
lknuth · 5h ago
We look at K8s more like "the Cloud Operating System". Many of its capabilities are more valuable for other runtimes, but that doesn't mean that Elixir is a bad fit with it.
For example, the Erlang VM clustering can make use of K8s for Service Discovery. You can do ephemeral containers and use readiness probes to create a " hand over" period where new instances can sync their data from old, about-to-be-replaced instances.
sisve · 4h ago
Did you do hot updates? I ser that is mention in the post, but I thought the community has walked away from it? Or at least that its mixed feelings about it?
Dowwie · 6h ago
being able to remote into the runtime, manage state and interact with internal BEAM processes is an amazing experience
Towaway69 · 5h ago
That’s the BEAM and is common to Erlang, Elixir and Gleam.
So it’s not a feature specific to Elixir since the BEAM is the common virtual machine.
Dowwie · 3h ago
I'll take Elixir, thanks.
Towaway69 · 6h ago
I personally prefer Erlang because I’m closer to ideals: lightweight processes, message passing and behaviours.
Elixir abstracts that away and leaves a ruby-like language that hides much away - which good and fine.
Erlang is by no means a simple language to get one’s head around.
Joker_vD · 6h ago
> For those I managed to confuse, “glass-to-tin” just means “front-to-back” or “from the screen to the back end”.
So like a thin mirror? Which only serves to show the viewer back to themselves? And which also consists of just two extremely simple parts, that is, two panes/sheets of uniform materials, and nothing more?
How do you even come up with this metaphor for a web-based application? It's horrible!
matthewsinclair · 5h ago
Sorry, it didn't land for you. It's something I've used for a while ("glass" for the screen, and "tin" for the back-end). Perhaps I'm showing my age or my Aussie slang. Thanks for reading, in any case!
maratc · 5h ago
Elixir's syntax is very intimidating. We maintain a fork of "bors-ng", I'd very much like to hack around a fix or two, but just stare at the code in awe.
asib · 5h ago
What part of the syntax is intimidating? To my mind, it's not all that dissimilar from e.g. Python, which is not a language about which people express the same feeling.
cybrox · 56m ago
Structure and control flow feels very Python/Ruby-ish, however, when you get into the depths of pattern matching and binary deconstruction or even macros, Elixir syntax can become somewhat messy. However, the same concepts, once understood, are extremely powerful for parsing or protocol handling.
Am I the only person who is put off by Elixir by the lack of S-expression syntax?
I decided to learn Clojure for my next language.
iLemming · 55m ago
> Am I the only person
No, you're not alone. After learning Lisp, structural editing and REPL-driven-development, I just don't feel like needing to learn new languages no matter how powerful they seem to be. Lisps like Clojure are highly pragmatic and offer something fundamentally different from the endless parade of syntax-heavy languages that dominate the mainstream.
Once you've experienced the fluidity of paredit or parinfer, where you're editing the structure of your code rather than wrestling with textual representations, going back to manually balancing brackets, fixing indetnation and carefully placing semicolons feels like reverting to a typewriter after using a word processor. The code becomes malleable in a way that's hard to appreciate until you've lived with it.
And the REPL changes everything about how you think and work. Instead of the write-compile-run-debug cycle, you're having a conversation with your running program. You can poke at functions, test hypotheses, build up solutions incrementally, and see immediate feedback. It's exploratory programming in the truest sense - you're not just writing code, you're discovering it.
The homoiconicity - code as data - means you're working in a language that can easily reason about and transform itself. Macros aren't just text substitution; they're proper AST transformations. This gives you a kind of expressive power that most languages can't match without tremendous complexity.
So when the latest trendy language appears with its new syntax and novel features, it often feels like rearranging deck furniture. Sure, it might have nice type inference or clever concurrency primitives, but you're still stuck in the old paradigm of fighting syntax and losing the conversational flow of development.
You've tasted something closer to the pure essence of computation, and it's hard to go back.
amarsahinovic · 37m ago
There is Lisp Flavoured Erlang https://lfe.io/ created by Erlang co-inventor Robert Virding.
Jtsummers · 4h ago
Considering the vast majority of languages don't use s-exprs, possibly. There aren't many hardcore lispers who refuse to use anything but s-exprs.
em-bee · 4h ago
while i love s-expressions, i am not aware of any language outside the lisp ecosystem that supports it natively. are you saying that you are put off that elixir is not lisp?
i am interested in clojure, but i am put off by it using the java run time. ;-)
iLemming · 1h ago
> i am interested in clojure, but i am put off by it using the java run time
Clojure runs not only on Java - you have Clojurescript, you have babashka and nbb, you have Clojure-Dart — if interested in building Flutter apps, you can even use Clojure with Python libs. If you need to target Lua, there's Fennel, which is similar as it's inspired by Clojure.
For me - Clojure is a hands-down best medium for data manipulation - there's just nothing better out there to explore some data - investigate APIs; sort, group, dice and slice any kind of data - CSVs, JSON, etc. Nothing else simply can match the joy how one could incrementally build up complex data transformations, it makes it incredibly productive for the "let me just quickly check this shit" scenarios that can easily turn into full analyses. REPL-driven nature of it makes it so much fun - you feel like you're playing a videogame.
I honestly wish every programmer knew at least some Clojure. I lost count of how many times I gave up on figuring out complex jq syntax and reached for Clojure instead. Or the times I'd quickly build a simple Playwright script for reproducible web-app bug trapping or quick data scraping that saved me hours of frustration and manual clicking.
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.
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.
If you're at all interested, I'd suggest doing the basic and OTP tutorials on the Elixir Website. Takes about two hours. Seeing what's included and how it works is probably the strongest sails pitch.
Erlang OTP relies on being able to swap to new functions to do upgrades without downtime.
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.
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?
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.
lol
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 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"
As such fault tolerance does not guarantee that you MRI scanner does not kill your patients.
You likely want both.
Elixir's seamless pattern matching paradigm, IMO, largely negates the need for strict typing. If you write your function signatures to only accept data of the type / shape you need (which you are incentivized to do because it lets you unpack your data for easy processing), then you can write code just for the pretty path, where things are as expected, and do some generic coverage of the invalid state, where things aren't, rather than the norm in software development of "I covered all the individual failure states I could think of". This generic failure mode handling, too, greatly benefits from dynamic typing, since in my failure state, I by definition don't know exactly what the structure of my inputs are.
However,elixir depreately needs proper types. IMHO the needs for types are in no means negated by pattern matching, and I also see hints at why you would say so.
> If you write your function signatures...
The point of types is worry less refactoring.
If you work at a place where you can define the arhicture for the entire lifecycle of the application without ever needing to Refactor, then sign me up! I want to work there.
I see this story on an on: some hacker makes a language, they hate types because they want to express themselves. The languages gets traction. Now enterprise application and applications with several devs use it and typing gets essential - types will then gradually be added.
What? Elm was literally the result of a single grad students side project - elm incorporates both a sound type system and FRP.
This has nothing to do with time. It was a decision not to support it.
Very opposite the Go model, btw.
Erlang/Elixir's approach is to simply say, "It's gonna fail no matter how many precautions we take, so let's optimize for recovery."
Turns out, this works fantastically in both cellphone signaling, which is where OTP originated, as well as with webserving, where it is perfectly suited.
It just does not catch logics errors.
in other words, any error that doesn't occur right at start can be recovered from at least for all those operations that do not depend on that error being fixed.
Both because that memory leaks are normal is types languages - and does usually not matter in most serious applications - and because this class of errors is usually not what types catch.
Types have value when you 1) refactor and 2) have multiple people working on a code base.
The error you see when you don't have types is something like a BadArityError.
It WILL log the error, with a stacktrace, so you have that going for you
Note that even with typing, you cannot avoid all runtime errors
Also note that this tech was first battle-tested on cellphone networks, which are stellar on the reliability front
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."
Long story short, a particular machine that joined the cluster that morning had some kind of CPU or memory flaw that flipped a bit sometimes. Our Elixir server was fine because we were matching on valid values. Imagine a typed language compiler that makes assumptions about things that "can't" happen because the code says it can't... yet it does.
You get zero help and punished hard for failing.
I don't want to look at TIOBE, so let's look at the stack overflow survey from 2024. https://survey.stackoverflow.co/2024/technology#admired-and-...
Strong + Static: TypeScript, Java, C#, C++, Go, Rust, Kotlin, Dart, Swift, Visual Basic, Scala
Weak + Static: C
Strong + Dynamic: Python, Lua, Ruby, R, GDScript(*)
Weak + Dynamic: JavaScript, PHP, Matlab, Perl
At this point I'm reaching into the low percentages. I think it's pretty clear that Strongly + Statically typed languages are massively over-represented on the list.
Both Strongly and Weakly Dynamically typed languages are similarly represented.
Note: I'm open to editing the comment to move languages from and to various categories. I haven't used many of them, so correct me if I'm wrong.
Sure, Smalltalk isn't, but Lisp is a different story. In this context I assume we all mean to say "Lisp" and not "Common Lisp" specifically.
Lisp (as the entire family of PLs) is quite massively popular.
Standard rankings have major blind spots for Lisp measurement, they miss things like, for example, Emacs Lisp is everywhere. There's tons of Elisp on GitHub alone, and let me remind you, it's not a "general-purpose" language, its sole function is to be used to configure a text editor and there's mind-boggling amount of it out there. AutoLISP is heavily used in CAD/engineering but rarely discussed online. Many Lisp codebases are proprietary/internal. Also, dialect fragmentation artificially deflates numbers when measured separately - many rankings consider them different languages.
If you count all Lisp dialects together and include: Emacs Lisp codebases, AutoLISP scripts in engineering, Research/academic usage, Embedded Lisps in applications, Clojure on JVM and other platforms - babashka scripts, Flutter apps, Clojurescript web apps, etc;
...Lisp would likely rank much higher than typical surveys suggest - possibly in the top ten by actual lines of code in active use.
not anymore. they were very popular in the industry at one point. very few other languages have so many independent implementations as smalltalk and lisp. a testament to their wide spread use in the past.
Strong + Static: TypeScript; Weak + Dynamic: JavaScript
that doesn't make sense. typescript is javascript with types, it can't be both strong and weak at the same time.
but i believe we have a different definition of weak. just because javascript, php and perl have some implicit type conversions doesn't make them weakly typed. i believe it takes more than that. (in particular that you can't tell the type by looking at a value, and that you can use a value as one or another type without any conversion at all)
C is weakly typed, it was always a major criticism, C++ too i think (less sure about that).
once you correct for that you will notice that all languages in the strong and static category are less than 30 years old and many are much younger. (java being the oldest. but there are older ones like pike which is also strong and static and goes back to 1991)
the strong and dynamic category goes back at least a decade more. (if you include smalltalk and lisp)
what this does show is that static typing has experienced a renaissance in the last two decades, and also the worst is really using any form of weak typing.
i still don't get what makes strong and dynamic a bad combination, other than it's bad because it is not static.
I know that there are discussion about what strong vs weak even means, but I think most people would place the weak distinction way above yours on a possible weak-strong spectrum.
C can certainly be argued to be weak. My understanding is that it's mostly due to pointers (and void* especially). C++ is much better in this regard. I mostly just did not want to add a Weak + Static category just for one language.
Well, now that you've defined Strong to also include all of the languages I consider Weak, then yeah, no issues at all.
Log lines are whatever, but a system that goes into a crash loop or fails on most requests isn't great.
This is what Erlang has and it’s very convenient since once a design is fixed, I end up writing a spec to remind me what types the function expects.
[1] = https://www.erlang.org/doc/system/typespec.html
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.
Erlang knowledge is not needed for building products with Elixir at all unless you want to go very in-depth.
I don't think it's really impeded my ability to learn or use Elixir. But I could also see how learning it and the underpinnings for Elixir could aid understanding too.
Learning the concepts that embody Erlang such as tail recursion and function matching, make Erlang worth learning. Erlang is also a special mix of Prolog and Lisp.
For me Erlang was worth learning because it's so interestingly different to many other languages because of its Prolog roots.
You don't need to learn OTP at first either — it'll just slow you down and confuse you. Learn Elixir syntax and semantics, learn how to build a Phoenix app or whatever, then dive into OTP once you're comfortable with the basics.
I picked up Joe's Erlang book years after out of pure joy/curiosity.
Especially with LLMs, totally unnecessary.
Still, every release now contains new type system features. Next up is full type inference. [2] After that will be typed structs.
[1] José Valim giving his balanced view on type systems: https://www.youtube.com/watch?v=giYbq4HmfGA
[2] https://hexdocs.pm/elixir/main/changelog.html
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! :)
YMMV, but I think it writes fine unit tests, but really sub par functional or end to end tests that need to check business logic. I think that's just a hard case for LLMS and not an elixir issue though.
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
if using elixir supposedly gives a competitive advantage, why aren't companies using to launch new products - both existing and startups.
a lot of those things quoted in the article are present on the jvm platform or through containers.
and btw some of those companies listed have migrated away from elixir e.g brex and discord.
A while back there was an effort to give more publicity on precise cases here https://elixir-lang.org/cases.html ; I think the effort is now moving to advertising the platform outside Elixir circles (e.g. more generalist conferences).
FWIW, I'm working on https://transport.data.gouv.fr, Elixir-based since 2016, the National Access Point to transportation data, which includes a business specific reverse proxy with a 3x YoY growth, with no plans to migrate :-)
Tools like Elixir which are focused on solving problems, aren’t flashy or easy for web dev influencers (yes, they’re a thing) to tout, and have a bit of higher barrier to entry are probably at a disadvantage in this way, even if they’re actually quite good.
This is why the industry is stuck on a revolving door of JS frameworks and the n-hundreth React self-reinvention. It’s not about how good any of this actually is, it’s about how well it scratches the itch for that new car smell while also being easy to pick up and make grand declarations on social media about.
to learn what? that the language was not good enough? that it wasn't marketed well enough? that there was not enough community support? not enough word of mouth?
lisp users say they have a competitive advantage, as do smalltalk users. even pike at a time had a competitive advantage in that it was/is more performant than other similar languages.
some of us in the pike community kept asking ourselves why pike is not more popular. the syntax is not obscure. roxen was a killer webdev server, 10 years ahead of its time. but no takers. why? (probably a mix of lack of marketing and community support/encouragement from the financial backers, but other languages become popular without backing, so what gives?)
my point is that most times there is nothing you can do. unless you have the marketing power of sun (java) or google (go, etc), popularity of a language is mostly a case of luck and serendipity (ruby, python) or filling a unique need that no other language could (javascript, rust)
Elixir also does not stand alone - the storied history of Erlang/BEAM in mission-critical distributed systems needs no introduction. Elixir lives within, and benefits from, that same ecosystem of libraries and tools.
So yeah I'm not sure what you believe there is to "introspect" about, nor to what end.
And no, Discord has not moved away from Elixir. While they have adopted Rust for certain parts of their infrastructure, Elixir remains a core part of their backend, particularly for real-time communication and chat infrastructure.
Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly.
This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.
If you don't know Elixir and the BEAM well, of course you're going to have a bad time. That's true of any language.
> what happens when the server restarts / connection is lost / server dies?
> you lose all of the current client state but you can work around this by persisting all the client state somewhere.
> oh, so why am i using live view again?
Not exactly, it's built to hold state in memory by default but doesn't assume how you want to handle deploys or server restarts. There's a built in restore mechanism for forms and it's trivial to shuffle state off to either the client/redis/your db[1]. You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice. Or you conversely have the problem that refreshing the page trashes client state.
So there are two thinks here, you don't have to use live_view to use elixir or phoenix, and if you do you just need to actually think about how you're solving problems. The state can get trashed anywhere for any number of reasons. Tossing on the client and forgetting about it just moves the problem.
[1] https://hexdocs.pm/phoenix_live_view/deployments.html
https://hexdocs.pm/phoenix_live_view/form-bindings.html#reco...
Erlang is low level, lightweight processes and message passing - perfect for micro-services and containerisation.
What Erlang lacks are high level web-oriented packages, i.e. markdown conversion, CSS and JavaScript packaging, REST (not quite true: cowboy is fantastic) - for which though Erlang was never intended.
However the cool thing is that you can combine both in the same project, allowing you to have high level Elixir and low-level process management in one project. This is possible because both use the same virtual machine - BEAM.
If I were starting a new company today though I'd probably go with Elixir, and then I simply wouldn't bother with containers, Kubernetes, and schedulers. Just run some servers and run the application on them, let them cluster, and generally lean into the advantages.
For example, the Erlang VM clustering can make use of K8s for Service Discovery. You can do ephemeral containers and use readiness probes to create a " hand over" period where new instances can sync their data from old, about-to-be-replaced instances.
So it’s not a feature specific to Elixir since the BEAM is the common virtual machine.
Elixir abstracts that away and leaves a ruby-like language that hides much away - which good and fine.
Erlang is by no means a simple language to get one’s head around.
So like a thin mirror? Which only serves to show the viewer back to themselves? And which also consists of just two extremely simple parts, that is, two panes/sheets of uniform materials, and nothing more?
How do you even come up with this metaphor for a web-based application? It's horrible!
Talking about stuff like this:
I decided to learn Clojure for my next language.
No, you're not alone. After learning Lisp, structural editing and REPL-driven-development, I just don't feel like needing to learn new languages no matter how powerful they seem to be. Lisps like Clojure are highly pragmatic and offer something fundamentally different from the endless parade of syntax-heavy languages that dominate the mainstream.
Once you've experienced the fluidity of paredit or parinfer, where you're editing the structure of your code rather than wrestling with textual representations, going back to manually balancing brackets, fixing indetnation and carefully placing semicolons feels like reverting to a typewriter after using a word processor. The code becomes malleable in a way that's hard to appreciate until you've lived with it.
And the REPL changes everything about how you think and work. Instead of the write-compile-run-debug cycle, you're having a conversation with your running program. You can poke at functions, test hypotheses, build up solutions incrementally, and see immediate feedback. It's exploratory programming in the truest sense - you're not just writing code, you're discovering it.
The homoiconicity - code as data - means you're working in a language that can easily reason about and transform itself. Macros aren't just text substitution; they're proper AST transformations. This gives you a kind of expressive power that most languages can't match without tremendous complexity.
So when the latest trendy language appears with its new syntax and novel features, it often feels like rearranging deck furniture. Sure, it might have nice type inference or clever concurrency primitives, but you're still stuck in the old paradigm of fighting syntax and losing the conversational flow of development.
You've tasted something closer to the pure essence of computation, and it's hard to go back.
i am interested in clojure, but i am put off by it using the java run time. ;-)
Clojure runs not only on Java - you have Clojurescript, you have babashka and nbb, you have Clojure-Dart — if interested in building Flutter apps, you can even use Clojure with Python libs. If you need to target Lua, there's Fennel, which is similar as it's inspired by Clojure.
For me - Clojure is a hands-down best medium for data manipulation - there's just nothing better out there to explore some data - investigate APIs; sort, group, dice and slice any kind of data - CSVs, JSON, etc. Nothing else simply can match the joy how one could incrementally build up complex data transformations, it makes it incredibly productive for the "let me just quickly check this shit" scenarios that can easily turn into full analyses. REPL-driven nature of it makes it so much fun - you feel like you're playing a videogame.
I honestly wish every programmer knew at least some Clojure. I lost count of how many times I gave up on figuring out complex jq syntax and reached for Clojure instead. Or the times I'd quickly build a simple Playwright script for reproducible web-app bug trapping or quick data scraping that saved me hours of frustration and manual clicking.
Fennel -> Lua
Jank -> C++