Item — HN Reader

The writing style of "Joy of Elixir" is (I think) inspired by "Learn you some Erlang for great good" [1] and "Learn you a Haskell for great good" [2]. Personally, I like the cutesy style for getting started with a new tool/technology/language, just to know the basics.

The main selling point of Elixir is concurrency. Dave Thomas gives this great example in the second page of his book [3]:

    defmodule Parallel do
      def pmap(collection, func) do
        collection
        |> Enum.map(&(Task.async(fn -> func.(&1) end)))
        |> Enum.map(&Task.await/1)
      end
    end

    result = Parallel.pmap(1..1000, &(&1 \* &1))

Elixir developers can see the beauty of that snippet. However, for beginners, it can be overwhelming or intimidating. If you want to understand what is going on, you first need to learn about enumerables, map/filter/reduce, lambda functions, capture and pipe operators, spawned processes, tasks, etc. Yes, that is a great example for showing the power of Elixir but if you are a beginner chances are you are looking for something easier (e.g., Joy of Elixir).

Take Nix and NixOS [4] for example. That is an impressive technology and it has a (not cutesy) documentation. But, as a beginner, I feel lost. I rather prefer a cutesy getting-starter tutorial or book.

So, yes, I think there is a niche for developers that want to start with cutesy material. It is just a matter of taste.

[1] https://learnyousomeerlang.com

[2] http://www.learnyouahaskell.com

[3] https://pragprog.com/titles/elixir16/programming-elixir-1-6

[4] https://nixos.org

3 comments

My favorite part was a you used &Task.await/1 :) Every time I see someone kick off a task without the await part, I want to cry a little bit.

Please explain, thanks.

The pattern in the example above is a fork/join model of concurrency. Task.async will spawn a new task and return a handle to it, the task will be scheduled and run at some point. Task.await takes that handle and waits for the associated task to complete before continuing and returns its result.

  do_work = Task.async(fn -> long_calculation() end)

That kicks off the new task, at some point later we should obtain and examine the result:

  result = Task.await(do_work)

https://hexdocs.pm/elixir/1.13/Task.html#await/2

OK, thank you very much!

But why would anybody "kick off a task without the await part"?

Sometimes you want something to happen, but you don’t want to block whatever you’re doing on that. Think things like sending a welcome email when someone signs up for a new account.

Not much of an Elixir developer but if I saw that snippet in code review I would flag it for readability.

Just because you can write something in 3 lines of code using lots of nesting and anonymous functions and variables doesn’t mean you should. This code would do better if it was longer, the variables had names, and the transforming functions broken out and named.

Disagree, you probably think it's unreadable because you don't know the language and/or concepts in this snippet.

But does that mean we shouldn't, for example, use destructuring in javascript because some devs might not know it.

At some point you have to assume a common ground of knowledge, and that common ground in Elixir is somewhat different than in algol derived OOP mainstream.

I've been writing Elixir for 5 years and I agree with the OP: I dislike the Ampersand syntax immensely. I find it a major impediment to readability.

I never quite understand this mentality that many engineers have.

Instead of taking advantage of advanced language features and teach them to people, we more often than not create rules to avoid using them because "someone else won't understand it".

Why not grow people instead of lowering the bar?

Because it’s not about growth it’s about the ability for a large team (and changing over time) to reason about a single code base.

Why not rewrite your entire business logic into a succinct DSL based on macros? Because making lower level or refactoring changes would be a headache.

‶I don't know this language, so I would reject the snippet in code review″

I certainly hope that for the sake of integrity, you would decline reviewing a language that you don't know.

This example is not so difficult to understand.

The important thing to realise is that the dot operator is used to access functions grouped into modules (or even invoke anonymous functions) rather than invoke methods on an object. Because Elixir being a functional language, the central operation is invoking functions on data and passing the results to other functions, rather than calling methods on objects.

From this understanding you can just grok from the code that this is a program that takes a list of numbers and squares them concurrently, in the process using your computer’s parallel processing hardware. And as this is a high level language you can create concurrent workloads with minimal implementation knowledge.

Even if you come from C family of languages where the & denotes something to do with address, you’ll realise the way Elixir uses it is not far away from that, but without the added tediousness of memory management. So elixir builds upon common conventions.

Some things like Enum may confuse a Java programmer. It’s Elixir speak for enumerable data rather than a collection of constants. And of course the pipe operator is different.

It’s certainly not easy to see this and write your own code and offer suggestions. But for a mildly experienced programmer who has already adopted the mindset that code is just a bunch of instructions presented in non-linear fashion, like in a legal document, this is an approachable intro to start asking questions from. First of all one should be willing to read a couple of pages from some book on what are anonymous functions and what is the syntax like for that etc.

The task is a bit more difficult for people who tend to look at code with a more inflexible viewpoint ie junior developers.

I'm not an Elixir beginner but all those ampersands means that either one writes that kind of code everyday or one won't understand what it does when coming back next month. Use names, not shortcuts.

Ampersands are the builtin symbol for point-free evaluation in Elixir.

If you forget what it means in a month, you will probably have other problems than this single snippet.

You never know in advance who will work on code in a large project, how expert in that language and under which time pressure. I prefer to stick to a common ground between major languages that lets (say) someone that knows only JavaScript at least read the code and understand what it does. If it means that I have to write a few more lines or type more characters in variable and function names, I do it. I never appreciate where languages and developers want to do smart things. Boring and plain is much safer.

If you find yourself in such conditions that JS developers unable to google ‶elixir ampersand″ are the ones reviewing your code often enough for it to be a constraint while developing, your company has much deeper problems far up the command chain.

My customers are small companies. Elixir is their choice.

The ampersand syntax is extremely common in Elixir code - absolutely the kind of thing you'd write every day. If your Elixir developers find the ampersand stuff hard to read, you've hired the wrong Elixir developers.

I very much didn't like the ampersands the first couple of years looking at Elixir code. I think I've gotten used to it now. Looking at my own code, it's definitely more terse than it used to be. I do usually move such things into a separately named method, or a lambda that's assigned to an appropriate named variable.

I do agree with you though, when you get a screenful of ampersands that contains non-trivial business logic - it's not great.