
The Elixir of concurrency - carlesfe
http://cfenollosa.com/blog/the-elixir-of-concurrency.html
======
emson
Great article thanks. One of the things that helped me learn Elixir was to
play Elixir golf - it gives you a feel for the language and strengthans your
thinking in a functional way. Anyway check out
[http://elixirgolf.com](http://elixirgolf.com)

Disclaimer I wrote a Udemy course on Elixir too, so if anyone wants a 30% here
you go... [https://www.udemy.com/elixir-for-
beginners/?couponCode=Save3...](https://www.udemy.com/elixir-for-
beginners/?couponCode=Save30%25)

~~~
carlesfe
Thanks, added to the post!

------
dimgl
I'm sorry you had such a hard time getting into Elixir. Dave Thomas's book on
Elixir is a very good introduction and there are a few other Elixir books out
there that can get you started really quickly.

The issue really starts when you start writing web servers. I always advise
that anyone who wants to start using Phoenix learns how to use Plug first.
Phoenix is very macro heavy which can give that magic-is-happening feeling
when you run your app, but looking through the Phoenix source code and using
Plug is a great way of getting your head around what is actually happening
behind the scenes.

Elixir is incredibly powerful and I find myself being more productive with it
than with most other languages. TDD and integration testing is also
surprisingly easy.

~~~
rubiquity
+1 to learning Plug before Phoenix, too. Sometimes I feel like I have god mode
activated when co-workers or friends are hung up on the connection life cycle
or not sure how a piece of Phoenix works/scales. I'd add a basic understanding
of OTP to that list as well.

Phoenix does do an excellent job of getting people to try Elixir, kind of like
how Rails did for Ruby. Phoenix has also added a cool abstraction in
Presence/CRDTs. Now that people don't have to implement that themselves I
wonder if that will be as useful to people like how ORMs stormed onto the
scenes in the early 2000s.

~~~
goldbrick
Would you say that Plug is the Rack of Elixir?

~~~
rubiquity
Yes that's exactly the domain that Plug sits in. It's an interface from web
servers to applications. As someone who tinkered around with Rack and Ruby web
servers a lot, Plug is much better designed (yay for learning from past
implementations).

~~~
alxndr
I'd even say that Phoenix is more akin to Sinatra than to Rails.

------
sequoia
"A small community also comes with some upsides: people are more motivated and
willing to help, centralized tools like forums and IRC channels are still
manageable"

I recognize the benefit here but I have a strong aversion to this line of
decision-making. "Current thing is maturing and becoming popular, now the
community is unwieldy and full of riff-raff-- on to the next thing!"

I'm in the JS community and it is suffering terribly from this line of
thinking-- every time something reaches any sort of scale & there are new,
bigger organizational challenges, Thought Leaders jump ship to some newer,
cooler, smaller project (or language). Lather, rinse, repeat, repeat, repeat,
repeat.

Online communities are like this as well (see Reddit, Hackernews, Twitter,
etc.). Only difference is the cost of moving from Reddit to HN is minimal for
the user, the cost of learning a new language or rewriting an app on a new
platform is HUGE for developers and organizations.

So I don't know elixer & if it's cool and worthwhile, by all means let's
encourage people to use it, but NOT because it's new and the community is
small! Beauty fades and if you're moving on to the next thing because it's
young & doesn't have any warts yet, mark my words-- you'll be moving again
soon enough!

~~~
yarou
I think you misunderstood the context of that sentence.

The way I read that was: "most people are hesitant to try a new language with
a small community, and lack of stackoverflow support, but here are some
potential upsides of being in a small language community".

Not so much: "hey, you should switch to this shiny new thing just because it's
new".

------
arca_vorago
I just started a new project in Elixir (aimed at systems administrators), and
am very excited about using it for what it is good at, and breaking out to
system for what it's not good at.

To the author, this is one of the best summary writeups I have seen on it, and
I read every elixir thing that comes across hn or elixir radar. I think there
should be more emphasis that just because elixir doesn't necessarily do
computationally heavy stuff easily, there is nothing to stop you from using
elixir as the job handler and then use something else for the heavy part.

There are also some things which I think might do well in elixir we might not
think of. For example, on the irc chan I was told if you call a system call
from elixir/erlang you lose the concurrency... so why not write somethings in
elixir that were in system, for example, icmp/snmp query?

~~~
rubiquity
Very cool! I've had lots of ideas around how Elixir would be great for
building orchestration or provisioning tools. The concurrency model and
immutability are fantastic for that kind of work.

Regarding system calls and concurrency: Erlang does lots and lots of system
calls. I think what that/those person/people were talking about are NIFs
(Natively Implemented Functions) written in C. Those block the scheduler while
calling out to C. However, that is a thing of the past with the implementation
of dirty schedulers. AFAIK, Erlang/OTP 18 added better control of dirty
scheduling and I think version 19 builds on that some more.

------
carlesfe
Hi, author here, I’d appreciate any feedback, I always try to update blog
posts with new info and fixes :)

~~~
di4na
Hello. Really nice write up.

To follow up on your list of useful learning references, that talk from Chris
is a bit old, but it covers all the basics. Nearly everything is still up to
date. It is a bit long, but it takes time, cover everything and is not hard to
follow.

[https://www.youtube.com/watch?v=5kYmOyJjGDM](https://www.youtube.com/watch?v=5kYmOyJjGDM)

It was a workshop to teach the basics of Elixir at a Ruby conference. 3Hours
long, but really great :)

~~~
carlesfe
Thanks! Added to the post :)

------
idobai
> Elixir's novelty, the pipe operator, is a fantastic approach to working with
> state in a functional manner. Instead of running
> readlines(fopen(user_input(), "r")).uppercase().split(), try the more
> readable user_input |> fopen("r") |> readlines |> uppercase |> split.

The pipe operator isn't Elixir's "novelty". Also, why is it better than the
'.' syntax:

> fromFile(userInput).getLines.map(_.toUpperCase)

Do you get code completion for it as in an oop-ish language?

~~~
andy_ppp

        A |> B |> C second_param
    

Is the same as:

    
    
        C(B(A()), second_param)
    

It's much more powerful than that because you can create chains of functions
that pipe their output i.e.

    
    
       Some_data
       |> fetch_reports
       |> email_users
       |> setup_notifications
       |> IO.inspect
       |> affirm_elixir_pipes
    

It's 100% not the same as dot or arrow! IO.inspect allows you to print details
of any data being passed but also returns the first argument passed.

Hope this is a clear explanation of what is happening.

------
eggy
Making the jump from Java to Python, and from Python to Elixir is similar to
how I feel going from Common Lisp/Scheme to LFE, Lisp Flavored Erlang. The
Lisp part is friendly, but learning the really useful OTP is the harder part
for me. Even the funcional nature is familiar to me. I need to spend more time
on the OTP.

------
avodonosov

      1. Bring everything down?
      2. Try to capture the error and recover?
      3. Kill the crashed process and launch another one in its place?
      For example, C uses approach 1. Most modern languages
      with Exceptions like Java and Python use 2. 
    

No, in Java and C the "let it crash" (aka the "failstop principle") is also
used.

~~~
avodonosov
In C the OS process takes place of the Erlang "process". C is designed for
multi-process systems (Unix), where a task is often implemented by a number of
processes. Upon error the process is terminated, but the system (OS) is never
"brought down" by a single failure, remains fully operational and you can
retry your command again.

~~~
honua
While similar, it's not the same. Erlang/OTP/Elixir provides baked in tools to
watch, restart, etc. processes. In C you'd need to do this yourself.

~~~
avodonosov
The tools to watch, restart, etc are bash, ps, top, etc

~~~
dozzie
Not really. Those are equivalent to monitors and links in Erlang/BEAM, if we
go this line of thought. OTP is a collection of architectural patterns coded
down in Erlang (what means OTP is a framework).

~~~
avodonosov
We are talking about error handling. My point: "let it crash" aka "failstop
principle" is well known for decades, and practiced in all major languages.

~~~
dozzie
> We are talking about error handling.

I thought we switched to a little more down-in-the-trenches discussion with
you saying:

> The tools to watch, restart, etc are bash, ps, top, etc

~~~
avodonosov
Carried away a little. Not to say it's not interesting to compare Unix/C
programs with OTP/Erlang, but it's a different subject.

------
mathpepe
The we put cookie advice takes less than a second to disappear and it is
replaced with thank you for accepting cookies, this policy is not very
respectful with your viewers.

------
conqrr
Often compared to Rails. However no matter how similar syntax wise, Rails
greatest power is its community support. Which in Elixir's case isnt there
yet. I do believe in Elixir. However they would need wide adoption to compare
with Rails. Edit: I meant Phoenix. Sorry

~~~
ch4s3
Not to be overly pedantic, but Elixir is a language and Rails is a framework
built with Ruby. As I understand it, ELixir is more popular at this point in
its life than Ruby was when it was the same age. With respect to Rails the
ELixir equivalent would probably be Phoenix, which is a wholly different
beast. It is just past 1.0 and is already very productive and growing in
popularity. While the community isn't large per se, it's growing. Additionally
I think it caters to a different audience.

