

Elixir and the Internet of Things – Handling a Stampede - gigasquid
http://www.neo.com/2014/01/14/elixir-and-the-internet-of-things-handling-a-stampede

======
wcummings
Glad to see more Erlang/Elixir/OTP articles on HN. With all these newfangled
cool kid concurrent languages, people seem to have forgotten the
sophisticated, decades old solution. Funny to think telecoms were solving a
lot of the same problems web devs are now (High Availability, Low Latency,
Fault Tolerance, large amounts of concurrent connections).

~~~
angersock
It's quite funny, since the the backbone server operating principles we all
use were developed at a telco anyways (hooray *nix!).

------
brassybadger
The funny thing is that most people choose Elixir over Erlang because of the
syntax - personally I can't stand Ruby but love the Erlang syntax. When I see
Erlang code, everything just clicks - almost like I'm reading prose.

So, if you want to harvest the power of Erlang, I'd suggest you start with the
real thing first. The only drawback is that once you get used to functional
programming, guards, pattern matching, OTP, cheap processes, links and all the
other goodness, there's no way back.

If you still feel Erlang is weird after spending a couple of days working with
it, feel free to jump on the Elixir bandwagon. :)

~~~
bitwalker
Personally I don't find Ruby and Elixir to be very similar. Maybe some of the
terms are the same, but in general they feel very different. Elixir has a much
more consistent syntax than Erlang (imo), it's macros are more powerful, it
has a great build system right out of the box (inspired by leiningen for
Clojure), and it can make use of any Erlang library with no additional effort.
I'm also a huge fan of Elixir's pipes feature, which I think makes a lot of
code much cleaner and easier to read. I love Erlang, but I wouldn't call the
use of Elixir over Erlang a bandwagon - there are good reasons why one would
favor Elixir as a starting point. There are probably reasons why one would
choose Erlang instead too, but I feel like if you are at a point where you can
choose one or the other, Elixir makes the most sense.

~~~
klibertp
Erlang syntax is a) Prolog inspired and b) more than 20 (closer to 30) years
old. While it generally gets the job done without much hassle, it's very
possible to improve on it. The macro system you mention is the reason I'm
going to give Elixir a whirl, despite being happy with Erlang otherwise.

Anyway, the situation of Elixir and Erlang looks more like JavaScript and
CoffeeScript to me than like Java and Scala. Of course, Elixir is similar to
Scala in terms of implementation - they both compile to bytecode instead of
transpiling like CS. But the features Elixir brings to the BEAM are less
groundbreaking and more practical, just like in CoffeeScript and unlike Scala,
which transforms JVM so much that it's almost invisible.

There's a difference, too - JS is being reworked and Harmony will bring many
improvements which Coffee has today, but I'm not aware of "next generation
Erlang" being actively worked on (Joe Armstrong does erl2, but I don't know
how active it is). So while there are people who don't use Coffee because "it
will be in the standard in a year anyway" this argument does not hold true for
Erlang and Elixir.

Just some random thoughts, I like them both and am actively learning Elixir
while maintaining a project in Erlang (and I also like Scala!) and I hope they
can both thrive. It's a symbiosis, really - Elixir brings a new wave of
developers to Erlang, and Erlang gives a solid foundation to Elixir.

~~~
ch4s3
Respectfully, I'm not sure I buy this comparison. Yeah, CoffeeScript adds some
cleaner syntax and OO niceties onto JS, it's still basically just a higher
level abstraction that get boiled down to JS. Elixir is a multi-paradigm
language that that gets turned into the same type of byte code that Erlang
does and is interoperable with Erlang. Its more like jRuby and Java both
living on the JVM and being able to call Java code in jRuby, or maybe its a
bit like ClojureScript and Clojure?

------
kungfooguru
I only skimmed so far, but you might want to checkout Ranch instead of rolling
your own tcp acceptor pool,
[http://ninenines.eu/docs/en/ranch/HEAD/guide/](http://ninenines.eu/docs/en/ranch/HEAD/guide/)

~~~
jeetkundoug
Thanks for the link to Ranch. As this was done as a spike with people who
(until that point) had never done Erlang or Elixir, it's certain that we
reinvented the wheel at certain points. That being said, we didn't really know
we were building a socket acceptor pool until we built it. I'll definitely
take a look at ranch and see if it would make sense to replace our home-grown
implementation with Ranch.

------
oijaf888
This seems pretty neat but what advantage does this have compared to
terminating SSL at nginx? I guess you still need to have something that nginx
can hand the connections off to.

~~~
jambo
I previously worked on this project, and most of the devices we handle are not
communicating over http. The goal is to manage long-lived TCP/IP connections.

------
Pxtl
Oooh, I didn't even know this existed. I've always been curious about learning
Erlang, but I'm always suspicious of languages that predate the vowel
generation.

~~~
lostcolony
I don't know how good the tutorials for Elixir are on teaching you the basics
of concurrent programming on the Erlang VM. It's very different than the
concurrency models you'd encounter in almost every other language (Scala, and
the Akka framework not withstanding, since they basically borrowed everything
from Erlang and implemented it on the JVM), so it's not merely a matter of
learning syntax and a couple of new constructs; your entire mechanism of
problem solving changes (I'd almost argue that Erlang is unique in being a
'concurrent language' rather than, say, an OO one, or procedural, or
functional. It's functional, yes, but its concurrency mechanism is messages,
which have no guarantee of delivery, so are by definition side effects).

As such, I'd recommend starting with Erlang rather than Elixir simply because
you'll find tutorials on how to start thinking about and breaking down
problems to take advantage of the environment; trying to write an Erlang app
using a paradigm learned from another language is going to be frustrating and
not performant.

Joe released a 2nd edition of Programming Erlang last year, which is a
-really- good introduction to the basic ideas of the language, as the focus of
it (as compared with the first edition) is very much beginners, and taking
advantage of the platform. [http://www.amazon.com/Programming-Erlang-
Concurrent-Pragmati...](http://www.amazon.com/Programming-Erlang-Concurrent-
Pragmatic-Programmers/dp/193778553X)

~~~
SkyMarshal
Also [http://learnyousomeerlang.com/](http://learnyousomeerlang.com/).

------
iwasphone
Gripping article, but his incorrect use of apostrophes made me want to an
hero.

