The Elixir of concurrency | Hacker News Reader

The Elixir of concurrency

cfenollosa.com

116 pointscarlesfe38 comments

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

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

Thanks, added to the post!

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.

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

Would you say that Plug is the Rack of Elixir?

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

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

Author here, I definitely agree.

I tried to learn Phoenix just after Elixir, and I just couldn't do it.

Now I've written a couple of simple web apps with Plug, and realized that I don't need Phoenix for most of my use cases.

I'm sorry if it looked like I had a hard time. It wasn't hard, just long. I consider writing production code of a new language with a different paradigm in just two weeks a success!

I agree with web servers, check my reply below. Plug + Router is enough for most things, and even though everybody recommends Phoenix (maybe because many want to move from Rails to Phoenix?) I found it too complicated since I've never used an MVP framework, I'm more of a devops guy.

Finally, I didn't mention Elixir tests, but they are great. The lack of mutable objects helps a great deal too

Interesting, i think there is a telk to have here. Because Phoenix is not Rail. No part is forced. Everything is modular. Maybe there is a need to put an emphasis on that more on the main guides.

Because in the end, the only "mandatory" part of Phoenix are Cowboy, an Endpoint. And that is all. If you use Channels only, you do not need a Router.

"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!

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

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?

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.

Rustler looks quite nice for embedding native code in Elixir btw: https://github.com/hansihe/Rustler - I had some issues getting it running at first, but the author was very responsive.

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

Seeing the section "How to Start" I can't help but mention it doesn't include "How I Start: Elixir" :) http://howistart.org/posts/elixir/1

It's listed under First Projects "Portal Game by José Valim. A complement to the sample project on the official guide."

Oh, my bad :)

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

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

Thanks! Added to the post :)

I wasn't going to mentions this, but now you've commented.

>Neither developers don't want their code to crash nor Elixir promotes writing bad code.

Is this a double negative?

    Not(x nor y) = (not x) or (y)

Ok, I'm done, I'll go and sit in the corner with the other pedants now.

Hi, I'm not a native English speaker. Could you please suggest the correct way to rephrase it? Thanks!

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

    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.

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.

  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.

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.

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.

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

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

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.

> 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

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.

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.

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

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.

What is the point of comparing Rails to Elixir? You can compare Phoenix to Rails. Elixir/Phoenix has obviously a smaller community (but very welcoming and supportive and growing extremely rapidly). There are classes of problems you can not solve with RoR period.

Reply on news.ycombinator.com