
Elixir vs. Erlang: a question of momentum - davidw
http://journal.dedasys.com/2015/04/23/elixir-vs-erlang-a-question-of-momentum/
======
losvedir
More like "Elixir _and_ Erlang". It's certainly interesting to compare the
relative momentums of each language and think about why that may be, but I
hope people don't see it as a zero sum competition.

I was intrigued by Elixir, coming from a ruby background, but one of the key
points for me was the robust and battle-tested Erlang VM and OTP. And as I've
played with my Elixir app, I've found myself looking at Erlang code.

Erlang is one of the main draws of Elixir, and conversely the enthusiasm
around Elixir will be hugely beneficial to the Erlang community.

~~~
davidw
Excellent comment: it's definitely not zero-sum, but there is a bit of rivalry
and duplication of effort. If someone's using ecto, they're using postgrex
rather than epgsql, for instance. Elixir is definitely a gateway drug for
Erlang, for many people. I think one of the things that José has done so well
with Elixir is layer something on top of Erlang that adds to it without
muddying what was underneath, if that makes sense. You can see Erlang sticking
out in places, but what's on top if it fits there nicely.

------
aaron-lebo
Sure, Erlang has an issue with gaining forward momentum, but I feel like
people are really overstating the momentum Elixer has.

It is easy to gain huge percentages of momentum (if you could ever measure
that) when you have little to start with. That's the case with Elixir. That's
the same situation languages like Factor and even Haskell saw seven years ago.
The former is more or less dead and and the latter still never "broke out".

When Elixir is competing library-wise and ecosystem-wise with the likes of
existing languages like Python, Ruby, Java, Javascript, and then some of its
major selling points are in competitors like Go (though not 100%) or
Clojure/Scala (which can leverage the JVM), it really, really has to distance
itself.

As great as Elixir is, it is hard to make a bet on it ever crossing the
threshold of "this is really cool" to something you can goto because library x
y and z are available.

~~~
josai
>> I feel like people are really overstating the momentum Elixir has

I don't think so at all. I see elixir gaining a groundswell of momentum very
much like the early days of rails and node. Of course it's the beginning, but
I see a whole different crowd of people interested in elixir - the "gets
things done" crowd rather than the "this is cool/elite" crowd I see playing
with factor or haskell (sorry, but it's true).

Elixir does not compete with Python, Ruby or JS - it solves a whole different
problem, which is the "massively multiplayer" requirement the apps world is
obviously moving towards. No-one I know likes Go or Scala. Clojure is a
genuine competitor, you are right about that, but it lacks the ruby community
spirit showing itself in elixir. Say what you want about ruby but its
community moves mountains.

It's early, yes, but I know a lot of good rails devs who are embracing elixir
and they're all "smart and gets things done" types. A lot of torque is
building behind taking elixir mainstream, and there's excitement in the air.
Time will tell, but it's a bet I'm increasingly ready to make.

~~~
themartorana
Hi. I'm Dave. I really like Go, and I write and maintain a real-time and turn-
based multiplayer game backend.

I liked Elixir a lot too, but when trying to pick the right tool, the learning
required around Elixir/Erlang, the VM, and OTP didn't make sense when writing
a production system that needs to handle 1000 req/s or more with a small
staff. Go handles what we do fantastically.

Now you know someone. :)

~~~
perishabledave
If your interested, Jamie Winsor of Undead Labs did a talk at Erlang Factory
on how they use Elixir for their backend:
[https://www.youtube.com/watch?v=_i6n-eWiVn4](https://www.youtube.com/watch?v=_i6n-eWiVn4)

Also theres a good writeup on how Erlang was used for some of Call of Duty's
infrastructure. [http://www.erlang-
factory.com/upload/presentations/395/Erlan...](http://www.erlang-
factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf)

Sounds like you're already committed to Go, but just wanted to make the case.
Concurrent, fault-tolerant, highly scalable systems is Elixir's sweet spot.

[edit] One more, great talk from the Elixir Conf on how Martin Shurrer used
Erlang to build a multiplayer card game. This one is particularly good because
it deals with scaling, game states, and is very practical:
[http://confreaks.tv/videos/elixirconf2014-otp-in-
production-...](http://confreaks.tv/videos/elixirconf2014-otp-in-production-
the-nitty-gritty-details-of-game-servers)

~~~
themartorana
To be clear, I really liked both Elixir and Erlang. It's just that purely
functional programming, the Erlang VM, OTP, and so on all required learning,
and so introduced so many possible points of failure.

Go was familiar from the jump, and easy to reason around coming from primarily
Objective-C, C, Python, and C#. Considering timeline, it wouldn't have made
sense to be so behind the learning curve.

With more time or breathing room, I think Erlang would be a space I'd jump
into with both feet.

Edit: I know Martin through common colleagues and have worked with him in
Austria. He's a great dev, and that was a good watch. Thanks for the link.

------
MCRed
Elixir is one of the best ways to program erlang. I learned erlang first, many
years ago, and I don't really think of them as different languages. Yes, they
have different syntaxes and yes Elixir has added features. But when I'm
programming in Elixir I'm using the same part of my brain that loved
programming in erlang. I think in the same way.

More importantly, I think, for some reason so many programmers just can't get
past erlang's syntax. I've never seen any really good criticisms of erlang
that made sense-- other than the syntax. While it was fine for me when I was
doing erlang all the time I did spend a couple years away and find it
frustrating again. So Elixir fixes that.

Further, there is no other language/platform that does distributed computing
correctly, or on such scale, and with such battle testing. Haskell may do it
correctly (I'm not sure) but it's very new. Go, Node.js, every "actors"
library you can think of, they are single-threaded-thinker's attempts to
scale, and they are not correct.

Yes, in computer science there is such a thing as "correct" and "not correct",
and way too many young programmers seem to think popularity determines
correctness.

IF you haven't learned Elixir and you want to write code that runs on multiple
machines without a lot of hassle, and you've seen how tough this is to do on
other platforms, head over to [http://elixir-lang.org](http://elixir-lang.org)
and learn. It's really a delight!

Edit: Fixed some typos. Oops. Want to add, my intention is not to bash
languages like Go. Go has some good ideas and is appropriate for certain use
cases. It's just frustrating to see these things being pitched as
"distributed" when they have not incorporated the lessons learned building
erlang over 20 years ago, and the 20+ years of development since.

~~~
j-conn
_does distributed computing correctly_

 _Go, Node.js, ever "actors" library you can think of, they are single-
threaded-thinker's attempts to scale, and they are not correct_

Could you elaborate, or point to a resource comparing the different scaling
strategies? What makes the Erlang approach correct?

~~~
MCRed
It really is concurrent and at a fundamental level, eg: it's supported in the
VM. The JVM does not support it. It's not a language feature that simulates
concurrency and it's not throwing the baby out with the bathwater and just
using events (node.js).

The book recommended by the other replyer is probably good. I'd also suggest
you check out Joe Armstrongs thesis or his ProgPRog book "Learning Erlang".

There are many necessary things to do things right. It's not a single feature.
Erlang the language, the VM, the OTP platform are a collection of all these
choices...

~~~
KirinDave
I understand and appreciate your enthusiasm and excitement over the Erlang vm,
but you really shouldn't misrepresent what's possible with the JVM, the Go VM,
or even with Node.js.

All support parallelism as well as concurrency, and all can do so with an
actor paradigm (and predictably, Node's support is the weakest).

Erlang's solution is more exciting because it offers a transparent mapping
between local and remote code, so long as "transparent mapping" ignores the
performance overhead.

~~~
phamilton
The problem is that there is a leaky abstraction of concurrency in Node and
Akka. Anytime you want to do some blocking computation or IO, you put the
whole application at risk. This even applies to garbage collection. There's a
whole class of things that you shouldn't do in that concurrency model. You
also have to be sure that none of the libraries you use are doing these
things. (zealots will say "don't do blocking IO in Akka!", which missing the
point entirely)

Erlang's solution shines (in addition to reasons you cite) because of its
efficient scheduler. That's something that you can't have in another language
without essentially building Erlang itself.

~~~
KirinDave
> Anytime you want to do some blocking computation or IO, you put the whole
> application at risk.

It is true that you should not do this, and it's a fair point. Of course, you
don't do it with Erlang either! Erlang carefully takes all file I/O out of
their actor model and has it so that one (and only one) process can interact
with a file handle. Operations to this have to be serialized by the actor.
Since there is only one implementation of I/O and it's non-blocking, this
works fine, but _if your application is an actor pipeline you run exactly the
same risk as your mailbox overflows_. Needham's Duality is real.

And naturally that ignores the fact that JVM concurrency and parallelism can
handle that outcome perfectly well (and in fact Akka appeals to these
primitives). It's absurd to suggest that java.util.concurrent doesn't have
great tools for parallel anything, let alone parallel I/O.

Golang, by the way, doesn't have this restriction. The runtime supports non-
blocking, parallel-friendly I/O from the ground up.

And as for Node.js, well the general abstraction here is the most parallel of
all. I'm not a huge fan of it and I agree it's a bit leaky, but Node's cluster
stuff is serviceable and used by many. You cannot argue the actor model is
essential, threadpools and actors ultimately model the same process and as Go
has shown can do so with similar sharing semantics.

Finally, Erlang's scheduler is not black magic nor an arcane work of wisdom.
It uses well-known, well documented principles and techniques. Quite frankly,
its not the secret sauce of Erlang. Erlang's secret sauce is the HUGE some of
very good code for building a distributed system with all the robust goodness
that OTP provides.

Erlang's great, Elixir is interesting (albeit it took one stinky old syntax
and exchanged it for another stinky syntax). I wanted to reply to that prior
post and talk to why Erlang has a magical recipe for _distributed_ code, not
_parallel_ code. Quite frankly, Erlang's parallelism story only makes sense in
the context of its decision to make remote and local execution
indistinguishable at the call site.

~~~
phamilton
In the context of sharing IO, Erlang does have the same problems. I was
however referring to IO in the sense of "I'm going to block until I get a
response." And not have to deal with callback shenanigans (be it futures or
callbacks). Golang does solve these issues fairly well except for GC issues
(which I've heard have gotten better).

~~~
KirinDave
> I was however referring to IO in the sense of "I'm going to block until I
> get a response." And not have to deal with callback shenanigans (be it
> futures or callbacks).

Callbacks and futures are very different modeling techniques and I'm not sure
why you'd suggest they're inherently inferior. They have their uses just like
the Actor model.

People obsess on the existence of blocking I/O (proponents of Node.js do this
too) and I find it strange that this is still a subject of conversation. It's
by and large a solved problem.

> Golang does solve these issues fairly well except for GC issues (which I've
> heard have gotten better).

Golang's GC issues were no to much about GOMAXPROCs as just needing a really
good optimization pass. As a younger language, it's unsurprising it needs some
time to reach production readiness. Erlang has the benefit of many years of
testing in anger.

------
digitalzombie
This is the same feeling I have. Well mostly toward Erlang. I was at an Erlang
meetup and I've mentioned that the reason why Ruby is popular was because of
RoR. Erlang needs a killer framework. A web framework would be a good choice
since RoR have shown that. The consensus I got from this was basically Erlang
doesn't need a killer software and the majority at the meetup thought the idea
wasn't valid.

Here come Elixir and so far it have decent momentum. It got mix, ecto, etc..
tools. And all of a sudden the creator started to contribute to Phoenix
framework. It got 2 books now and an OTP books coming out.

In general, I think Elixir is executing pretty well. If pheonix hit 1.0 that
is comparable to RoR and can make restful service dead simple with oAuth,
elixir might have a chance.

edit:

From what I've gathered:

The blog posts and online community of Erlang is mostly technical. The
community at the local meetup is very against new ideas, they're stuck in a
cycle of continuing the same path while complaining about how to get adoption
rate up for Erlang...

~~~
Luc
> Erlang needs a killer framework

I like N2O a lot: [https://github.com/5HT/n2o](https://github.com/5HT/n2o)

~~~
davidw
One part of that, and Nitrogen, that I really disagree with is "writing HTML
via Erlang": the number of people who can hack on a template that is HTML with
some processing instructions exceeds, by orders of magnitude, the number of
people who can write Erlang.

~~~
Luc
I'm sure this only partially addresses your issue, but one can use DTL (Django
Template Language) with N2O:
[https://synrc.com/apps/n2o/doc/web/elements.htm](https://synrc.com/apps/n2o/doc/web/elements.htm)

------
jacquesm
I think in part this is because there are a few very vocal elixer proponents
here on HN and this being _the_ site where those people with scaling issues
and 'erlang' style problems (which most web stuff actually is!) converge the
uptake could be substantial. Erlang doesn't nearly have the 'hey look at me, I
wrote a language' component but it just quietly excels at what it does
(reliable, scalable). Elixer being targeted at the VM it is very well possible
to have the best of both worlds.

I'm curious what will happen in the longer term, if at some point the
'upstream' providers of the erlang ecosystem will take notice of elixer and
will start to cater to it and then maybe actually adopt it. Until then I'm on
the fence, elixer could be great but it also could end up being abandoned as
more and more warts in erlang are taken care of.

And most of those warts are cosmetic rather than real problems, the lack of
libraries will hurt both languages just about the same and it would be much
nicer if new libraries were written with interop in mind.

That way they will have staying power regardless of which language will
eventually become dominant/stay dominant.

The erlang vm and ecosystem are very well thought out, battle hardened and
solid beyond what most programmers that came into the profession past say 1998
or so are familiar with but it is clearly showing its age and elixer solves
some of those problems. A more open process around erlang itself could easily
take the wind out of elixer's sails.

Time will tell, it sure is interesting.

And thanks David, excellent post.

edit: it could actually be that elixer will drive developers to erlang in the
longer run, the syntax is a minor nuisance easily understood after a little
bit of work and the 'strings' issue is mostly a different take on an old
problem that you can either work around or simply accept as part of the deal.
It can throw you for a loop but not worse than the things other languages will
force on you and if you think about it is actually an elegant solution, re-use
the same data structure to make life easier.

If under the hood those lists would be replaced with something like the
clojure ones you might be able to get rid of the performance issues entirely
without affecting the code already in production (unless it was C code
operating directly on internal structures of erlang).

~~~
phamilton
They've gone as far as making 1 in 8 tracks at Erlang Factory about Elixir.
They had José give a keynote last year and participate on a panel this year.
Robert Virding (one of the creators of Erlang) is fairly active in monitoring
(and participating) in the elixir mailing lists. Granted, there's always a
small tone of "get off my lawn", but that's just entertaining :-).

I've mentioned this before but I'll daybit again. Protocols and Macros are the
game changer. The Enumerable protocol absolutely changes the way you write
code and solve problems. Doing the same thing in Erlang is just not the same.

------
alanpeabody
As huge fan of the Elixir language I think this article missed the point.

Elixir is gaining popularity _because_ of the Erlang VM and libraries. Yes,
macros, protocols, syntax, etc may attract a first glance at the language, but
I believe people stay and evangelize Elixir because of the power of
Erlang/OTP.

Likewise, I think Elixir popularity will only drive Erlang, Joxa, and LFE
popularity forward as the initial roadblock of grokking the Erlang VM and how
OTP works are overcome.

~~~
rdtsc
Exactly. Just Elixir build on say Ruby VM or Python VM would not be appealing.
BEAM VM is really a marvel of engineering. Telling others that yes it provides
lightweight processes which also have isolated heaps is often met with
disbelief. It is almost magic.

------
kungfooguru
It should be noted that rebar3 ([http://rebar3.org](http://rebar3.org)) uses
hex for packages and has a plugin for working with hex repos
[https://github.com/tsloughter/rebar3_hex](https://github.com/tsloughter/rebar3_hex)

~~~
rlbaker
Given I had no knowledge of rebar3 before clicking the link, it took me a
while to discover what it actually is.

There is no descriptive text on the landing page aside from "Build Better
Erlang" which i guess narrows this down to some sort of erlang developer tool.
The Getting Started page has no mention of what we are installing actually
does aside from a snippet in their console output log "you can use rebar to
build OTP-compliant apps". So its a build tool? Not until "Basic Usage" do I
find out in writing what rebar potentially is:

"Rebar3 comes with templates for creating applications, library applications
(with no start/2), releases and plugins"

So it's a project templating tool? Does "comes with" mean it has more
functionality than just templating? On the sidebar I see some terms that lead
me to believe it can do more than that but I would love something on the
landing page that told me exactly what the tool's purpose or function is.

From my understanding it is a tool similar to Leiningen?

~~~
mononcqc
Yes, pretty much. I think we went short on the rebar3 descriptions just
because of how known 'rebar' is as a household name. Go to almost any Erlang
project, and you'll find 'rebar' or some variant.

Rebar3 is the next version of it.

But you're entirely right, the page and documentation is lacking to people
unfamiliar with the Erlang/OTP ecosystem.

------
hnrem
I had a brief look at Erlang in my spare time. Time passed, and I would have
returned to it at some point, but then Elixir appeared on the radar, and it
appears almost as a refreshed, improved Erlang, an Erlang 2.0. Well, why would
I learn yesteryear's implementation instead of a modern implementation? So, I
looked at Elixir, and now would need an unlikely compelling reason to look
back in Erlang's direction with any serious effort. When people talk about
Erlang, they talk about telephone switches and data stores - I'm never going
to be hired to build either, how many are? Elixir being used for more modest
feats of engineering makes it sound more appealing and accessible to the
mortal majority, hence building momentum. That said, I've just looked at the
roles advertised at a large London tech fair - two Golang, zero Elixir, zero
Erlang, numerous .Net and Java, countless Javascript. Long way to go for new
languages, and London feels excruciatingly risk-averse.

~~~
xixixao
That's funny because JavaScript could be considered a new language (unless you
were counting the "JavaScript, HTML, CSS knowledge useful" descriptions).
Languages take time, two Golang jobs is already pretty good given how young a
language it is.

~~~
hnrem
Its popularity increasing doesn't make it a new language. If you spend seconds
on a web search you'll see that two is pathetic compared to elsewhere - I'm
commenting on London there, not Go, or Elixir, both of which I would love to
use, hence my grumbling.

------
vezzy-fnord
_Trying to put together cowboy, poolboy, a circuit breaker, a database driver,
erlydtl, and various and sundry other pieces, for someone not well versed in
Erlang is a losing proposition._

How so? A framework can very much be (and often is) a reductionist endeavor:
the sum of its parts connected by entry points. Particularly ones that are
loosely coupled, as the one you alluded to (Chicago Boss) is

If someone is not well versed in Erlang, they should probably learn Erlang
before starting a project in it. Chicago Boss still makes implicit much of
OTP, the process model and records that it's easy for beginners to jump in,
though.

 _Their friend, using Elixir, will at least have something up and running in
short order._

Once again, this is just as applicable to Erlang.

 _A package management system, “hex”._

Do people even know why they want/need a hundred language-specific package
managers anymore, or is it just a cargo cult thing to do? No, a module system,
a dependency resolver (Rebar) and release management may push you out of your
comfort zone a bit compared to the typical do-everything package manager blob,
but it's very much doable.

 _Ecto database driver, with Postgres as the first database integrated
(yay!)._

Ecto looks more like ActiveRecord, but there's nothing particularly wrong with
BossDB. The fact that BossRecords are serialized as proplists means you can
perform relatively complicated operations by using list comprehensions alone.
Oh, but you have to learn some Erlang. No avoiding that.

 _Ecto migrations._

I might grant that. BossDB migrations aren't particularly advanced. Not sure
how well Ecto fairs in to it.

 _Porcelain, for working with external processes, where Erlang is somewhat
lacking_

[https://github.com/msantos/alcove](https://github.com/msantos/alcove)

[https://github.com/msantos/perc](https://github.com/msantos/perc)

Latter is old, but the point remains. Port drivers and NIFs can easily bridge
the gap from the Erlang VM to the host OS, and it seems that Porcelain uses
exactly the former, at least.

~~~
davidw
> BossDB migrations aren't particularly advanced.

No, they aren't, they were "the simplest thing that possibly worked" for my
needs (I wrote that code).

One problem with boss_db is that it uses some heavy duty compiler magic that
none of the "pure Erlang" kinds of folks really want to touch because it
produces un-Erlangy code. This leaves it in a no-man's land: the Erlang people
don't want to deal with it, and the people coming in from Ruby or whatever are
just going to go straight to Elixir which looks more familiar anyway.

~~~
rambocoder
IMHO when Ericsson decided to remove "experimental pmods" support from Erlang
in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a
liability. Ericsson's development team did release a workaround example, but
the whole process how this went down left a sour taste in my mouth.

My wish is that Ericsson's Erlang development team became more transparent to
the outside world, shared their bug tracker, code reviews (Go team does this
wonderfully) and did all development in the open. Then we would not have these
situations
[https://github.com/erlang/otp/pull/687](https://github.com/erlang/otp/pull/687)
and it would save me ton of time couple years ago chasing after ssl bugs.

~~~
davidw
> when Ericsson decided to remove "experimental pmods" support from Erlang in
> version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a
> liability.

It caused a bit of hassle, but not much, really. It was a feature that many
Erlang people did not like much in the first place, so heavy use of it put
them off to begin with.

~~~
rambocoder
I agree with you that it wasn't that much of a hassle technically, just wish
that the announcement was done with more transparency instead of "OTP
Technical Board" met somewhere and this is what was decided
[http://erlang.org/pipermail/erlang-
questions/2012-October/06...](http://erlang.org/pipermail/erlang-
questions/2012-October/069720.html)

Reminds me of Microsoft's .NET development process from 10 years ago, huge
corporation drives development of a platform behind closed doors with very few
people from the outside having any idea what is coming in the future.

------
mml
That this post has > 100 replies (good or bad) heartens me. I would be happy
to see more from erl or exrl. Both are phenomenal achievements. I'm only
saddened that erl doesn't move faster to modernize its obvious, and easily
rectified shortcomings (modern strings anyone?).

Adding hashes to erl is a good start, and joeerl seems very open to more.
There is certainly more to come in both camps, and that's good for everyone.

------
peregrine
Not a discussion of Elixir vs Erlang. Its not a zero sum game. Every
improvement to erlang is an improvement to elixir and vice versa.

------
fiatjaf
Quick side-by-side code comparison, for everyone wanting a quick (and not very
complete) overview:
[http://rosetta.alhur.es/compare/elixir/erlang/#](http://rosetta.alhur.es/compare/elixir/erlang/#)

------
rambocoder
Elixir needs a good IDE with code completion and jump to definition. There are
awesome Erlang plugins for Eclipse and IntelliJ IDEA, but for Elixir I am
still hacking in SublimeText and the lack of those two functionalities slows
down the process considerably, from what it could be.

~~~
Akkuma
I'm not sure if this would suffice, but I came across
[https://github.com/tonini/alchemist.el](https://github.com/tonini/alchemist.el)

~~~
rambocoder
alchemist.el does the trick. I got it to work after some configuration
tinkering, but so far so good. Thank you.

------
keithnoizu
A bit like lisp the metaprogramming aspect of elixir allows for really rapid
domain customization with out needing to have your changes approved by the
core team. I think this on top of interop with existing erlang libraries and
the scalability of the erlang vm model put elixir in a really good position to
have presence if not in web dev overall then atleast in areas that in the past
would have been grudgingly done using erlang instead of scala or whatever for
scale reasons.

------
deathtrader666
There's also a ton of great stuff highlighted at Awesome Elixir [1] and
Awesome Erlang [2]

[1] [https://github.com/h4cc/awesome-elixir](https://github.com/h4cc/awesome-
elixir) [2] [https://github.com/drobakowski/awesome-
erlang](https://github.com/drobakowski/awesome-erlang)

------
jrochkind1
> Being, among other things, a “web guy”, this is particularly noticeable to
> me, and perhaps less so to people using Erlang for what Erlang traditionally
> has done well.

What are the things Erlang has traditionally done well? In what domains is it
generally used now?

------
areski
Great article!

For a language that has been there for 29years, it's very hard to get such
momentum.

~~~
maze-le
Well, Erlang has kind of a cumbersome syntax, and it is hard to learn for
someone who has never seen a functional programming language.

IMO Elixir does a great job at reducing the inherent complexity of the Erlang
syntax, while keeping its powerful features (Erlang-procs, horizontal
scalability, fault-tolerance).

~~~
k__
But I still don't understand why Elixir didn't drop ends.

~~~
tormeh
I think they should keep the "end"s, but they should say what they end! "end
function" tells me that a function ends here. "end if" tells me that an if
statement ends here. "end" is just equivalent to "}".

~~~
yellowapple
Some Ruby (and Elixir and Julia and other languages that use `end`) will just
add a comment at the end of the `end` if they want to be more explicit about
it. For example:

    
    
        def foo(bar,baz) do
          ...
        end # foo
    

This brings me to why a bare `end` makes more sense (in the case of Elixir, at
least): because every use of `end` corresponds to a `do`. The above code is
basically equivalent to `def foo(bar,baz) { ... }`, since `def` takes a
function specifier and a block as its arguments.

If you really don't like `end`, you can also (at least with Elixir) use the
shorthand form:

    
    
        def foo(bar,baz), do: ...

------
platz
Is the main drawback about Elixir lack of support from Dialyzer?

~~~
djm_
You can use Dialyzer, not perfectly (yet) but it works. [1-2]

[1]
[https://github.com/jeremyjh/dialyxir](https://github.com/jeremyjh/dialyxir)

[2] [https://groups.google.com/forum/#!topic/elixir-lang-
talk/yDX...](https://groups.google.com/forum/#!topic/elixir-lang-
talk/yDXgV0hnM-c)

