
Elixir Is Erlang, not Ruby - stanislavb
https://preslav.me/2020/09/06/elixir-is-not-ruby-elixir-is-erlang/
======
latch
While I agree, the article doesn't really give concrete examples.

Elixir is layered, making it easy to learn and master. You can get pretty far
with Phoenix without ever understanding (or even knowing about) the more
fundamental building blocks or the runtime. In large part, this is because of
its ruby-inspired syntax. You'll have to adjust to immutability, but that's
pretty much it.

Then one day you'll want to share state between requests and you'll realize
that the immutability (which you're already comfortable with at this point)
goes beyond just local variables: it's strictly enforced by these things
called "processes". And you'll copy and paste a higher-level construct like an
Agent or Genserver and add the 1 line of code to this root supervisor that was
just a file auto-generated in your project. But that'll get you a) introduced
to the actor model and b) thinking about messaging while c) not ever worrying
about or messing up concurrency.

Then you'll want to do something with TCP or UDP and you'll see these same
patterns cohesively expressed between the runtime, the standard library and
the language.

Then you'll wan to do something distributed, and everything you've learnt
about single-node development becomes applicable to distributed systems.

Maybe the only part of Elixir which can get complicated are Macros /
metaprogramming. But you can get far without ever understanding this, and
Phoenix is so full of magic (which isn't a good thing), that by the time you
do need it, you'll certainly have peaked behind the covers once or twice.

The synergy between the runtime, standard library and language, backed by the
actor model + immutability is a huge productivity win. It's significantly
different (to a point where I think it's way more accurate to group Ruby with
Go than with Elixir), but, as I've tried to explain, very approachable.

~~~
nickjj
> copy and paste a higher-level construct like an Agent or Genserver and add
> the 1 line of code to this root supervisor that was just a file auto-
> generated in your project. But that'll get you a) introduced to the actor
> model and b) thinking about messaging while c) not ever worrying about or
> messing up concurrency.

Isn't it well known that GenServers can become severe bottlenecks unless you
know the inner workings of everything to the point where you're an expert?

I'm not an Elixir expert or even used a GenServer in practice but I remember
reading some warnings about using GenServers around performance because they
can only handle 1 request at a time and it's super easy to bring down your
whole system if you don't know what you're doing.

This blog post explains how that happens:
[https://www.cogini.com/blog/avoiding-genserver-
bottlenecks/](https://www.cogini.com/blog/avoiding-genserver-bottlenecks/)

And I remember seeing a lot of forum posts around the dangers of using
GenServers (unless you know what you're doing).

It's not really as easy as just copy / pasting something, adding 1 line and
you're done. You need to put in serious time and effort to understand the
intricacies of a very complex system (BEAM, OTP) if you plan to leave the
world of only caring about local function execution.

And as that blog post mentions, it recommends using ETS but Google says ETS
isn't distributed. So now suddenly you're stuck only being able to work with 1
machine. This is a bit more limiting than using Python or Ruby and deciding to
share your state in Redis. This really does typically require adding a few
lines of code and now your state is saved in an external service and now
you're free to scale to as many web servers you want until Redis becomes a
bottleneck (which it likely never will). You can also freely restart your web
servers without losing what's in Redis.

I know you can do distributed state in Elixir too, but it doesn't seem as easy
as it is in other languages. And it's especially more complicated / less
pragmatic than other tech stacks because almost every other tech stack all use
the same tools to share external state so it's a super documented and well
thought out problem.

~~~
dragonwriter
> And as that blog post mentions, it recommends using ETS but Google says ETS
> isn't distributed. So now suddenly you're stuck only being able to work with
> 1 machine.

There is a mostly API-compatible distributed version of ETS in OTP, called
DETS. And a higher-level distributed database built on top of ETS/DETS called
Mnesia, again, in OTP. So, no, you aren't.

> I know you can do distributed state in Elixir too, but it doesn't seem as
> easy as it is in other languages. And it's especially more complicated /
> less pragmatic than other tech stacks because almost every other tech stack
> all use the same tools to share external state so it's a super documented
> and well thought out problem.

You can use the same external tools in Elixir as on platforms that don't have
a full distributed database built in as it is in the OTP, so, I don't see how
the fact that those external tools are widely used on other platforms makes
Elixir _harder_.

~~~
b3orn
> There is a mostly API-compatible distributed version of ETS in OTP, called
> DETS. And a higher-level distributed database built on top of ETS/DETS
> called Mnesia, again, in OTP. So, no, you aren't.

DETS is the disk based term storage, it is as distributed as ETS.

------
pantulis
The greatest achievement of Elixir is making the Erlang platform and ecosystem
accessible to everyone. And that's because its "Ruby-ness".

I learned Ruby with Rails, so in the same spirit you could learn Elixir with
Phoenix and I really think it's a bona-fide approach to "graduate" to the BEAM
world.

But, caveat emptor, the BEAM world is like an alien wunder-weapon: everything
we take for granted in the modern web development world was already invented
--with flying colors too-- in Erlang/BEAM so there is a lot of overlapping in
terms of architecture solutions. In a Kubernetes/Istio world, would you go for
a full BEAM deployment? I don't say it's not an already solved problem but
what's the perfect mix-ratio? It depends.

~~~
dynamite-ready
The overlap between K8s and BEAM is a good question. Even amongst experienced
BEAM (especially Erlang) programmers, there's a lot of conflicting
information. From my limited understanding, Kubernetes is comparatively
complicated, and can hamstring BEAM instances with port restrictions.

On the other hand, there's a rarely documented soft limit on communication
between BEAM nodes (informally, circa 70 units, IIRC). Above this limit, you
have to make plans based on sub-clusters of nodes, though I have certainly not
worked at that level of complexity.

Would be interesting to hear what other people think about this specific
subject.

~~~
toast0
I have no idea where this limit came from. I worked at WhatsApp[1], and while
we did split nodes into separate clusters, I think our big cluster had around
2000 nodes when I was working on it.

Everything was pretty ok, except for pg2, which needed a few tweaks (the new
pg module in Erlang 23 I believe comes from work at WhatsApp).

The big issue with pg2 on large clusters, is locking of the groups when lots
of processes are trying to join simultaneously. global:set_lock is very slow
when there's a lot of contention because when multiple nodes send out lock
requests simultaneously and some nodes receive a request from A before B and
some receive B before A, both A and B will release and retry later, you only
get progress when there's a full lock; applying the Boss node algorithm from
global:set_lock_known makes progress much faster (assuming the dist mesh is or
becomes stable). The new pg I believe doesn't take these locks anymore.

The other problem with pg2 is a broadcast on node/process death that's for
backwards compatibility with something like Erlang R13 [2]. These messages are
ignored when received, but in a large cluster that experiences a large network
event, the amount of sends can be enormous, which causes its own problems.

Other than those issues, a large number of nodes was never a problem. I would
recommend building with fewer, larger nodes over a large number of smaller
nodes though; BEAM scales pretty well with lots of cores and lots of ram, so
it's nicer to run 10 twenty core nodes instead of 100 dual core nodes.

[1] I no longer work for WhatsApp or Facebook. My opinions are my own, and
don't represent either company. Etc.

[2]
[https://github.com/erlang/otp/blob/5f1ef352f971b2efad3ceb403...](https://github.com/erlang/otp/blob/5f1ef352f971b2efad3ceb4030e2367e8996f893/lib/kernel/src/pg2.erl#L286)

~~~
ksec
>I think our big cluster had around 2000 nodes when I was working on it.

Is there fairly recent? I thought WhatsApp was on FreeBSD with Powerful Node
instead of Lots of Little Node?

>BEAM scales pretty well with lots of cores and lots of ram, so it's nicer to
run 10 twenty core nodes instead of 100 dual core nodes.

Something the I was thinking of when reading POWER10 [1], what system and
languages to use with a maximum of 15 Core x 16 Socket x SMT 8 in a single
machine. That is 1920 Threads!

[1] [https://www.anandtech.com/show/15985/hot-chips-2020-live-
blo...](https://www.anandtech.com/show/15985/hot-chips-2020-live-blog-ibms-
power10-processor-on-samsung-7nm-1000am-pt)

~~~
toast0
Lots of powerful nodes. That cluster was all dual xeon 2690v4. My in-depth
knowledge of the clusters ends when they moved from FreeBSD at SoftLayer to
Linux at Facebook. I didn't care for the environment and it made a nice
boundary for me --- once I ran out of FreeBSD systems, I was free to go, and I
didn't have to train people to do my job.

We did some trials of quad socket x86, but didn't see good results. I didn't
run the tests, but my guess from future reading is we were probably running
into NUMA issues, but didn't know how to measure or address them. I have also
seen that often two dual socket machines are way less expensive than a quad
socket with the same total number of cores and equivalent speeds; with Epyc's
core counts, single socket looks pretty good too. Keeping node count down is
good, but it's a balance between operation costs and capital costs, and lead
time for replacements.

The BEAM ecosystem is fairly small too, so you might be the only one running a
16 socket POWER 10 beast, and you'll need to debug it. It might be a lot
simpler to run 16 single socket nodes. Distribution scales well for most
problems too.

------
phreack
I find this quite funny because it's my first time hearing I was supposed to
be thinking of Elixir as a Ruby thing. I actually learnt about it from a
concurrent computing class and it was always an Erlang thing, and now I know
it as the magic sauce behind Discord that I always want to try and never find
a good reason to.

~~~
linux2647
> I always want to try and never find a good reason to

As someone who learns best by doing, what are some practical projects that
someone could do to learn Elixir? I know that Elixir is quite capable of
solving certain kinds of problems very elegantly, but maybe my experience
hasn’t presented these kinds of problems yet. Outside of building a Discord-
like server or a Phoenix web app, what other good practical
projects/applications are there for Elixir?

~~~
dnautics
I'm probably the crazy one in the community who is using Elixir for the most
super-strange things. For example:

\- as a custom DHCP server to do multiple concurrent PXE booting (among other
things)

\- as a system for provisioning on-metal deployments (like ansible but less
inscrutable).

\- as a system for provisioning virtual machines over distributed datacenters.

I'll probably also wind up doing DNS and HTTP+websocket layer-7 load balancing
too by the end of the year. Probably large-size (~> 1TB) broadband file
transfer and maybe even object storage gateway by next year. I've rolled most
of these things out to prod in just about year. I honestly can't imagine doing
all of these things in Go, without a team of like 20.

Elixir sucks at:

\- platform-dependent, like IOS, android, or like SDL games or something,

\- number-crunchy, like a shoot em up, or HPC.

\- something which requires mutable bitmaps (someone this past weekend brought
up "minecraft server").

Actually even desktop might be okay, especially if you pair it up with
electron.

~~~
grantjpowell
> Elixir sucks at:

> number-crunchy, like a shoot em up, or HPC.

> something which requires mutable bitmaps (someone this past weekend brought
> up "minecraft server")

One thing I'd like to see for the BEAM communities long term are well
maintained libraries of NIFs[0] for high performance and possibly mutable data
structures. Projects like rusterl[1] and the advances made on dirty schedulers
make this more feasible than it used to be.

It would be cool to write all the high level components of a minecraft-esque
game in Elixir, and drop down to rust when you need raw performance. Similar
to the relationship between lua/c++ in some modern game engines

[0]
[http://erlang.org/doc/man/erl_nif.html](http://erlang.org/doc/man/erl_nif.html)

[1]
[https://github.com/rusterlium/rustler](https://github.com/rusterlium/rustler)

~~~
dnautics
I'm in agreement; though I don't like rust (can't read it) and am the author
of
[https://hexdocs.pm/zigler/Zigler.html](https://hexdocs.pm/zigler/Zigler.html)

------
jakuboboza
The best things about Elixir are mix and phoenix. We all can talk about how
well under load on multicore machines it behaves but that is the same as we
would talk about Erlang. What pushes Elixir beyond Erlang is advanced macro
language that allows for things like Ecto, mix with moden Ruby like gem+rake
kinda dependency management and really really good solid testing framework.

Elixir/Phoenix is really good. And the ecosystem is also pretty solid.

Pros:

* Functional language __* Multicore support built in * Mix * Phoenix * REPL * solid ecosystem of most needed tools

Cons are:

* Functional language __* Still niche adoption, not many talented people to pick from. * If you are deploying via release ( as you should ) mix is going away in production

 __Can be plus or minus depending on people reading it etc.

Now things like LiveView are just cherry on top. In general Elixir/Phoenix is
a full package.

~~~
lawn
I haven't done a release with Elixir or Phoenix yet and the documentation
about it is quite confusing. There are many different ways but I have no idea
which one to choose.

Why should I deploy with release?

~~~
nickjj
Yeah it's super confusing, especially since mix releases are now a thing, but
weren't before.

I've heard Chris McCord (the author of Phoenix) say he doesn't use Elixir
releases in production in most of his consulting company's client work. He
talked about it in some podcast like 6 months ago. I think they just run the
same mix command as you would in development but he wasn't 100% clear on that.

But yeah, it's not easy to reason about it, and also if you decide to use
releases it's a bummer you lose all of your mix tasks. You can't migrate your
database unless you implement a completely different strategy to handle
migrations. But then if you ever wanted to do anything else besides migrations
that were mix tasks, you'd have to port those over too.

~~~
dnautics
> it's a bummer you lose all of your mix tasks

That's not true at all. Mix Tasks are just code. Assuming you stashed them in
/lib (or someplace that elixirc reaches) you can call them in a release using
eval.

    
    
        path/to/bin eval "Mix.Task.MyMixTask.run(...)"

~~~
nickjj
Ah nice to know.

I've seen a bunch answers around having to jump through larger hoops to get to
run mix tasks in releases. Are all config options still available to be read
in mix tasks that are called that way? What about Mix functions like
Mix.env()?

If you Google around the topic of database migrations in Elixir releases
you'll find like 5 different ways to do them with no clear "this is the best
answer".

~~~
Ndymium
Mix doesn't exist in releases. You can get config options like normal, but not
`Mix.env/0`. You can compile your current env into a config option though, and
use that at runtime.

Here's an example how to set up an Ecto migrator task with Mix releases:
[https://hexdocs.pm/phoenix/releases.html#ecto-migrations-
and...](https://hexdocs.pm/phoenix/releases.html#ecto-migrations-and-custom-
commands)

------
m12k
As someone with a background in Objective-C, Swift, C++, C# and Java, and
currently using Ruby, I'm looking for my next language for web development.
Elixir sounds like a step up from Ruby, but I really miss static typing, and I
find it hard to justify investing time in yet another language that doesn't
have it.

But what are the alternatives? I'm looking for something with static typing,
good editor support, mature community projects (e.g. testing on par with
rspec), faster than Ruby (though most statically typed languages tend to be)
and if it supports some functional paradigms that could be a plus (I dabbled
in F# and SML previously).

\- Scala is an option, but build times sound like an issue, and the JVM is a
bit 'heavy' (e.g. startup times, min memory usage).

\- Haskell sounds cool, but maybe a bit too esoteric? (i.e. is it worth the
trouble, does it have all the middleware I'm used to)

\- C# could be an option, but is the open source/community support there? (if
you're not a corporate shop, doing corporate things).

\- And then there's Rust, which I'm fascinated by, but I'm also worried that
I'll be less productive worrying about lifetimes all the time, and that it's
less mature (though growing fast, and seems to have attracted an amazing
community of very talented people).

I'm also interested in ways to use a language like that in the frontend -
Scalajs sounds pretty mature, C# has Blazor and Rust seems like one of the
best ways to target WebAssembly.

So what is a boy to do? Stick to Ruby until the Rust web story is more mature?
Try out Elixir in the meantime? Join the dark side and see what C# web dev is
like these days? It can be really hard evaluating ecosystems like that from
the outside.

~~~
smabie
Ocaml/ReasonML checks all the boxes you listed. The tool chain is extremely
mature and it's pretty easy to pick up.

~~~
devmunchies
This. Although I would not use Reason since the compiler layer, bucklescript,
changed its name to Rescript to rebrand as its own frontend language and left
Reason holding the bag. There is no reference to OCaml in any documentation
that was once under the bucklescript project. It even created its own sytax
that is different than Reason and Ocaml to something more like JavaScript.

It basically should have been a new project and have had nothing to do with
bucklescript.

The worst part is that the owner of bucklescript even owned some properties
that had the name "reasonml" in it (like reasonml.org and the reasonml discord
group, which weren't owned by the Reason team) and then he pointed all those
thing to Rescript. Just the confusion did some serious damage to Reason.

My advice is to stick to OCaml.

~~~
smabie
Yeah I don't actually like ReasonML and don't think it should exist. OCaml's
syntax is great and easy to use.

Ocaml is a seriously underrated language and would be my goto choice for
developing a native or webapp.

I would still use Scala for backend development, though. The JVM is kind of a
drag, though.

------
atonse
The biggest adjustment for me was the fact that everything is immutable. Apart
from that, everything has been simpler to reason about in elixir.

Now objects feel very weird.

~~~
feifan
Elixir seems to encourage simple data structures — everything is made up of
basic data structures, and since there's no encapsulation, libraries seem to
be built with an attitude of "developers are gonna inspect everything so we
might as well make things clear and simple". I only noticed this in contrast
to libraries in popular OO languages (most recently Python) where everything
is done through objects that often have inscrutable instance variables and
"missing" methods/methods that library authors simply haven't gotten around to
implementing.

Having a small library of functions operating on a small number of data
structures makes programming a lot more intuitive than a large number of
classes, each with their bespoke set of things you can do to them.

~~~
jake_morrison
Instead of "lack of encapsulation", it's more "lack of private state". In an
object oriented language, you have private instance variables and methods to
manipulate them. In a functional language, you have functions which manipulate
data structures.

If possible, the data structure would have straightforward fields which are
public and documented. If necessary, you might make it opaque, expecting only
the library which manages the data structure to manipulate it.

One way to think about this is that in functional programming, the "verbs"
(functions and manipulation patterns like map) are more generic and the
"nouns" (data structures) are less important than in OO languages. See
[http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

~~~
leghifla
There is no encapsulation like in OOP (data level), but there is another kind
of encapsulation (process level): a process is the only one
accessing/modifying its own state. And this is very liberating when you need
to think about what is going on, what could go wrong...

------
josefrichter
I guess the point of this all is that there's BEAM underneath all this. And it
turns out to be one of the best solutions out there for web apps.

Erlang has some bad rep for "weird syntax", but it's completely unfounded, the
syntax is actually quite simple and clean.

Elixir opens doors mainly for Rubyists, but there are some other paths to
discover BEAM. Check out:

Luerl – Lua on Erlang
[https://github.com/rvirding/luerl](https://github.com/rvirding/luerl) LFE -
Lisp Flavoured Erlang
[https://github.com/rvirding/lfe](https://github.com/rvirding/lfe)

~~~
dragonwriter
> Erlang has some bad rep for "weird syntax", but it's completely unfounded,
> the syntax is actually quite simple and clean.

Anything that isn't Algol-flavored and either procedural or class-based OOP
tends to be seen as weird syntax, and much more so if it ticks both boxes.

It's not as much a matter of simple and clean as familiar in a world where
almost everything people will be exposed to first tends to come from a narrow
design space.

------
sickcodebruh
Every time I think about using Phoenix, I get scared off by warnings about how
not knowing BEAM can result in serious problems. I’m not sure if that
conclusion is justified but it’s where I end up every time. It’s odd and
unfortunate that Elixir and especially Phoenix seem to have invested heavily
in being approachable but the rest of the ecosystem seems to have warning
signs posted all over the place.

Is this a fair impression? Or is it possible to run Phoenix in production and
gradually learn more about the BEAM, leveling up as you encounter new
challenges?

~~~
josevalim
We work hard exactly so that you can run Phoenix in production and gradually
learn more about the BEAM along the way!

One recent example is the built-in dashboard showing all the different data
the VM and the framework provide:
[https://github.com/phoenixframework/phoenix_live_dashboard/](https://github.com/phoenixframework/phoenix_live_dashboard/)
\- at first it may be daunting but providing a web-based experience to help
familiarize with the building blocks is hopefully a good first step. We also
added tooltips along the way to provide information about new concepts.

The same applies to Elixir: learning all of functional programming, concurrent
programming, and distributed programming would definitely be too much to do at
once, so we do our best to present these ideas step by step.

For what is worth, this is also true for Erlang. It has tools like Observer
(which was used as inspiration for the dashboard) and a great deal of learning
materials.

One last advice is to not drink the cool-aid too much. For example, you will
hear people talking about not using databases, about distributed cluster
state, etc, and while all of this is feasible, resist the temptation of
playing with those things until later, unless the domain you want to use
requires explicitly tackling those problems.

I hope this helps and have fun!

------
spapas82
Elixir is like an abstraction on top of Erlang and its runtime(otp). It
heavily depends on the data structures of Erlang and its very difficult to
extend it beyond Erlang's limitations / capabilities. When you take macros out
of the way, Elixir programs can be translated line by line to Erlang. That OTP
dependancy is considered the great strength of Elixir by many but it also has
disadvantages.

The thing with Erlang is that it ain't a general purpose programming language
like Java or Python but a niche telecom software language. Erlang is
marketised like that and from what I've heard it's really great at that
(telecom software). But nobody proposes to write f.e a game or a Gui app in
Erlang.

Elixir on the other hand is marketised as a general purpose programming
language. People that start a journey of learning Elixir must be very careful
and understand that there are a lot of applications that Elixir can't be used
for because of Erlang's limitations.

Also, when you start using it you'll see that common applications outside of
the Erlang telecom niche, like the polular phoenix web framework and its ecto
orm like library make very heavy use of macros and message passing
abstractions that seem strange in a lot of situations. Of course all will fall
in place after you understand the Erlang dependecy.

~~~
dnautics
I can assure you erlang is not a 'niche telecom language's, as I have used it,
in prod, in so many ways that have nothing to do with telecoms. One mini-
project I'm planning on working on for fun is to use it for HDL simulations,
because its message passing concurrency is a nice way of cleanly dealing with
eventing voltage edge transition logic.

> But nobody proposes to write f.e a game or a Gui app in Erlang.

Yet square enix uses elixir for _game orchestration_

------
vinceguidry
I came to the same conclusion as the author, though not quite in the same way.
Everything I needed to know about what Ruby was was given to me when I
attempted to learn and love Crystal. Similar syntax does not make a similar
language. Smalltalk is far closer to Ruby than Crystal ever could be.

What makes Ruby so lovable is, in a few words, the _pure_ object orientation.
This is the source of all it's flexibility. Any concept can be created and
tersely described. It's almost as semantically flexible as Lisp and ultimately
friendlier.

You'll never get these benefits in a language that looks like Ruby. It's not
the syntax at all, it's the semantics, and you can't get Ruby semantics
without actually being Ruby.

~~~
grantjpowell
> [ruby] is almost as semantically flexible as Lisp and ultimately friendlier

Elixir for the most part _is_ a Lisp, and inherits almost all of Lisp's
semantic flexibility also

I write Elixir full time now after writing Ruby for several years. At first I
struggled getting out of the ruby meta programming mindset. After reading some
advanced lisp books, the concepts of quote/unquote began to click and now I
feel like my ability to meta-program in Elixir is much stronger than in Ruby.

~~~
vinceguidry
Not to take away from the sheer amaze-balls power that lisp offers, you can
get Ruby superpowers just from one book, Metaprogramming Ruby 2, which is
sadly out of print.

Here's a 2005 article comparing Ruby favorably to Lisp:
[http://www.randomhacks.net/2005/12/03/why-ruby-is-an-
accepta...](http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-
lisp/)

I learned Lisp, went through the whole of HtDP, tried to get into it, but
Ruby's friendliness is really special and unique.

~~~
fouc

        [1,2,3].map {|n| n*n }.reject {|n| n%3==1 }
    
        [1,2,3] |> Enum.map(&(&1*&1)) |> Enum.reject(&(rem(&1,3)==1))
    

Still somewhat familiar heh

------
lawik
Coming into Elixir from mostly doing Python but having it strongly recommended
by a Rubyist I was a bit surprised to find myself in the middle of an implicit
ex-Ruby world. It has been fine. But in contrast to the article, Elixir has
always been about Erlang/OTP for me. I've never cared much about Ruby/Rails
because it felt equivalent to the Python/Django which I already know.

~~~
dnautics
I would say that in my experience everything outside of Phoenix is more
explicit than python. There's a lot of hidden implicitness in python that
drives me up the wall when I'm trying to chase a bug in someone else's code; I
rarely have that problem in Elixir (even with phoenix, usually chasing where
the code comes from is not terribly hard).

~~~
lawik
Haha, I was referring to feeling the implicitness of "everyone came from Ruby"
which I didn't, rather than anything in the language. Sorry if I was unclear
:)

------
htnsao
Funny I came across this same article earlier today while looking into a Flow-
Based Programming framework for Elixir called Flowex. [1]

[1] [https://github.com/antonmi/flowex](https://github.com/antonmi/flowex)

------
didibus
Elixir is a little bit of Erlang, a little bit of Clojure, a little bit of
Ruby, and a little bit of its own thing.

Together that makes it that Elixir is Elixir.

~~~
Kototama
It's a lot of Erlang :-)

------
mcv
I hadn't heard of Elixir yet. I did use Ruby ages ago, loved the syntax, but
the language felt a bit flakey at times (for example, I had a project where I
needed to use unicode that didn't turn out to be properly supported).

Erlang has been on my radar ever since a friend wrote either Tetris or
Conway's Game of Life in 3 lines of Erlang. Never got around to learning it,
though. If Elixir is a friendlier gateway to Erlang, it might be exactly right
for me.

~~~
Gravityloss
Odd, I've seen so many encoding problems in other languages (Python etc) but
unicode has worked completely flawlessly in Ruby always.

~~~
mcv
Are you sure? I'm reasonably sure that Ruby 1.8 or earlier didn't have
flawless unicode support yet.

~~~
Gravityloss
Only used 1.8.7 or later versions. That seems to have been released in 2008.
[https://www.ruby-lang.org/en/downloads/releases/](https://www.ruby-
lang.org/en/downloads/releases/)

------
jrochkind1
At the time, making a language that on ran on the Erlang VM with Erlang
semantics that _looked_ like ruby probably seemed like a huge advantage to
Elixir. (Plus, the people who developed it were rubyists and former rubyists
who honestly liked the 'look alike' elements they took from ruby, it wasn't
just a cynical attempt at manipulation).

but these days ruby's popularity seems to be waning (personally I don't think
for any _technical_ reasons, especially when compared to it's nearest neighbor
python; to me it's like a 'betamax vs vhs' thing, and makes me sad, but
nonetheless) -- and the association to ruby may actually be holding it back as
people have (IMO unjustified) negative perceptions of ruby. :(

------
perlpimp
I love how documentation and tests are intertwined - bonus on thinking this
way from get go.

------
samuell
Now that we have Elixir (Erlang looking like Ruby) and Crystal (Go concurrency
dressed up like Ruby[1]), I'd be primarily be interested to see how these two
languages stack up against each other, what niches they might address etc.

[1] Did a small comparison here: [https://rillabs.com/posts/crystal-
concurrency-easier-syntax-...](https://rillabs.com/posts/crystal-concurrency-
easier-syntax-than-golang)

~~~
dnautics
neither Go nor Crystal have the same sort of failure-domain support that
Erlang Vm provides.

~~~
samuell
Indeed, but at the same time, it seems people are using both Go and
Erlang/Elixir for a lot of similar use cases (scaleable web-apps), which makes
me interested in what specific use cases they do respectively shine.

------
lovebes
I don't know Rails. I know Python and Golang. Worked in a data-intensive, data
heavy startup, throwing microservices, nanoservices in a haphazard fashion
with K8S backing the "throw and see something sticks" approach.

Elixir, and Phoenix makes me think. About three years ago, when we started the
company, if we had these two tech... we could've been saved so much dev time
focusing on the core tech, instead of making scaffolding work.

~~~
erinan
Same here. Microservices have their place if you expect to have to scale like
craaaaazzzzy or if you know that your platform will be huge with many
different parts but you can go a LONG way with a Phoenix monolith while being
"happier" and more productive.

From my (limited) experience it's an ideal framework for startups or new web
apps. I've also heard excellent things about replacing painful microservice
setups with one Phoenix app.

There is just so much you can do with it at scale and also so much you don't
have to do (e.g. channels + integrated pub/sub are a godsend). Definitely my
new favorite framework (+ language) for web dev.

------
microcolonel
After using Elixir professionally for a while, I still barely knew that it was
supposed to have anything to do with Ruby aside from the oversized
punctuation.

------
etxm
I really enjoy writing elixir and I’ve had some really quick wins that have
scaled effortlessly on the projects I’ve deployed using it.

I would love to use it to build a desktop app. I’ve fooled around with Scenic
for building a UI, but haven’t figured out a way to distributed a binary
besides a self extracting executable.

------
namelosw
Elixir is basically an Erlang that looks like Ruby instead Prolog. Combined
with Phoenix which looks like Rails, this language is really getting traction.

I wonder if an Erlang that looks like JavaScript would work. It would be like
what ReasonML to OCaml but may works better on the server side.

------
deltron3030
I'm a few weeks into Elixir and it and the ecosystem definitely feel more
techy and mathy than Ruby. It's more comparable to JS and node, it's like a
more consistent JS without the OO stuff plus convention over configuration.

------
b0rsuk
I'm getting the impression that Elixir is Erlang in Ruby's clothing, a bit
like Rust is (functional language) in C's clothing. Does that sound fair?

------
bigbassroller
Out of the ashes of Ruby, the Elixir cures and the Phoenix rises. My keyboard
is ready!

~~~
joelbluminator
Ashes of Ruby? Look at a jobs board, let me know how many Pheonix jobs you see
there compared to Rails.

~~~
pampa
And 99% of thse jobs are legacy RoR codebases, big hairy balls of mud. Good
for job security and pays well (somebody has to support it all), but somewhat
boring.

Also the ruby ecosystem is in decay. A lot of libraries are abandoned or on
life-support - just do a random search on rubygems and check release dates.

~~~
joelbluminator
"legacy RoR" , so if it's not a 2 year old startup "changing the world" \-
it's boring? Working in Stripe / Shopify / Github is boring? I'm pretty sure
btw new projects are being started in Ruby in bigger numbers than Elixir
(which isn't saying much, but still). I don't really love those language wars
but I don't see why Elixir has to keep trying to assert itself by dissing
Ruby. First - at least by numbers, it's way way smaller. Second - it should be
more confident in itself.

~~~
pampa
I'm not bashing ruby or something. I love ruby, I have been using ruby/rails
since rails 0.9. Still using ruby with roda/sequel, and i think it is the best
language to rapidly prototype and explore ideas.

But the reality is, that all the interesting and cool stuff is happening
somewhere else now. Ruby is still a great language, but the active community
outside rails is shrinking and the creativity isnt there anymore. People
prefer to explore novel ideas in different languages now - rust, go, elixir
etc, even if they do ruby for a living.

And rails is showing its age too. Every rails project i encountered was a
petrified spagetti monolyth that had to be broken up and refactored into
smaller pieces.

~~~
joelbluminator
No argument with you there, Ruby / Rails is pretty boring by now. As someone
who's looking for a stable stack I'm absolutely fine with that.

~~~
RandoHolmes
No framework that acts like Rails should be considered a stable stack.

If the answer to the question of "will it be supported in 5 years" is no, it
can never be considered a "stable stack".

~~~
joelbluminator
Can you clarify? I don't see what's so unstable about Rails. Probably
webpacker was the biggest change in Rails 6 and that's not mandatory.

~~~
RandoHolmes
If I write an application in asp.net core it will continue functioning on the
most recent version of .net core and asp.net core 5 years from now.

If I do the same thing on RoR it will not, guaranteed.

I've lost count of the number of times I've gotten a new client and had them
on a web framework that was EOL, on a version of the language that was EOL,
and on an OS that was EOL (because they couldn't get the EOL
language/framework running on a modern OS).

Anytime you use something like RoR you're automatically taking on a higher
maintenance burden because you MUST upgrade or you'll find yourself in a spot
where you're trying to decide if you want to rewrite or pull it up to the
newest version.

No part of that description screams stability.

~~~
joelbluminator
OK, stability is relative. Compared to Node / Elixir Rails is still pretty
stable. I'd put it with stacks like Laravel / Django. ASP.net probably changes
less, I agree. But .net core was a huge change though, kind of a new framework
right? new runtime even.

~~~
AlchemistCamp
I have an Elixir app from four years ago that still runs with no issues, even
on the current version. Can you elaborate?

There's no plan to ever have a v2.0.

~~~
joelbluminator
I don't have any experience with Elixir / Pheonix. From comments I read, even
things like deployment change frequently in Elixir, and major libraries are
created or abandoned. It's just still a very new ecosystem. In 5-10 years I'm
sure the rate of change will decline. Then there is a stack like Node where
constant change seems to be just part of the culture. Rails changes too, but
not as much.

~~~
RandoHolmes
Elixir compiles and runs on BEAM, which is a technology that's roughly 34
years old.

I think most elixir projects are on Phoenix, and while I can't speak too much
about the speed of that project, the poster you're responding too has clearly
stated they have an app that's 4 years old and running just fine so I have to
believe it's not as much of an issue as you think.

~~~
joelbluminator
Based on the one comment from the one guy - talking about one app that might
be not even Phoenix - it's definitely not an issue.

~~~
AlchemistCamp
It was a Phoenix app. Upgrading from v1.2 to 1.5 is very straightforward, the
largest part being replacing Brunch with Webpack for the front-end.

There are some new choices for building releases that make it easier for
people who prefer to use run time environment mentioned variables for
configuration instead of compile time ones. Previous ways of building releases
still work as before.

I make releases with Distillery just as I did back in 2016. The main change in
my release workflow is that now I use Gitlab CI/CD, and that's unrelated to
any Elixir or Phoenix changes.

------
philosopher1234
Over herr

------
gosukiwi
Last time I tried Elixir it had some rough edges where you had to use some
other ugly-ass language (I think it was Erlang?) to do some things. I
immediately stopped learning after that. It feels like before learning Elixir,
you need to learn Erlang, and I was just too lazy. Kind of using Clojure. You
don't NEED to, but knowing Java helps. A lot. You need to learn the ecosystem,
standard library, etc. You don't just pull a banana, you pull the gorilla
holding the banana.

~~~
baby
yup, I recommend just learning erlang.

~~~
dnautics
maybe it's just me. I can read and write erlang, but I still think it's harder
to read. It's got a lot of baggage behind it (like <<"this monstrosity for
binaries">>); map syntax is atrocious, and lexical substitution should
probably be considered to be an mistake this day in age.

~~~
baby
I've reviewed erlang apps and I found them surprisingly easy to read, like
really really clear. Perhaps it was the developers who did a good job, but I
suspect it is the language. Sure some of the syntax is not super pretty, but
I'd bet you would get used to it if you programmed in erlang more frequently.

~~~
dnautics
I can't believe it's a good job: most of what I read in erlang is the OTP
source. There are some real stinkers in there, in modules that barely anyone
uses anymore (so there aren't any bug reports), like tftp (but when you need
it you need it). And if you've ever tried chasing the ssl code, there's
definitely some java-esque factory patterns hiding in there where one module
or another drops an interface back to its caller, and the call stack weaves
several times between two or three modules even.

