Elixir and the Internet of Things – Handling a Stampede(neo.com)
neo.com
Elixir and the Internet of Things – Handling a Stampede
http://www.neo.com/2014/01/14/elixir-and-the-internet-of-things-handling-a-stampede
6 comments
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).
It's quite funny, since the the backbone server operating principles we all use were developed at a telco anyways (hooray *nix!).
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. :)
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. :)
I would say it goes much deeper than syntax and both Elixir/Erlang can co-exist happily just like Scala/Java. After jumping into Elixir, you'll eventually have to become familiar Erlang/OTP conventions, but starting with Erlang is not a requirement. You're right that guards/pattern matching/OTP leave you with language envy once you go back to your previous language of choice. Elixir does remove some pain points of Erlang, particularly around metaprogramming, polymorphism, and string handling. I will say after getting into the ecosystem, I can't believe the Erlang folks have been quietly "building the future" all these years while the rest of us largely ignored their innovations.
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.
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.
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.
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?
I second that. Although I only write Erlang, Elixir is the future.
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/
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.
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.
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.
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.
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...
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...
Learning Erlang a few years ago was one of the most enjoyable programming experiences I've had in a long time. It took about a day and a half for the syntax and semantics to click
Gripping article, but his incorrect use of apostrophes made me want to an hero.