The last few years the Elixir ecosystem has started to become the simplest solution to so many use cases:
- Web development with Phoenix and Liveview is immensely enjoyable and fast
- AI with NX, Axon, Bumblebee
- Audio and Video streaming and manipulation with Membrane
- CQRS and Event Sourcing with Commanded
- Embedded with Nerves to make your own devices
- Mobile apps with Liveview Native ( in development )
- Queues, pipelines and batch processing, etc... natively or with GenStage, Broadway or Oban depending on your use case
but for me, the killer feature is IEX, Elixir's REPL. Being able to interact directly with my running code easily ( in dev or in production ), introspect it, debugging it, is just life changing.
Adding types is indeed the last piece to the puzzle to bring even more confidence in the code we ship.
- FLAME for the ability to scale different processes to different computers with nearly 1 line of code (the whole library itself is just a few hundred LoC if I remember)
- Ecto for interacting with SQL databases in a functional manner (I still never know how to feel about ORMs, but I was able to write a few composable queries and get rid of 90% of my SQL, so I'll call that a win)
After months of struggling with deployments, uptimes, segfaults, package times, etc I moved my webserver & data layer over to Elixir + Phoenix. It's more well tested than ever, so much easier to reason about, I trust it will scale, and deployment was a breeze.
Because of convention over configuration, I was able to get up and running _insanely_ quickly with Phoenix (way more than FastAPI). I really wish I did this months ago.
Now I'm training models in Nx, playing around with Bumblebee/Livebooks, and adding presence/live functionality to my app for nearly free.
I'll take the opportunity for a shameless plug on LiveView Native. In addition to mobile apps we can also build for desktop, watch, TV, and even Apple Vision Pro. All using LiveView concepts, performance, and ease of development.
Hi Brian, thanks for all effort put into LiveView Native.
Quick suggestion, it would be nice if the landing page [1] has more information or links to actual examples of how to use LiveView Native. That page has not been updated in a long time and give the (misleading) impression that the project is on hold.
> Adding types is indeed the last piece to the puzzle to bring even more confidence in the code we ship.
This is the hard missing piece for me and why I'm looking curiously over to Gleam. Coming from a language with a very powerful and useful statical typesystem, I just can never go back to something like Erlang or Elixir in my life. :-(
The Elixir REPL is world-class, and I agree that it's a truly killer feature of the language. I miss it terribly when I write stuff in other languages (i.e. any time I'm coding, you know, for money).
Having a good REPL just removes so much of the friction you normally have to contend with in programming. You can build up ideas piecewise and test things as you go, instead of having to make guesses and run the whole damn app just to poke some troublesome piece of code. The Elixir standard library is great, and it's extremely easy to access the docs via the REPL, which I find really helps me stay in the flow. When I'm coding in Elixir, popping over to a browser window to search small questions is pretty rare, because I can usually find the answer without leaving the REPL. This also encourages me to write good docstrings for my own code!
But it gets even better, because you can run the REPL while also running your code. I mentioned above having to "run the whole app to poke a piece of code" - when you find yourself needing to run the app, you're welcome to, and you can manipulate live data (in dev, of course ;) ) and inspect what's going on in ways that you either can't do or need a debugger for in other stacks. And now, with the introduction of some typing facilities, I expect the tools to get even better.
Then there's all the fun and power of the functional paradigm while still having extremely robust ways to deal with mutability and state, and not having to deal with the syntax of LISP (sorry LISP). It's a language that just hits every note for me, I'm a huge fan.
Recently moved my python app over to Elixir, and currently gushing over Elixir every day. I'm a huge fan and have loved everything about it, except...
Comping from a LISP, the Elixir REPL really is not world-class. It's a really far, distant second. It's nice, I enjoy it more than python's personally, and more than what I remember from irb back in the day -- but nothing beats the integration of structural editing and nREPLs.
LISP doesn't have to be for you, but there's still a lot to learn from that REPL experience if the Elixir community wants to grow ;)
The cool thing is that you can, with the BEAM, connect your shell[0] to a running server and use something like recon_trace[1] to watch functions as they’re getting called. The same principle is used for libraries like this distributed profiler so you can watch the aggregate performance of your application[2].
Beam/OTP has a lot of tools for understanding the runtime state of the system. And you can attach the REPL to an existing, already running instance.
As with many things Elixir/Erlang related, there isn't a lot that's unique and not seen anywhere else. It's more that the pieces are carefully thought through and come together to make a fantastic whole.
Personally, I prefer iex over irb, iex feels more intuitive. Recently, some improvements were made into iex, the most relevant to me is the ability to use Ctrl+l to clean the output. Now, iex is getting closer to ipython.
When you use Elixir you have to go into it knowing you might have to end up maintaining any library you are using because the vast majority of Elixir libraries are abandoned.
You have to search through libraries to find out which one is being maintained.
For example if you want to use an OpenAI API client, you wouldn't want to use the most starred one because that hasn't been maintained in 7 months.
If you just use Python you get to use the one maintained by OpenAI. Using a language like Python, JS, Go ect. you almost never run into this problem because libraries are usually maintained and aren't abandoned and if they are there are usually enough users that a fork appears.
So yeah Elixir has great uses, but is it worth the possible future headaches of having to maintain a bunch of libraries to get your app going? Instead of using Go, Python, JS ect where you can rely on a massive community
Very very few companies build and maintain SDKs for Elixir.
For API clients it's hardly any work to write your own. Sure large communities have more off the shelf options but those options are also more likely to go out of vogue.
NIFs and small services can often fill the gap if really needed.
> Very very few companies build and maintain SDKs for Elixir.
This is true with any tech until it gets traction. React/Next is backed by a big company, but Vue/Nuxt still managed to grab its piece of the pie.
In order to get traction Erlang / Elixir needs enthusiasts who are ok with risking and introducing it to their company or product, at least partially.
No offense, but instead of condemning the Elixir ecosystem, why not embrace it in your company or product, as many have done (including me)?
I think most devs should be OK with taking a tolerable risk if they see opportunity to increase productivity by N times
Recently live development capabilities were added to Ruby as well, thanks to latest patches to inf-ruby, now it's possible to eval code around the breakpoint and in the global context as well, everything available right under cursor.
Elixir and Erlang teams are absolutely killing it over the last few years, not to mention all the work done by the library and book authors out there.
I've never been more excited about a release. I've been watching commits to both Elixir and OTP for awhile now and I feel Elixir/Erlang has really picked up steam.
Thanks to everyone involved for making my life easier!
I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience.
I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even without LiveView and realtime/channels, just using Elixir as a backend for a simple API has been really fun.
I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software.
I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].)
In fact, the fact that the above sentence has zero meaning to a new-to-phoenix-and-liveview dev is proof enough to me that liveview should not be the default way of doing things.
It creates a very steep learning curve where, crucially none is required. elixir/phoenix are easy.
I would even say that the correct learning order for a new-to-elixir/phoenix dev should be:
- Phoenix with deadviews (MVC style).
- "Elixir in action" to learn the basics of OTP. This book is was both easy and utterly eye-opening to me and changed the way I code basically everything.
Thanks for the link. This is my fault because the sentence is ambiguous. Where it tries to explain that "you need to remember to perform auth checks both", it rather means that you need to protect controller routes and LiveView routes the same way, but for a single LiveView, you don't need to do both. I will try to clarify it!
If you have other footguns in mind, feel to shot me an email at jose dot valim on gmail!
I've been having a similar experience trying to build an app with liveview. I've been simultaneously building the same app with Phoenix + LiveView and Dream (OCaml) + HTMX. With the OCaml stack I'm finding it really easy to follow the data flow through the whole app thanks to the compiler. With the Phoenix app I'm struggling to internalise how all the code fits together and having to navigate the code base off searching for strings alone (vscode editor tooling seems to just not work for me?). I'm also struggling to grasp how state is stored in a liveview and it isn't helped that a lot of the resources I've found online are now out of date. Going with a simpler approach of MVC sounds promising - I do want to get to the point where I'm actually taking advantage of the BEAM (I'm aiming for long running processes + user interactivity + maybe multi-user editing).
I'd be keen to hear your development workflow for building an MVC style app, what you use for the front end, and how you go about refactoring, e.g. when editing a struct which is stored in the DB and shown in a view is when I particularly feel like I'm flying blind.
Very re-assuring to find this opinion elsewhere. I am absolutely drowning in Liveview. So difficult to /really/ grok. I'm becoming more convinced that it just isn't worth the effort, especially considering the interface will glitch if the user drives through a tunnel.
Meanwhile deadviews + channels is /miles/ better than python/rails/laravel (imho).
I recently started a project and could have pushed for LiveView but knowing I would need very detailed and complex auth/auth which SUCK in Phoenix I went back to Symfony + VueJS&TS for some parts and I'm amazed how fast and productive I am.
Sure when I need to write a REST route + its consumer in the client I die a little because I know that's the part I could have avoided...
Yes, I totally get that (and have been doing that). My complaint/suggestion is more around the marketing and messaging. There is so much more to Elixir than LiveView!
There are a couple comments to you so far and both of them miss the point.
> decouple itself from LiveView in a sense in the __minds of developers__
This isn't a technical knowledge issue or if a given technology should be the default on install. Assuming I understand your original post correctly this is a mindset issue: too many people dismiss Elixir and the rest of the ecosystem because the first thing they think about is LiveView while ignoring the rest of the ecosystem and that's a shame, because it's much more than that... and I would agree with that point. Even Phoenix is more than LiveView.
It's possible to have solidly productive, cost effective Elixir applications not involving LiveView or even Phoenix for that matter. The choice of Elixir in the backend should be more common than it is, though I understand some of the conventional wisdom and fears that motivate other choices.
I've been building my startup 100% fullstack in elixir, and it's been the most wonderful technology I've ever worked with. I'm evangelising all my serious tech friends about how great it is.
Now it would be awesome if rabbitMQ and its client would run on OTP 27, would love to upgrade :(
A news aggregator (and premium news chatbot) that indexes and analyses around ~150.000 new articles a day (http://im.fo)
I'm absolutely certain the real time processing would be unfeasible in any other technology in terms of complexity and the minimal compute resources it's running on.
Modules like broadway, ash, oban, phoenix liveview ... make it not just a pleasure to work with but insanely performant.
With over 20 years of programming experience, I can say with certainty that there is no language that makes me as productive as elixir. It's at least 10x my python productivity (despite being at an expert level in python as well).
Can't say enough good things about Elixir and Phoenix. Now with types coming, it'll get even better.
By the way, you hear a lot about the BEAM and it's power - but in my experience you can go a LONG LONG LONG way before you ever have to even think about that part of your stack. Phoenix does such a tremendous job abstracting that for you. You just get the gainz with no effort. Other parts of the stack also just abstract that for you.
Case in point: Oban. You get powerful, flexible and easy to use background jobs for essentially free. Right there in Postgres, with your Elixir code. It's crazy.
I fully agree with you were it not for LiveView, which combined with the marketing obsession around LV, means people who could have glossed over OTP for a while longer are now confronted with it much earlier in their journey, possibly on their first controller route.
Writing robust LiveView flows, and testing them well, is exactly as intellectually complex as writing stateful genservers with multiple non-linear flows and various call/cast entry points. LVs use different jargon and have small convenience layers like async-assigns, but mechanically genservers are literally what they are. I'd say that's crucial to understand well if you want to use them effectively.
Aside note: Have any of you used elixir-desktop [1]? It is a wxWidgets + LiveView bundle, pretty much like a Electron app.
In [2], Wojtek Mach explains how the team behind Elixir build Livebook Desktop. He explains how the project started, some subtle bugs found when building the app for MacOS, some limitations of wxWidgets in Windows, and many other implementation details.
It would be awesome if the Elixir team releases something like elixir-desktop based on Livebook. That is, forking the Livebook repo and release an official template project for generating desktop applications based on LiveView. Right now, Livebook is distributed as an executable for Windows and Mac. Why not follow the same approach to allow developers to publish self-contained executables pretty much like Electron?
I am aware of LiveView Native [3] but I think they follow a different direction.
For 10 years I’ve been reading about cool Elixir stuff here. Love the language. I gave up on finding a job in Elixir many years ago though after seeing salaries consistently lower than more mainstream languages. It may be the language I’d want to use most, but salary and cool product are more important to me than tech stack so it may never happen. Still fun to follow from afar.
I keep an eye out in the US and there just aren't many of them out there.
And you have to be careful because some of those are
* "Bob wanted to try out Elixir, so now we use it for this one microservice, but we're mostly a PHP/Rails/Java/Python/whatever shop and we'd like to rewrite it one day, because Bob left a few years ago" - places where someone wanted to play with something shiny and new.
* Early stage firms where someone is a true believer that BEAM is some kind of magic scaling bullet or secret sauce.
Readit News
- Web development with Phoenix and Liveview is immensely enjoyable and fast
- AI with NX, Axon, Bumblebee
- Audio and Video streaming and manipulation with Membrane
- CQRS and Event Sourcing with Commanded
- Embedded with Nerves to make your own devices
- Mobile apps with Liveview Native ( in development )
- Queues, pipelines and batch processing, etc... natively or with GenStage, Broadway or Oban depending on your use case
but for me, the killer feature is IEX, Elixir's REPL. Being able to interact directly with my running code easily ( in dev or in production ), introspect it, debugging it, is just life changing.
Adding types is indeed the last piece to the puzzle to bring even more confidence in the code we ship.
- ExUnit for incredibly easy tests
- Hex package manager that just works
- FLAME for the ability to scale different processes to different computers with nearly 1 line of code (the whole library itself is just a few hundred LoC if I remember)
- Ecto for interacting with SQL databases in a functional manner (I still never know how to feel about ORMs, but I was able to write a few composable queries and get rid of 90% of my SQL, so I'll call that a win)
After months of struggling with deployments, uptimes, segfaults, package times, etc I moved my webserver & data layer over to Elixir + Phoenix. It's more well tested than ever, so much easier to reason about, I trust it will scale, and deployment was a breeze.
Because of convention over configuration, I was able to get up and running _insanely_ quickly with Phoenix (way more than FastAPI). I really wish I did this months ago.
Now I'm training models in Nx, playing around with Bumblebee/Livebooks, and adding presence/live functionality to my app for nearly free.
Quick suggestion, it would be nice if the landing page [1] has more information or links to actual examples of how to use LiveView Native. That page has not been updated in a long time and give the (misleading) impression that the project is on hold.
[1] https://native.live/
This is the hard missing piece for me and why I'm looking curiously over to Gleam. Coming from a language with a very powerful and useful statical typesystem, I just can never go back to something like Erlang or Elixir in my life. :-(
Having a good REPL just removes so much of the friction you normally have to contend with in programming. You can build up ideas piecewise and test things as you go, instead of having to make guesses and run the whole damn app just to poke some troublesome piece of code. The Elixir standard library is great, and it's extremely easy to access the docs via the REPL, which I find really helps me stay in the flow. When I'm coding in Elixir, popping over to a browser window to search small questions is pretty rare, because I can usually find the answer without leaving the REPL. This also encourages me to write good docstrings for my own code!
But it gets even better, because you can run the REPL while also running your code. I mentioned above having to "run the whole app to poke a piece of code" - when you find yourself needing to run the app, you're welcome to, and you can manipulate live data (in dev, of course ;) ) and inspect what's going on in ways that you either can't do or need a debugger for in other stacks. And now, with the introduction of some typing facilities, I expect the tools to get even better.
Then there's all the fun and power of the functional paradigm while still having extremely robust ways to deal with mutability and state, and not having to deal with the syntax of LISP (sorry LISP). It's a language that just hits every note for me, I'm a huge fan.
Comping from a LISP, the Elixir REPL really is not world-class. It's a really far, distant second. It's nice, I enjoy it more than python's personally, and more than what I remember from irb back in the day -- but nothing beats the integration of structural editing and nREPLs.
LISP doesn't have to be for you, but there's still a lot to learn from that REPL experience if the Elixir community wants to grow ;)
Don't many other languages have this? Ruby has IRB for example. Is there anything IEX does that IRB doesn't?
[0] https://hexdocs.pm/iex/1.12/IEx.html#module-remote-shells (the remsh flag)
[1] https://ferd.github.io/recon/recon_trace.html
[2] https://hexdocs.pm/orion/Orion.html
As with many things Elixir/Erlang related, there isn't a lot that's unique and not seen anywhere else. It's more that the pieces are carefully thought through and come together to make a fantastic whole.
You have to search through libraries to find out which one is being maintained.
For example if you want to use an OpenAI API client, you wouldn't want to use the most starred one because that hasn't been maintained in 7 months.
If you just use Python you get to use the one maintained by OpenAI. Using a language like Python, JS, Go ect. you almost never run into this problem because libraries are usually maintained and aren't abandoned and if they are there are usually enough users that a fork appears.
So yeah Elixir has great uses, but is it worth the possible future headaches of having to maintain a bunch of libraries to get your app going? Instead of using Go, Python, JS ect where you can rely on a massive community
Very very few companies build and maintain SDKs for Elixir.
NIFs and small services can often fill the gap if really needed.
If I had to use OpenAI API I would pick my favorite HTTP client and just use the Rest API and write a small wrapper around it for my needs.
This is true with any tech until it gets traction. React/Next is backed by a big company, but Vue/Nuxt still managed to grab its piece of the pie.
In order to get traction Erlang / Elixir needs enthusiasts who are ok with risking and introducing it to their company or product, at least partially.
No offense, but instead of condemning the Elixir ecosystem, why not embrace it in your company or product, as many have done (including me)? I think most devs should be OK with taking a tolerable risk if they see opportunity to increase productivity by N times
Dead Comment
I've never been more excited about a release. I've been watching commits to both Elixir and OTP for awhile now and I feel Elixir/Erlang has really picked up steam.
Thanks to everyone involved for making my life easier!
I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even without LiveView and realtime/channels, just using Elixir as a backend for a simple API has been really fun.
I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].)
In fact, the fact that the above sentence has zero meaning to a new-to-phoenix-and-liveview dev is proof enough to me that liveview should not be the default way of doing things.
It creates a very steep learning curve where, crucially none is required. elixir/phoenix are easy.
I would even say that the correct learning order for a new-to-elixir/phoenix dev should be:
- Phoenix with deadviews (MVC style).
- "Elixir in action" to learn the basics of OTP. This book is was both easy and utterly eye-opening to me and changed the way I code basically everything.
- Then, and only then, LiveView.
[0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
If you have other footguns in mind, feel to shot me an email at jose dot valim on gmail!
I'd be keen to hear your development workflow for building an MVC style app, what you use for the front end, and how you go about refactoring, e.g. when editing a struct which is stored in the DB and shown in a view is when I particularly feel like I'm flying blind.
Meanwhile deadviews + channels is /miles/ better than python/rails/laravel (imho).
Sure when I need to write a REST route + its consumer in the client I die a little because I know that's the part I could have avoided...
Saying this as a die hard Elixir fan who's been using it since 2015.
> decouple itself from LiveView in a sense in the __minds of developers__
This isn't a technical knowledge issue or if a given technology should be the default on install. Assuming I understand your original post correctly this is a mindset issue: too many people dismiss Elixir and the rest of the ecosystem because the first thing they think about is LiveView while ignoring the rest of the ecosystem and that's a shame, because it's much more than that... and I would agree with that point. Even Phoenix is more than LiveView.
It's possible to have solidly productive, cost effective Elixir applications not involving LiveView or even Phoenix for that matter. The choice of Elixir in the backend should be more common than it is, though I understand some of the conventional wisdom and fears that motivate other choices.
Now it would be awesome if rabbitMQ and its client would run on OTP 27, would love to upgrade :(
I'm absolutely certain the real time processing would be unfeasible in any other technology in terms of complexity and the minimal compute resources it's running on.
Modules like broadway, ash, oban, phoenix liveview ... make it not just a pleasure to work with but insanely performant.
With over 20 years of programming experience, I can say with certainty that there is no language that makes me as productive as elixir. It's at least 10x my python productivity (despite being at an expert level in python as well).
We've used the SSL cert client login method for years, and have been very happy with the reliability.
Cheers, =)
By the way, you hear a lot about the BEAM and it's power - but in my experience you can go a LONG LONG LONG way before you ever have to even think about that part of your stack. Phoenix does such a tremendous job abstracting that for you. You just get the gainz with no effort. Other parts of the stack also just abstract that for you.
Case in point: Oban. You get powerful, flexible and easy to use background jobs for essentially free. Right there in Postgres, with your Elixir code. It's crazy.
Try it.
Writing robust LiveView flows, and testing them well, is exactly as intellectually complex as writing stateful genservers with multiple non-linear flows and various call/cast entry points. LVs use different jargon and have small convenience layers like async-assigns, but mechanically genservers are literally what they are. I'd say that's crucial to understand well if you want to use them effectively.
Love Oban and miss it deeply in other ecosystems.
In [2], Wojtek Mach explains how the team behind Elixir build Livebook Desktop. He explains how the project started, some subtle bugs found when building the app for MacOS, some limitations of wxWidgets in Windows, and many other implementation details.
It would be awesome if the Elixir team releases something like elixir-desktop based on Livebook. That is, forking the Livebook repo and release an official template project for generating desktop applications based on LiveView. Right now, Livebook is distributed as an executable for Windows and Mac. Why not follow the same approach to allow developers to publish self-contained executables pretty much like Electron?
I am aware of LiveView Native [3] but I think they follow a different direction.
[1] https://github.com/elixir-desktop/desktop-example-app
[2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
[3] https://native.live/
That seems surprising to me as an Elixir developer. Are you looking in the US, or elsewhere?
And you have to be careful because some of those are
* "Bob wanted to try out Elixir, so now we use it for this one microservice, but we're mostly a PHP/Rails/Java/Python/whatever shop and we'd like to rewrite it one day, because Bob left a few years ago" - places where someone wanted to play with something shiny and new.
* Early stage firms where someone is a true believer that BEAM is some kind of magic scaling bullet or secret sauce.