8 ms·

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 h

by MCRed 12y ago

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.

deleted 12y ago
[deleted]
j-conn 12y ago
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?
- perishabledave 12y ago
  Check out Seven Concurrency Models from Prag Prog. It does a good job of going over concurrency. It doesn't explicitly go over Node.js or Go's concurrency model, but it talks about the pitfalls of concurrency with shared memory and it also goes over the actor model, which is Erlang/Elixir model as well as Scala's Akka. https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in...
- MCRed 12y ago
  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 12y ago
    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 12y ago
      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.
saiko-chriskun 12y ago
Haskell is 'very new'?
- krenoten 12y ago
  Have any of the popular Haskell libraries for building distributed systems seen high-scale production use for more than 5 years?
- MCRed 12y ago
  Haskell's not new compared to Elixir which got it's 1.0 release last summer. It is new compared to erlang which has been around longer than the startup CEO in silicon valley has been alive. :-) Also "new" is one of those things that I think changes perspective with age. Probably when you're younger newer things seem more established than when you're older and looking at a longer time horizon. No offense meant to haskell. :-)
  - cgag 12y ago
    I don't really know how to compare these things since I don't think Haskell was really very useful at it's 1.0 release, but Haskell 1.0 came out in 1990, 4 years after Erlang, they're both pretty old.

by MCRed 12y ago

deleted 12y ago

[deleted]

j-conn 12y ago

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?

perishabledave 12y ago
Check out Seven Concurrency Models from Prag Prog. It does a good job of going over concurrency. It doesn't explicitly go over Node.js or Go's concurrency model, but it talks about the pitfalls of concurrency with shared memory and it also goes over the actor model, which is Erlang/Elixir model as well as Scala's Akka. https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in...
MCRed 12y ago
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 12y ago
  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 12y ago
    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.

saiko-chriskun 12y ago

Haskell is 'very new'?

krenoten 12y ago
Have any of the popular Haskell libraries for building distributed systems seen high-scale production use for more than 5 years?
MCRed 12y ago
Haskell's not new compared to Elixir which got it's 1.0 release last summer. It is new compared to erlang which has been around longer than the startup CEO in silicon valley has been alive. :-) Also "new" is one of those things that I think changes perspective with age. Probably when you're younger newer things seem more established than when you're older and looking at a longer time horizon. No offense meant to haskell. :-)
- cgag 12y ago
  I don't really know how to compare these things since I don't think Haskell was really very useful at it's 1.0 release, but Haskell 1.0 came out in 1990, 4 years after Erlang, they're both pretty old.