| HN Mirror

I think a case could be made based on the relatively straightforward syntax (very few gotchas).

I mean, most functions will look like:

  f(X) when is_list(X) ->
    firstExpression,  % commas separate a sequence of expressions
    secondExpression; % semicolons tell us an alternate sequence follows
  f(X) when is_integer(X) ->
    thirdExpression. % periods terminate the block

Case expressions (similar to switch/case in other languages, cond in various lisps):

  case Expression of
    Case1 when SomeGuard -> Expression1;
    Case2 when SomeOtherGuard -> Expression2;
    _ -> DefaultExpression
  end.

Receive expressions:

  receive
    Case1 when SomeGuard -> Expression1;
    Case2 when SomeOtherGuard -> Expression2;
    Case 3 -> Expression3
  after 1000
    TimeoutExpression % handle timing out
  end.

Note how they're all following the same form (this is also a selling point of python, its syntax is pretty consistent, especially for the features used by beginners).

The conflation of strings with lists and characters with integers can be problematic, as sometimes a list of integers will display as a string if they fall in the printable character range (and this isn't what you want). This creates confusion, but it's surmountable.

Variables don't vary in erlang, but if a new user isn't accustomed to doing:

  x = y
  x = x * x
  x = x + 4
  x = sqrt(x)

then they won't have too big a problem doing:

  X1 = Y,
  X2 = X1 * X1,
  x3 = X2 + 4,
  X4 = sqrt(X4).

It is more cumbersome, but it's also likely that those intermediate variables could have more descriptive names.

The concurrency model is fantastic, and will, IMO, be greatly beneficial to anyone new to programming. Not because it's available in every other language (without libraries it likely isn't), but because it gives a really good mental model for concurrency that can be mapped to other existent concurrency implementations in other languages. It also helps to encourage a design based on loose coupling and high cohesion, which many (most?) of us believe are good design principles.

Syntactic sugar around list comprehensions, maps, binary comprehensions make a lot of algorithms very concise (though perhaps not performant, but this is effective for a first pass implementation when you're aiming for correctness and not speed).

The library ecosystem was less comprehensive last I checked (several years ago now), which made integrating some useful libraries very challenging. But I believe this has changed, and the Elixir project has certainly helped a great deal here as well.

The performance of numerical code hasn't been good. And a lot of people mistake concurrency for parallelism expecting performance boosts that just won't happen. Concurrency is largely a design/communication principle, not a performance one (though it can and does aid performance). So those are areas for concern.

There's probably more pros and cons, but I've got to go now.