[mrspeaker]

Could someone give a more concise reason for using Elixir? I have a "rule of 3" for checking out things - the third time I hear it mentioned and it seems interesting, then I'll go check it out.

Elixir is past 3 times - so I will check it out for sure! - but this article didn't seem to actually say anything (seemed more like a PR piece that was trying not to be technical, and the main argument appeared to be "well, it's not javascript!").

The part that actually talked about Elixir listed some Pros that didn't seem that unique. What's the "killer feature" of Elixir - or is it just a combination of "good features"?

[latch]

It's the synergy between the language, the runtime and the standard library to deliver the actor model.

Elixir "threads" are called "processes". It's a bit confusing at first, but there's a good reason for it. So from hereon in, when I say "process" think "thread".

Elixir processes, like OS processes, are fully isolated from each other. If Process A has data than Process B wants, Process A has to ask it (send it a message) and can only get a copy of the data (like real OS processes, hence why the name makes sense). The advantage to this is that data ownership is explicit, race conditions are eliminated, and code is less coupled (A can't have a reference to an object that points to B that points to C..., that anyone anywhere in the code can mutate).

At a high level, this allows you to get many of the benefits of microservices, without the high cost (deployment complexity, service discovery, lower performance).

We run an analytics on live sports which does various transformation on a stream of play by play data. There are very distinct features: boxscores, lineups, scores, time alignment, broadcast information...For each live game we start a process for each of these features. When a play by play event comes it, we pass that to each worker of the appropriate game, and each worker does its own thing.

The workers are isolated. Not just the physical code, but at runtime. This makes them easier to test, refactor and grasp.

There's some interaction between the workers. For example our boxscore worker needs to know the score at a given time. So it sends a message to the score worker for that game: {:get, time}. The score worker replies with the score. There's no need for explicit locking. A process handles a message at a time. There's no chance that the boxscore worker changes the score worker's data (it can change the copy of the data that it got, but that change is only on the copy).

Really, it's most of the benefits of microservices (and I mean, being able to have true MICROservices, not just rebranded SOA) with few of the downsides.

[pmarreck]

Spotted the BleacherReport guy (...I think!) ;)

[latch]

Nope. I work at https://www.secondspectrum.com/

[bicx]

I think the real killer feature of Elixir is that it is a friendly, Ruby-like language that gives you access to the underlying power of Erlang/OTP on the Beam VM.

OTP (Open Telecom Platform) is a set of tools, libraries, and middleware that was built around Erlang. This has been in development since the 90s, and was originally developed by Ericsson for the telecom industry to handle massive numbers of concurrent connections without a single point of failure (I may be butchering this story, but this was the end result). OTP includes things like extremely lightweight processes, process supervision to quickly restart based on your desired behavior, multiple native real-time datastore options (both in-memory and/or persistent), hot deployments with no downtime, an extensive standard library, and other cool things that have stood the test of time. All of this just comes with the base Erlang/OTP installation.

Elixir essentially introduces a modern ecosystem around the Erlang/OTP system.

[PopeDotNinja]

>> I think the real killer feature of Elixir is that it is a friendly, Ruby-like language

Elixir looks a little like Ruby, but that's where I'd end the comparison. There's almost know similarity in how can be used well.

[bicx]

True in a lot of cases. However, Phoenix has major similarities to Ruby on Rails, and Elixir is often the functional language of choice for those moving away from RoR.

[andy_ppp]

I would say it's about developer happiness while coding and that all the decisions made by Jose and the core team tend to have been the correct decision. So taking Phoenix as an example you look at the framework and every time they find a problem i.e. Presence instead of saying that's a difficult problem and moving on they fix said problem in a really scalable way [1].

The same could be said for things like data processing with Flow [2] or even things like Ecto (semi official database wrapper) or even third party libraries like say ex_money [3].

Then you start looking at the packages and language and see that there are rarely thousands of bugs or that the infrastructure (mix, hex, docs etc.) is really nice to use and that the language is really stable, yet still provides you with useful but clear abstractions. Or that you can spin off processes and tasks inline without too much worry, or that you can use 20+ years of Erlang libs transparently, or that it's immutable and has the best concurrency primitives of any system available, or that it allow you to supervise processes and let them crash if needed without bringing down your app, or that you can transparently get multi machine out of the box, or that message passing is build in as the default way to scale the system. Or pattern matching or |> or the amazing community.

[1] https://phoenixframework.org/blog/the-road-to-2-million-webs... and https://dockyard.com/blog/2016/03/25/what-makes-phoenix-pres...

[2] https://www.youtube.com/watch?v=XPlXNUXmcgE

[3] https://github.com/kipcole9/money

[pmontra]

Actually Ecto is the most unhappy part of the Elixir ecosystem to me. It's unnecessarily complicated for almost any software project. I'd even take Django's ORM instead of it, but what I want is something close to ActiveRecord. There are some Elixir modules similar to AR, none popular.

[josevalim]

It is tragically funny how many people like and how many people dislike Ecto. :) I guess that's "ORM"s in a nutshell? Which is totally fine, of course!

[1_player]

Ecto is not an ORM, and an ORM like ActiveRecord would never fit a functional, immutable language anyway. Ecto is a query builder and DSL.

But I may be biased, I _love_ Ecto and have been using it every day for the past year, and have never come across something as powerful yet lightweight (perhaps SQLAlchemy, ignoring its ORM features).

[fcbrooklyn]

The real "killer feature" is the Erlang VM (the BEAM). Thanks to a combination of exceptionally lightweight "processes" (not true OS processes, a construct of the VM), which share nothing, can only interact through message passing, and which can be supervised by other processes, it's possible to build incredibly robust systems.

Elixir makes the Erlang VM much more pleasant to use in my opinion (plenty of Erlangers will disagree with this, ymmv). It provides a developer-friendly, modern ecosystem, with doc support, testing support, a great macro language for building DSLs, package management, etc, but underlying it all is a battle-tested VM, that has been under active development for 30 years.

[dlkinney]

It is an ergonomic language built on top of a stable, performant, proven runtime with a lot of features built-in.

It's a nice ecosystem with a good culture in a language that promotes pretty good programming practices.

The only major downsides (if they even are for you) are that it's dynamic--not good for number crunching, though you can connect to compiled binaries--and is not strongly typed--which can lead to runtime bugs.

That said, part of the philosophy is to enable fast failure without taking down the whole application. In communications, it's not considered the end of the world to drop or fail on one connection, so it works well for web services, chat, etc.

[pmontra]

Killer feature: pattern matching mixed with destructuring.

Bonus: parallelism almost for free.

If only GenServers had a sensible interface instead of semi random handle_* functions that obfuscate what a given GenServer is implementing.

[johnchristopher]

I am not into Python so I assumed it was the python db thingie.