5 ms·

Elixir and the Internet of Things – Handling a Stampede

110 points by gigasquid 13y ago

wcummings 13y ago
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 13y ago
  It's quite funny, since the the backbone server operating principles we all use were developed at a telco anyways (hooray *nix!).
oijaf888 13y ago
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 13y ago
  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.
kungfooguru 13y ago
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 13y ago
  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.
iwasphone 13y ago
Gripping article, but his incorrect use of apostrophes made me want to an hero.
brassybadger 13y ago
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 13y ago
  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.
  - loxs 13y ago
    I second that. Although I only write Erlang, Elixir is the future.
  - klibertp 13y ago
    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.
Pxtl 13y ago
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.
- pivo 13y ago
  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
- lostcolony 13y ago
  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-Pragmatic-Programmers/dp/193778553X http://www.amazon.com/Programming-Erlang-Concurrent-Pragmati...
  - SkyMarshal 13y ago
    Also http://learnyousomeerlang.com/ http://learnyousomeerlang.com/.

110 points by gigasquid 13y ago

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 13y ago
It's quite funny, since the the backbone server operating principles we all use were developed at a telco anyways (hooray *nix!).

oijaf888 13y ago

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 13y ago
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.

kungfooguru 13y ago

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 13y ago
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.

iwasphone 13y ago

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

brassybadger 13y ago

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 13y ago
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.
- loxs 13y ago
  I second that. Although I only write Erlang, Elixir is the future.
- klibertp 13y ago
  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.

Pxtl 13y ago

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.

pivo 13y ago
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
lostcolony 13y ago
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-Pragmatic-Programmers/dp/193778553X http://www.amazon.com/Programming-Erlang-Concurrent-Pragmati...
- SkyMarshal 13y ago
  Also http://learnyousomeerlang.com/ http://learnyousomeerlang.com/.