
Joy of Elixir - GordonS
https://joyofelixir.com
======
adamkittelson
I've certainly enjoyed Elixir as an nth programming language and the idea of
Elixir as a 1st programming language is really interesting.

I know I've seen at least one educator in the community speculate that Elixir
(or FP languages in general) could potentially make great 1st programming
languages because they're often conceptually easier than OOP languages and in
many ways the difficulties people associate with learning them come from the
difficulty of unlearning some of the things they already know.

~~~
zensavona
I have first hand experience with this actually...

Over the last 6 months or so a good friend of mine has learned to code from
scratch. After much deliberation I took a gamble and set him up with Elixir as
his first language (largely because he wanted to code so he can work with me
on some projects, which use Elixir).

I am really happy with this choice and so is he. Elixir is a language with
very consistent ideas throughout and I think concepts like functional
transformations, immutability, pattern matching and actor based concurrency
are both extremely useful to learn early and very accessible to beginners in
Elixir.

Edit:

I didn't think of it when I wrote this comment, but I think the single most
helpful thing for beginners (and me!) in Elixir, is the 'h' function. If you
run it with any function as an argument in iex (Elixir's repl) you'll get
documentation and an example of how to use that function:

    
    
      iex(2)> h Enum.map
    
                                  def map(enumerable, fun)
    
      Returns a list where each item is the result of invoking fun on each
      corresponding item of enumerable.
    
      For maps, the function expects a key-value tuple.
    
      ## Examples
    
          iex> Enum.map([1, 2, 3], fn(x) -> x * 2 end)
          [2, 4, 6]
    
          iex> Enum.map([a: 1, b: 2], fn({k, v}) -> {k, -v} end)
          [a: -1, b: -2]

~~~
RodericDay
Python has the same via help(thing)

~~~
robert_tweed
As does Clojure with doc. However, neither of these include examples as
standard. Idiomatic docstrings tend to be a short string; one sentence or
paragraph.

------
cordite
While I applaud creating documentation, books, and guides for those new to the
language, there's still a significant accessibility gap in resources. I
already know the language, I've already done some basic stuff in phoenix, I've
even made my own HTTP API wrapper as its own library. But when it comes to
architecting backend systems that aren't tied to phoenix or playing around
with IEx, I really feel like I am on my own.

There are erlang books, of which I am reading, though it feels like there's
always emphasis on history for backwards compatibility and the other warts
that Erlang has with its age. I'd like to design reliable systems that operate
outside of the classic HTTP -> Elixir -> Database pattern. Things that involve
working in memory, processing queues, managing sessions and state, patterns
for fallbacks and breakers for services, and so on, that is where I seek more
content.

Unfortunately I hear the big BEAM player around, Basho, is shutting the lights
--so I can't expect to witness the wonderful presentations their engineers
provide at conferences or through recordings of such conferences.

~~~
jah
I feel that Erlang adoption is probably the most realistic growth path for
most serious Elixir developers. All of these topics you mentioned (breakers,
message routing, etc) have been discussed and developed in the Erlang
community for years. The only new thing that Elixir brings to the table in
these areas is abstraction and syntax - both of which are arguably not needed
in large complex systems.

Source: full-time Erlang developer of 7 years who spent a full year coding
Elixir in its v1.0.x days

~~~
59nadir
Learning how the BEAM works and the architectural decisions that make sense
for running your system on it is the realistic growth path for any serious
BEAM developer. This has nothing to do with any of the languages on the BEAM,
but with what makes sense on the VM.

Your assertion that abstraction is somehow not needed in "large complex
systems" (this being completely undefinable, by the way) seems silly and I can
refute it with about as many objective reasons as I suspect you have for
making that comment. Our current code base would be significantly shorter if
we used Elixir (on the order of 50% less code, conservatively approximated)
and is an absolute bitch to spelunk in specifically because it's just Erlang.

There is no reason to create a new project in Erlang (instead of Elixir/LFE)
outside of reasons like handing it off to clients or the like and the focus
should never be on learning Erlang, but on the BEAM. Any knowledge gained
through that is trivially used in one of the more productive languages on the
BEAM.

~~~
ams6110
50% less code? Can you provide some more specifics? That seems like a bold
claim.

~~~
59nadir
We use REST for both internal and external calls to services (a mistake, in my
opinion) and while Erlang actually has frameworks for this, none of them are
good and cowboy_rest requires lots of boilerplate. Doing it with Phoenix would
cut out lots of entire modules and replace them with functions without paying
any real cost.

I like Erlang, but there's no upside to using it instead of something else
that runs on the BEAM, apart from making a basic library that you want to use
both from Erlang and Elixir (I don't know what the situation for compiling
Elixir with rebar3 is).

Effectively, Erlang is to Elixir what Java is to Kotlin, except there are even
less performance differences and no compatibility issues. It makes perfect
sense to learn Erlang syntax and learning the semantics of it will mean you've
learned BEAM semantics, but you might as well do that in Elixir and actually
have a better road to it.

Edit: I'd like to add that I find a general lack of tools for dealing with
boilerplate in Erlang. It also has a generally outdated functional programming
skew in that it doesn't at all facilitate pipelining and this makes it less
attractive to make nice abstractions like Plug(0), for example. This is
exacerbated by the fact that collections aren't abstracted over, so whenever
you end up dealing with them there's lots of sighing and docs checking to see
what the argument order was the week they designed that particular module and
that particular function in that particular collection module.

0 - [https://github.com/elixir-plug/plug](https://github.com/elixir-plug/plug)

------
beedn
is there any news recently about Elixir? I'm asking since recently Im seeing a
lot of articles about how to get into Elixir which is really nice since I just
started pickup the language as well.

~~~
pawelduda
Erlang/OTP 20.0, Elixir 1.5 and Phoenix framework 1.3 were all released in a
timespan of 2 months or so - huge improvements to the already great ecosystem.

~~~
pmarreck
Two months? Try all within the last 2 weeks!

~~~
bglusman
Erlang/OTP 20 came out June 21[0], so about 5 weeks ago. Makes sense though,
Eliir 1.5 was waiting for final release of OTP, and Phoenix was waiting on
final release of Elixir, but they'd all had very stable preview releases for a
while, so it wasn't a ton of work left on any of them, just finalizing and
testing I imagine. I'm super excited to get my side project[1] upgraded to 1.5
and see the new dev conveniences!

[0] [https://www.erlang.org/news/114](https://www.erlang.org/news/114)

[1]
[https://github.com/MasbiaSoupKitchenNetwork/open_pantry](https://github.com/MasbiaSoupKitchenNetwork/open_pantry)

------
achariam
I've spent the last year building[1] an open source side project with elixir
and phoenix. It's honestly been a pleasure to work with once you get over some
of the initial hurdles.

[1]: [http://www.achariam.com/elyxel](http://www.achariam.com/elyxel) (It's a
self plug but I genuinely think it will be helpful to folks)

------
bogomipz
I've been seeing a lot about Elixir lately. I am curious are people seeing a
demand for Elixir in the market?

Or has anyone recently hired for it? If so what did it look like from the
hiring side?

~~~
andythemoron
I happened to mention interest in Elixir on my LinkedIn page, and now I get
hit up by recruiters for it every so often, so it seems so. I haven't heard
too much outside of this personal anecdote, however.

------
amorphid
Side note... the book's logo is mildly similar to the Drupal icon. Might
confuse a few people.

[https://www.drupal.org/files/druplicon-
small.png](https://www.drupal.org/files/druplicon-small.png)

------
notamy
There seems to be an unfortunate number of "TODO: Add image here"-type blocks
in this. Other than that, a quick glance seems good to me.

~~~
ryanbigg
Yup, sorry about that! I am a _horrible_ artist and so I'm hoping to rope a
good friend of mine in to help with that. He's recently started a new job and
so he's been busy. One day there'll be some great images in the book.

~~~
notamy
Can't wait to see them! I really like the book so far :)

------
puuush
This doesn't improve the current docs or tutorials.

~~~
bostonvaulter2
It does if you are an absolute beginner to programming. If you are already
seasoned then yes it doesn't add much, it just means you aren't the target
audience.

~~~
X86BSD
Which the JOE folks make quite clear. Why would anyone assume this was not for
complete novices new to programming in general? It seems odd to me.

I find it a very good start for someone new to programming with zero
experience and wishing to start with elixir.

There are hardly any books that approach programming elixir from a complete
lack of programming knowledge POV. I'm happy to see this!

~~~
ryanbigg
Thank you for the validation! :) It really helps to see support like this for
the project.

------
jondubois
Why is there so much Elixir hype on HN at the moment?

HN shouldn't be used as a propaganda hype machine. I've seen all the language
hype cycles,

Year 1:

PHP sucks! Node.js is awesome! Everyone must use Node.js!

Year 2:

Node.js sucks! Go is awesome! Everyone must use Go!

Year 3:

Go sucks! Rust is awesome! Everyone must use Rust!

Year 4:

Rust sucks! Elixir is awesome! Everyone must use Elixir!

... And of course you get the odd Haskell article every so often.

Communities are promoting their stuff too hard - They are setting up their
users for disillusionment and disappointment.

~~~
bhauer
I too feel there is a generational hype cycle at HN. However, I don't see much
in the way of "language N sucks" as a precursor to "everyone should use
language N1!" Maybe I am just blind to the negativity, but in general, what I
see with each hype generation is only the positive side: "everyone should use
language N1!"

I suspect with any given hype generation—with each trending language—we're
going to see a lot of positive messaging as the fans up-vote articles
pertaining to the new hotness. Meanwhile, those who disagree (or simply don't
care) probably don't see much value in taking the time to _evangelize_ their
disagreement. I'm not upvoting Elixir content, but I'm certainly not going to
downvote it either. Why should I care if other people enjoy a platform I don't
care about? Good for them!

Also, perhaps as everyone is hyping language N1, those who are using N are
simply too busy using N and making a living to keep layering on the hype.

~~~
jondubois
Adding more programming languages just fragments the job market further. That
might mean fewer jobs available for other languages and allow software
developers less movement between companies.

How many times have you seen a job advert and you think oh wow that looks
interesting, I'd like to work there... Oh wait, they use X on the backend, I
don't have any previous commercial experience with X so damn, I can't join the
company. The more programming languages there are, the more often this will
happen. The time for creating and promoting new programming languages is over,
we have to move forward and work with the languages whose ecosystems have had
20 years to evolve - This is where the real value is.

I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js adds
no extra value to any given project... It only restricts the pool of potential
job candidates.

If you use any programming language for long enough, eventually, you will be
very productive with it - The language itself doesn't really matter.

Its just a waste because there are already so many languages optimized for the
server-side use cases which Elixir aims for and which are already doing a
great job.

~~~
klibertp
> [...] allow software developers less movement between companies.

> How many times have you seen a job advert and you think oh wow that looks
> interesting, I'd like to work there... Oh wait, they use X on the backend, I
> don't have any previous commercial experience with X so damn, I can't join
> the company.

Wait, just who are you, then? An intern fresh out of high school? Or do your
circumstances impair your ability to learn (I hope I'm not being insensitive)?
Are you a programmer?

I ask because it never happened to me, and I never even heard of something
like this from non-junior programmers. If the company I'd like to work at uses
a language that I don't know (there's actually pretty decent chance if they
use something mainstream) I believe in most cases it would be enough to tell
them I'll learn the language in a week and after a month I'll be writing
decent quality production code. There is no reason - except if I do bad in the
interview, maybe? - to not believe me, as that's generally accepted as a
standard timeframe for such things. In my case that's a lie, as I can get
started with a language in a matter of hours and start writing production code
after a few days - but I admit I'm unusual on this.

> I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js
> adds no extra value to any given project...

Programming languages are being created for a reason and "adding value" in
some kinds of programming tasks is a prime concern when designing them.
Different languages make different choices and in effect work better or worse
in given circumstances.

Replacing Node with Elixir (any BEAM lang) would immediately give you a true
SMP support without using spawned processes, for example, and could possibly
shorten and simplify your code if you have many communicating, long-lived
services in there. That's an added value, right? The saying "use the right
tool for the job" fits here perfectly.

> If you use any programming language for long enough, eventually, you will be
> very productive with it - The language itself doesn't really matter.

Exactly - so why limit yourself to a single language? How long do you think
you will be working? What will you do once you've mastered a language and
realize that you have 20 more years to work with it? Wouldn't that make you
bored after a while?

> Its just a waste because there are already so many languages optimized for
> the server-side

There is not a single language which offers the same mix of features as
Elixir. It's perfectly possible to have a system which would benefit from the
_just right_ mix of features and then not having these features is a
tremendous waste as well.

It's not like I don't understand where you're coming from: in my youth, when I
was learning C++, I also was frightened by the complexity and believed that it
will take years to master it. And it did take years, mostly because it's C++
and I was alone. However, the next language I learned - PHP if memory serves -
took me just a couple of months to get good at. Then, when I passed the 20
"langs known" mark, I realized that learning languages is no longer a problem
at all and instead made it into a hobby.

In other words, yes, you need some level of understanding of programming to be
able to efficiently learn new languages. I think it is better to strive to
reach this understanding instead of assuming new languages are bad.

~~~
jondubois
I've been programming for 14 years in about 10 different programming
languages... It's a struggle for me to list them all (let alone learn them). I
only really needed two of them; all the others were a waste of time because
they're so similar to each other.

Learning new languages is not hard for me, I can pick up a new one in a single
day and my code could fool someone into thinking that I've been doing it for a
while (if you ignore development speed)... But unfortunately that's not true
mastery, you can only truly master a language or framework after working with
it full time for a couple of years.

It takes a long time to absorb all the intricacies of a language to produce
really good software.

You could spend a few years studying French and think that you know it all by
the end just because you can talk fluently, but in reality you couldn't even
write a basic child's novel, let alone a top-seller, or a Pulitzer prize
novel.

It depends on what kind of work you want to produce.

~~~
klibertp
> 10 different programming languages... It's a struggle for me to list them
> all (let alone learn them).

That's still very little. You can take a look at my site (in profile, the
"Languages" page) where I listed PLs which I learned. There's 126 entries on
that list (to save you a couple of clicks). I'm not boasting - just offering a
different perspective.

> all the others were a waste of time because they're so similar to each
> other.

If they are so similar, then learning them should be very easy and quick, no?

> I can pick up a new one in a single day and my code could fool someone into
> thinking that I've been doing it for a while (if you ignore development
> speed)...

In a single day? So it's not that much effort, is it? Assuming, of course, you
won't hit the language which is different enough and your intuitions and
experience become useless.

> you can only truly master a language or framework after working with it full
> time for a couple of years.

You're wrong, in part.

It takes a lot of time to master your first language and a few others in the
beginning. Later it can take quite a lot of time to learn your first language
with a paradigm you're unfamiliar with.

But languages are similar to each other, can be classified into types and
studied in bulk. With enough languages (and frameworks) learned you develop an
intuition of what happens and how. With enough _different_ languages known,
you develop an intuitive feel for what's the best way of solving a problem in
a given language. There's also a bit of theory to be learned, but once you
have it down there's really nothing that can surprise you.

Personally, I've had the hardest time when learning J. There are exactly two
other languages which are similar (APL and K) and they both are even harder to
get into. So the reverse is also true: if you don't know enough about a
certain kind of languages, you're going to have a hard time.

In the end, I think we disagree on what we consider mastery. I don't believe
you have to remember all the finest details of implementation to say you've
mastered the language - as long as you can easily drop down to the compiler or
interpreter source, read it and understand without effort. It's all pretty
easy then, believe me.

