> killer feature is IEX, Elixir's REPL

Don't many other languages have this? Ruby has IRB for example. Is there anything IEX does that IRB doesn't?

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].

[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

This was possible with various flavors of Pry and DRB once upon a time.

Not just a running server, you can hook into a running cluster and do such things.

The Observer, :observer.start(), is another very nice tool. Might require some widget libraries for the GUI but you'll likely have set that up on the machine you're doing the introspection from.

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.

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.

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.

[1] https://native.live/

website comes last

That is sad to hear. Spending even just thirty minutes on the website to better communicate what one can/cannot do would go a long way.

In any case, thank you for your work.

Completely agree here. It would probably save time just having to explain timeline/status here, forum, etc.

Already sold. Just waiting for updates on production-readiness and Android support.

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 ;)

Yeah, I considered adding a caveat to my post. The LISP repl experience is of course the real gold standard (especially when you've got good editor integration, like the various Emacs packages).

I love LISP in general - was a big Clojure fan for a while - but I feel like Elixir threads the needle of usability much better for me.

Anyway, I'll stand by my claim - Elixir's REPL is leaps and bounds better than Python's, and better than irb and pry by some smaller amount. It's a pleasure to use. I would love to see a world where I can send expressions for evaluation to the REPL as easily as you can with LISP. Maybe we'll get there someday!

You are forgetting WebRTC with Membrane...

Don't forget:

- 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.

Now the only thing left: figuring out how to deploy it.

it's pretty straightforward and simple with `mix release`

I remember trying to deploy it a couple years ago and it was fairly complicated. Granted, I was trying to deploy a multi-node mnesia cluster, which is probably what caused all my issues.

But for non-production single nodes I just created a Dockerfile and deployed it because the other options were too much hassle. Can't remember the details, but in my (in)experience, deploying was always the hard part with Elixir.

I will need to try it again, it's been a while and the ecosystem has improved dramatically in the meantime ... and it was already excellent before. Good stuff!

My view on Elixir deployment is that for a given complexity of setup, it's no harder than anything else. For a basic single node webserver, `mix release` makes it like releasing anything else (often more easily). For complex multi-node setups, yes there's some hard work to do, just like there with on any other platform. The difference is that the development experience of getting to a working stable multi-node setup is so much easier on Elixir than anything else that you notice the difficult deployment more.

> 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. :-(

Go back? Have you ever worked on a significant project in either Erlang or Elixir? If so, what issues did you experience?

This was meant for the statical typesystem. I've worked without statical typesystem in other languages, yes. (never professionally on the BEAM though)

This seems to be the case for 99% of people I've noticed worrying about types for Elixir.

I've worked with a wide spectrum of type systems and none of the things that caused issues for me due to typing in large JS or Ruby projects ever did in Elixir. The schema-based structs and pattern-matching make a huge difference. I don't feel quite as confident of a poorly tested Elixir code base as one written in Rust, but I'd take it over one written in TypeScript or Obj-C any day of the week.

This is my experience too. Elixir's lack of static types never caused me nearly as many problems as they have in other languages; it's surprising how little I've missed a static type system. I wrote about it here:

https://phoenixonrails.com/blog/you-might-not-need-gradual-t...

Ah, yes. You pointed out immutability in that post, which also makes a significant difference!

Have you ever worked in a language where pretty much everything is immutable AND you have a very powerful static typesystem though? (so not Java and also not Rust).

If not, maybe it's hard to understand where I come from. On top of that, people are different. Maybe Elixir is the right thing for you, but still not for me as I'm more prone to typos and such kind of small errors.

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.

> 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

We did and it was a lot of work. We had to maintain 5-6 libraries ourselves instead of using one maintained by the services themselves. We had to fork libraries because they became abandoned.

Elixir has been around for 12 years now and still hasn't gained any meaningful traction.

The risk of using Elixir vastly out ways the benefits today if you are trying to build a product.

There is a reason why almost every product today is built using JS and Python because it easy to find developers, it's easy to find everything you need, almost every service supports it and there are tons of resources for it.

We switched for Elixir to JS and we only have to maintain the app itself. We have hundreds of OSS helping maintain the libraries we use most of them working for companies that the libraries are for. That's the massive advantage of using popular languages that everyone uses.

Elixir is a fun language but that's about it.

Million+ concurrent users per server - Discord are certainly having fun.

All while having so few employees. I don't blindly copy discord, but I pay attention to most things they do engineering wise. IIRC they have like 2 people working on the mobile app. It's insane, and I think a great story for those that want to start small and stay small.

NPM is anything but fun, I’ve seen tertiary dependencies cause complete application failures due to bad patch version releases.

Packages depending on packages not maintained or containing security issues.

I don’t know how many times Next has released broken updates without any mention of it in their change log and then you find a GH issue where it’s essentially “works on vercel hosting”…

Easy to find developers is often touted as a plus, but the process for making sure you get the right ones are scarce, and JS code bases almost always ends up as complete spaghetti as a result. As someone doing JavaScript for a very long time my statement is that it’s one of the hardest ecosystems to get right and it requires exceptional developers to do so, unfortunately it’s also where many start their journey and without exposure to other technologies becoming great at it is very hard.

The fact that I can do `mix hex.outdated` and get a code diff on dependency changes makes me smile every time, compared to the insanity that is updating npm packages in any sizeable project with hundreds of updates weekly.

I don't fully agree with your statement. We had used Scala around the time the devs were playing around with dotty. I loved many features of the language (compile times were painful, but the language itself was fun). But we had to stay back because a specific db dependency did not resolve well with later versions of Scala (2.13 it broke).

Similar thing recently, there was an obscure Scala version mismatch error when trying to use it with spark. (Not that significant of a problem).

It is definitely a headache trying to cope with the conditions till we get better especially with smaller teams who can't afford to fork and maintain something. A

Honestly I don’t see it as such an issue.

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.

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.

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.

A little demo https://youtu.be/WnBaMcH5AoY?si=ywFzQuCPp41l3MBF