Why Elixir? Common misconceptions

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.

> Maybe I'm just wrong

Yes you are. First of all there isn't such a thing as "strict typing", types are either static/dynamic and/or strong/weak. I suppose you meant Elixir has no static types. It is however a strongly typed language.

And just like it usually happens, static typing enthusiasts often miss several key insights when confronting dynamically typed languages like Clojure or Elixir (which was inspired by ideas implemented in Clojure).

It's not simply "white" and "black", just like everything else in the natural world.

You have to address:

- Runtime flexibility vs. compile-time safety trade-offs — like most things, things have a price to it, nothing is free.

- Different error handling philosophies. Sometimes, designing systems that gracefully handle and recover from runtime failures makes far more resilient software.

- Expressiveness benefits. Dynamic typing often enables more concise, polymorphic code.

- Testing culture differences. Dynamic languages often foster stronger testing practices as comprehensive test suites often provide confidence comparable to and even exceeding static type checking.

- Metaprogramming power. Macros and runtime introspection enable powerful abstractions that can be difficult in statically typed languages.

- Gradual typing possibilities. There are things you can do in Clojure spec that are far more difficult to achieve even in systems like Liquid Haskell or other advanced static type systems.

The bottom line: There are only two absolutely guaranteed ways to build bug-free, resilient, maintainable software. Two. And they are not static vs. dynamic typing. Two ways. Thing is - we humans have yet to discover either of those two.

Well written typespecs + dialyzer catches most things you’d want to catch with a type system: https://hexdocs.pm/elixir/typespecs.html

There is also pattern matching and guard clauses so you can write something like:

def add(a, b) when is_integer(a) and is_integer(b), do: a + b

def add(_, _), do: :error

It’s up to personal preference and the exact context if you want a fall through case like this. Could also have it raise an error if that is preferred. Not including the fallback case will cause an error if the conditions aren’t met for values passed to the function.

It's not so bad in Elixir for various reasons. Firstly, they're doing some work on set-theoretic types.

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.

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.

Maybe try Gleam? 80% of the goodies of Elixir is the BEAM anyway and you get that in Gleam too.

I believe you meant static typing. There's active ongoing work in this space, and Elixir is actually gradually typed now. You can read more about it in the docs: https://hexdocs.pm/elixir/gradual-set-theoretic-types.html

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!

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.

If I didn't need native functionality, I'd probably just use the recently released `phoenix_vite`: https://github.com/LostKobrakai/phoenix_vite

Something like https://github.com/mrdotb/live_react might be what you're looking for.

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.

Any thoughts on Inertia for including React into the picture?

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.

i understand, but i am not familiar with how one allocates hosts to create a cluster of beam instances across which elixir/gleam apps are running.

is there a popular pattern, perhaps as used by whatsapp, i guess?

This language and its upsides (that come from the VM) really are not for application development in this manner. I'm sure you can make it work somehow but its like using a tank to get groceries. Reliability, scalability, aren't concepts relevant to apps on mobile phones. If an app crashes to the homescreen thats fine, if your entire service goes down that's another. Would be fun if someone could prove me super wrong here but if you want to learn Erlang/Elixir/Gleam or anything BEAM I'd pick a backend project.

The continued lack of DOM access from wasm is keeping a lot of potential programming languages out of this space.

Uh, yeah, it's primarily a backend language, with any frontend stuff being either a thin layer or experimental, AFAICT. OTOH, doing a more traditional backend-heavy web app might be just the thing for JS fatigue. :)

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

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.

Yes, it is worth it to learn Elixir without learning Erlang, absolutely.

~5 year pro elixir here, various systems in production, I don't know any erlang.

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.

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.

You don't need to learn Erlang first.

You can get very very far in Elixir without even knowing about an acronym called OTP.

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.

[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

Pattern matching makes up for the lack of static typing for me. Combined with guard clauses it feels even stronger than static typing.

They are working on a type system.

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.

Ya, it one shotted a Server driven ui app using elixir backend, expo with phoenix channels. Was impressed.

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

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

Yeah, that’s a fair point.