9 ms·

Elixir – The next big language for the web

155 points by laut 11y ago

losvedir 11y ago
As a rails developer primarily, and someone dabbling with Elixir/Phoenix on the side, I get this feeling, too. It's taken the best of rails, dropped the annoying parts (e.g.: weird pluralization stuff, magic connection between instance variables in controllers and views, an explosion of path helpers (Phoenix's approach is basically post_path(:index), post_path(:show, 5), etc.)), and then put it on the rock solid Erlang VM. I remember hearing the "genesis story" of Elixir. IIRC, José was working on ensuring Rails was thread safe. He did so, but was dismayed with the difficulty and felt like he was fighting Ruby. So he stepped back, and thought that if concurrency is the future, he should find a better language for it. He looked into immutable, functional languages (Haskell, Clojure, Erlang), and realized that Erlang is built for an arguably harder problem: distributed computing, and made the connection that concurrency is sort of a smaller case of that. He worked with Erlang for awhile before deciding that it could be improved by building on it. Going through the Elixir tutorial and seeing how you could "simulate" state, by spinning up an infinite loop in another process and sending messages to it was mind bending. And learning about Erlang's OTP principles has made me really think about robustness differently. I really do hope Elixir/Phoenix become the next big language and web framework.
ksjjsk 11y ago
fukc offffff
- JustSomeNobody 11y ago
  I wish I could down vote...
  - DanBC 11y ago
    If you click the timestamp a "flag" option should appear. I think anyone can flag a post, and I think posts like that are what flag is meant for.
    - JustSomeNobody 11y ago
      Good to know. Thanks.
JustSomeNobody 11y ago
This isn't a criticism of Elixir (I've never used it, so I can't do that), but how can one just declare something "The Next Big" thing?
- laut 11y ago
  Author here. I wrote some reasons to why I think it is likely that it will be. It is not a sure thing of course.
  - JustSomeNobody 11y ago
    But that headline... :)
- davidddavidson 11y ago
  Did you read the article? The first sentence is literally: "In this article I will explain why I think the Elixir language will make a big impact in the world of web development."
  - JustSomeNobody 11y ago
    That's called backpedaling.
tatterdemalion 11y ago
I don't know much about Elixir but it seems like a really interesting language. The space it's trying to fit is definitely something needed: a good, flexible, high level language like Python/Ruby but with strong concurrency support and a functional paradigm. Can anyone give more information on the nature of Elixir's type system? Without digging into the docs I see elixer-lang says that its dynamically typed, but how strongly typed, is it robust, does it have ADTs, inheritance, etc? edit: looking an inch deeper, I see that it has 'protocols,' which seem like typeclasses, and 'typespecs,' which seem like gradual typing
- ryanworl 11y ago
  For type-safety, you can (optionally) add what are called type specs to your code with are processed with an analyzer tool called dialyzer [1]. This will identify errors related to types, as well as a few other kinds of errors. This doesn't work with Elixir directly, but rather BEAM byte code (Erlang VM) which Elixir compiles down to. [1]: http://www.erlang.org/doc/man/dialyzer.html http://www.erlang.org/doc/man/dialyzer.html
sergiotapia 11y ago
I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality.
- laut 11y ago
  Javascript has functional features too. A lot of Elixir developers come from platforms such as Python, Ruby, node.js
  - alco 11y ago
    JavaScript has functions. The list pretty much ends there. There are some libraries that provide "functional features" like functions over collections, persistent data structures, promises. The language itself and the environment it's running in (DOM or Node) do not have a lot going for them in terms of functional programming essentials.
- anonyfox 11y ago
  plus, you can use (or mix&match) other languages that compile to JS if you want. Coffeescript is the most popular choice (I code in literate coffeescript by myself), but stuff like livescript adds some more functional features as well.
- copsarebastards 11y ago
  1. "Realm-time" isn't baked in. It certainly comes easier to write real-time programs (for some definitions of real-time) than in some other environments, but real time programming doesn't come for free in any environment. You're overreaching with this claim. 2. Tons of programmers know JavaScript well enough to avoid it. A language originally thrown together "to make the monkey dance" is generally a poor choice. 3. Sane templating engines are a dime a dozen. I could probably find 5 in Python alone. 4. Same later realization that it's really good at a few things at the expense of others, I'd bet. 5. Okay I'll cede one point. > Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality. That says more about you than about the quality of tools involved. I'd rather have quality of mindshare than quantity.
amarsahinovic 11y ago
http://elixir-web.github.io/weber/ http://elixir-web.github.io/weber/
- adamkittelson 11y ago
  I used Weber when I first got into Elixir a little over a year ago. It was a cool framework and I even contributed to it (mostly keeping it up to date as new versions of Elixir were released). But... the last commit was 9 months ago. Weber is dead. If you're interested in doing web stuff with Elixir today Phoenix is what you want. http://www.phoenixframework.org/ http://www.phoenixframework.org/
  - yellowapple 11y ago
    Now would be a good time to plug Sugar, another framework for Elixir that's in active development. http://sugar-framework.github.io/ http://sugar-framework.github.io/ (disclaimer: I'm one of the collaborators on the project)
    - lectrick 11y ago
      Good luck! I think this is a great time to start a new Elixir framework, and competition (or perhaps, "coopetition") is good.
      - yellowapple 11y ago
        Thanks! "Coopetition" is certainly the goal, I think :)
cgag 11y ago
Does dialyzer work with elixir?
- laut 11y ago
  yes
- lectrick 11y ago
  "Elixir Sips" is a nice little screencast site showcasing and howto-ing various Elixir features. They have an episode on Dialyzer: http://elixirsips.com/episodes/125_dialyzer.html http://elixirsips.com/episodes/125_dialyzer.html
- alco 11y ago
  Elixir has first-class support for defining custom types and adding type annotations (specs) to functions. There's also a tool that makes it very easy to run dialyzer on your code: https://github.com/fishcakez/dialyze https://github.com/fishcakez/dialyze
pron 11y ago
Not about Elixir specifically, but don't people get tired of switching languages? What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO who gets a job at such an early-adopter company in 15 years, and finds out the codebase is made up of 7 different languages, four of them have been defunct for years? I mean, a language's benefit must at least cover all the switching costs, the fractured codebase costs and then some to justify adoption. Are all the new languages such huge advances over older ones that they do that?
- slayed0 11y ago
  I think the issue is that many CTO's don't take all of these factors into account when they do decide to switch to or add a new language to the companies codebase. It seems many are shortsighted and simply see A > B without evaluating all of the costs of switching from B to A.
- yellowapple 11y ago
  > Are all the new languages such huge advances over older ones that they do that? I don't know about other languages, but having personally migrated from Perl and Ruby to Erlang/Elixir, I at least believe that to be the case in that particular circumstance. A big part of it is that parallel programming is starting to catch on as mainstream rather than something to be shunned or avoided; whereas in the past folks were conditioned to avoid having to deal with threading or forking because of having to think about thread safety, there are now languages like Erlang (and its kids Elixir and LFE), Rust, Go, Scala, Julia, etc. that are meant to make parallel computing easier to reason about or less dangerous (or sometimes even both). On top of this, though, Erlang-and-kids' reliability features allow them to achieve the legendary "nine-nines" of uptime (99.9999999%) relatively easily (I say "relatively" because - while you certainly still have to think about it (particularly if you're trying to push a change to, say, how data is represented on the (D)ETS or Mnesia or CouchDB or SQL or whatever side of things) - it's much easier than with a lot of other languages). That level of availability has huge implications for a company's bottom line, particularly those companies that measure downtime in "thousands of dollars per second" instead of just seconds. A well-written Erlang/OTP (or Elixir/OTP or LFE/OTP or anything/OTP) application can do this on the software side rather effectively (on the hardware side, you'd still want redundancy wherever possible/feasible, including on the network side of things; most well-run hospitals, for example, will have connections with at least two different ISPs so that if one goes out, they still have the other, and will only lose connectivity in very extreme circumstances). In the case of Elixir, it makes for a very solid migration target from, say, a Rails codebase; the syntax is a bit more modern (I personally prefer Erlang's in many cases, but Elixir's pipe operator is a godsend) and familiar to Rubyists ("do" blocks, more flexible pipelining with the |> operator, etc.), while being fully compatible with the existing Erlang and growing Elixir ecosystems.
vezzy-fnord 11y ago
I think part of it is that with Erlang it is not as easy to get up and running with a new website. I'm doing this at present and there is no special difficulty. And things like package management, build tools, meta-programming, unicode handling and web frameworks are not as straight forward as in languages such as Ruby. Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. The rest - dependency management and building, is handled quite well by tools like Rebar. One can also leave Rebar as a dependency tool strictly (which is its primary purpose anyway) and use whatever they like for a build system. Plain old Makefiles can work just fine, and it's not like most language-targeted build systems aren't some shiny variation of make, anyway. Metaprogramming isn't quite as easy as in many OO languages, but it's hardly out of reach. The parser, the lexical scanner and other components are all exposed as Erlang modules, and there are projects such as the BossDB ORM that use parser transforms to provide features such as parameterized modules, which allow for using Rails-like ActiveRecord patterns, among other things. Unicode handling? I think this might be a knock on Erlang's string handling. Strings are represented as iolists of Unicode points (integers) which goes with much of Erlang's philosophy in lists and tuples as being the prime data types. Space efficiency and real-world usage usually has strings passed as binaries, but most web frameworks and libs can handle them plainly nonetheless. Web frameworks? Chicago Boss for a Rails-like, Nitrogen and N2O for real-time and extremely high load applications, or even just plugging in to web servers like Cowboy or Yaws can be enough for a RESTful backend.
- pawelkowal 11y ago
  > Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. Sure, modules provide a way to "package" functions, but that is 5% of what a package manager does. Being able to distribute, fetch and do dependency resolution is certainly the bulk of it. I definitely prefer my deployments to rely on packages than fetching git repositories from Github and Bitbucket. There are recent discussions in Erlang mailing list regarding packages and the OTP team (the team behind Erlang) is looking into package managers too. > The rest - dependency management and building, is handled quite well by tools like Rebar. Sorry, Rebar does not handle dependencies well. Rebar does not even guarantee repeatable builds. Once I fetch dependencies on my machine, my co-worker can end-up with versions different than mine and that is dependency management 101. Rebar 3 seems to improve in this area but is still alpha. erlang.mk idea of package manager is a file on github in tsv format (and still no repeatable builds). > Unicode handling? I think this might be a knock on Erlang's string handling. Erlang needs better unicode support, regardless of using lists or binaries. Strings support only latin1 in literal format. If I want to write my name as a binary, it needs to be written as <<"paweł"/utf8>>. This is nowhere close to acceptable to anyone that has to write strings in formats other than latin1. Things are getting better in Erlang 18 but there won't be any conveniences for handling unicode. There is no function to calculate the grapheme length (essential if you want to support languages like japanese or korean and do a size validation on an input), to convert to lowercase/uppercase and so on. Be it if the underlying representation is a list or a binary.
pbowyer 11y ago
Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?
- hackerboos 11y ago
  Can there only be 1 next big thing at a time?
  - pbowyer 11y ago
    When Rails came along it became the one big thing in the web world (something I look back at and wish the fanbois hadn't put me off so much). And looking at the state of competing and ever-growing landscape of Javascript frameworks, I'm not convinced multiple big things is better.
    - karmajunkie 11y ago
      I don't think its a matter of "multiple big things". Its a matter of having multiple solid options.
- bnchrch 11y ago
  I would like this answer as well. Both boast on their ability to handle concurrency. The main differences I see is that: 1. elixir is less strongly typed than go 2. elixir is more purely functional 3. elixir has a smaller community and is less backed
  - wcummings 11y ago
    The Elixir runtime (BEAM) is mature (20+ years old) and soft-realtime [1] [1] http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...
- dragonwriter 11y ago
  > Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Its a completely different language, with a completely different set of people thinking it is the way to go going forward. They have very little in common. > Or where Go didn't live up to its promises? As there are in the present, there will probably be more than one significant web application language in the future. Its not impossible that Go and Elixir could both be among them. Its not really an XOR type of situation.
filereaper 11y ago
I've been monitoring Elixir on HN for a while now, looks like an interesting direction to take. I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Is there a plan to change Rails enough to run on Elixir? How does the community feel about Elixir? I'm certainly interested in the concurrency aspects of Elixir (ie. no GIL) and everything else that Erlang has to offer. The developers of Elixir were core Rails developers so please forgive me if I'm getting the wrong impression here.
- dragonwriter 11y ago
  > I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Elixir is not even approximately compatible with Ruby, nor is it intended to be. It just has syntax that is very loosely reminiscent of Ruby. Someone might one day write a Rails-like framework for Elixir, but it will never be the same Rails that runs on Ruby. OTOH, if you want something no GIL that can run Rails, there is always JRuby.
- jtwebman 11y ago
  Rails is just one way to solve data problems. I don't see Rails being written in Elixir as it is not a functional way to solve that problem. Nothing against rails it is a good way to solve the problem in a modern object oriented way though Active Record has it's issues as well.
- yellowapple 11y ago
  > Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Most likely not. However, it might be possible to run Ruby programs in OTP-style supervision trees, thus managed by a supervisor written in Erlang or Elixir of LFE or some other BEAM-based language and thus made able to leverage some or all of the advantages of Erlang (a good potential proof-of-concept would be a replacement for Puma or Unicorn or Passenger - in other words, a Rack-compatible web server (or wrapper around an existing web server, like Cowboy) written in Elixir or Erlang or LFE or what have you). > Is there a plan to change Rails enough to run on Elixir? Also most likely not; most of the Rails community is currently heavily dependent on the Ruby ecosystem, and there's not really much of a point in changing that. That isn't to say that there's no place for Elixir in a Rails development framework; there are plenty of Rails shops that use Erlang for dispatching requests to Rails instances (I believe Github is one such shop). > How does the community feel about Elixir? The Elixir community obviously feels elated :) The Ruby/Rails crowd is a bit harder to read. I personally work for a Rails consultancy, and right now my coworkers don't seem universally interested in it quite yet. That may change in the future, though, especially as more folks realize the merits of using Elixir and Ruby side-by-side and more packages (whether from the Ruby side or the Elixir/Erlang side) are developed to allow easy communication between those two worlds. The Erlang community seems to be mildly positive about it. At least one of Erlang's original creators has expressed a modestly-positive opinion of Elixir's direction (with a particular excitement about Elixir's Clojure-inspired "|>" (pipe) operator - something that a lot of Elixirists seem to like using, myself included). There's some deviation from the more Erlangy ways of doing things, however, and it's not as mature as Erlang itself, so (from what I understand based on my observations of the Erlang community - particularly mailing lists and conference recordings/transcripts) there's still a bit of resistance there.
ksec 11y ago
I thought Erlang was abandon within Ericsson, and it was Open Sourced so people can continue to use it. Can anyone explain what is Erlang Public License? Why not something like Apache, GPL or MIT?
- yellowapple 11y ago
  > I thought Erlang was abandon within Ericsson, and it was Open Sourced so people can continue to use it. It was temporarily "abandoned" because Ericsson had (has?) a policy forbidding the use of non-free languages. In response, the Erlang devs open-sourced it, and now (IIRC) it's not banned anymore. > Can anyone explain what is Erlang Public License? It's derived from the Mozilla Public License. It differs mainly in terms of legal jurisdiction (i.e. Swedish law being specified as the applicable legal jurisdiction). > Why not something like Apache, GPL or MIT? Good question. The answer's probably similar to the reasons why Mozilla created the MPL (partial copyleft, in contrast with the GPL's strict copyleft, and with the Apache's and MIT's and BSD's and crowd's copycenter/copyfree).
- alco 11y ago
  Erlang/OTP is being developed continuously, primarily by a team at Ericsson. They ship one new major release roughly once per year, with a few minor releases in-between.
deleted 11y ago
[deleted]

155 points by laut 11y ago

As a rails developer primarily, and someone dabbling with Elixir/Phoenix on the side, I get this feeling, too. It's taken the best of rails, dropped the annoying parts (e.g.: weird pluralization stuff, magic connection between instance variables in controllers and views, an explosion of path helpers (Phoenix's approach is basically post_path(:index), post_path(:show, 5), etc.)), and then put it on the rock solid Erlang VM. I remember hearing the "genesis story" of Elixir. IIRC, José was working on ensuring Rails was thread safe. He did so, but was dismayed with the difficulty and felt like he was fighting Ruby. So he stepped back, and thought that if concurrency is the future, he should find a better language for it. He looked into immutable, functional languages (Haskell, Clojure, Erlang), and realized that Erlang is built for an arguably harder problem: distributed computing, and made the connection that concurrency is sort of a smaller case of that. He worked with Erlang for awhile before deciding that it could be improved by building on it. Going through the Elixir tutorial and seeing how you could "simulate" state, by spinning up an infinite loop in another process and sending messages to it was mind bending. And learning about Erlang's OTP principles has made me really think about robustness differently. I really do hope Elixir/Phoenix become the next big language and web framework.

ksjjsk 11y ago

fukc offffff

JustSomeNobody 11y ago
I wish I could down vote...
- DanBC 11y ago
  If you click the timestamp a "flag" option should appear. I think anyone can flag a post, and I think posts like that are what flag is meant for.
  - JustSomeNobody 11y ago
    Good to know. Thanks.

JustSomeNobody 11y ago

This isn't a criticism of Elixir (I've never used it, so I can't do that), but how can one just declare something "The Next Big" thing?

laut 11y ago
Author here. I wrote some reasons to why I think it is likely that it will be. It is not a sure thing of course.
- JustSomeNobody 11y ago
  But that headline... :)
davidddavidson 11y ago
Did you read the article? The first sentence is literally: "In this article I will explain why I think the Elixir language will make a big impact in the world of web development."
- JustSomeNobody 11y ago
  That's called backpedaling.

tatterdemalion 11y ago

I don't know much about Elixir but it seems like a really interesting language. The space it's trying to fit is definitely something needed: a good, flexible, high level language like Python/Ruby but with strong concurrency support and a functional paradigm. Can anyone give more information on the nature of Elixir's type system? Without digging into the docs I see elixer-lang says that its dynamically typed, but how strongly typed, is it robust, does it have ADTs, inheritance, etc? edit: looking an inch deeper, I see that it has 'protocols,' which seem like typeclasses, and 'typespecs,' which seem like gradual typing

ryanworl 11y ago
For type-safety, you can (optionally) add what are called type specs to your code with are processed with an analyzer tool called dialyzer [1]. This will identify errors related to types, as well as a few other kinds of errors. This doesn't work with Elixir directly, but rather BEAM byte code (Erlang VM) which Elixir compiles down to. [1]: http://www.erlang.org/doc/man/dialyzer.html http://www.erlang.org/doc/man/dialyzer.html

sergiotapia 11y ago

I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality.

laut 11y ago
Javascript has functional features too. A lot of Elixir developers come from platforms such as Python, Ruby, node.js
- alco 11y ago
  JavaScript has functions. The list pretty much ends there. There are some libraries that provide "functional features" like functions over collections, persistent data structures, promises. The language itself and the environment it's running in (DOM or Node) do not have a lot going for them in terms of functional programming essentials.
anonyfox 11y ago
plus, you can use (or mix&match) other languages that compile to JS if you want. Coffeescript is the most popular choice (I code in literate coffeescript by myself), but stuff like livescript adds some more functional features as well.
copsarebastards 11y ago
1. "Realm-time" isn't baked in. It certainly comes easier to write real-time programs (for some definitions of real-time) than in some other environments, but real time programming doesn't come for free in any environment. You're overreaching with this claim. 2. Tons of programmers know JavaScript well enough to avoid it. A language originally thrown together "to make the monkey dance" is generally a poor choice. 3. Sane templating engines are a dime a dozen. I could probably find 5 in Python alone. 4. Same later realization that it's really good at a few things at the expense of others, I'd bet. 5. Okay I'll cede one point. > Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality. That says more about you than about the quality of tools involved. I'd rather have quality of mindshare than quantity.

amarsahinovic 11y ago

http://elixir-web.github.io/weber/ http://elixir-web.github.io/weber/

adamkittelson 11y ago
I used Weber when I first got into Elixir a little over a year ago. It was a cool framework and I even contributed to it (mostly keeping it up to date as new versions of Elixir were released). But... the last commit was 9 months ago. Weber is dead. If you're interested in doing web stuff with Elixir today Phoenix is what you want. http://www.phoenixframework.org/ http://www.phoenixframework.org/
- yellowapple 11y ago
  Now would be a good time to plug Sugar, another framework for Elixir that's in active development. http://sugar-framework.github.io/ http://sugar-framework.github.io/ (disclaimer: I'm one of the collaborators on the project)
  - lectrick 11y ago
    Good luck! I think this is a great time to start a new Elixir framework, and competition (or perhaps, "coopetition") is good.
    - yellowapple 11y ago
      Thanks! "Coopetition" is certainly the goal, I think :)

cgag 11y ago

Does dialyzer work with elixir?

laut 11y ago
yes
lectrick 11y ago
"Elixir Sips" is a nice little screencast site showcasing and howto-ing various Elixir features. They have an episode on Dialyzer: http://elixirsips.com/episodes/125_dialyzer.html http://elixirsips.com/episodes/125_dialyzer.html
alco 11y ago
Elixir has first-class support for defining custom types and adding type annotations (specs) to functions. There's also a tool that makes it very easy to run dialyzer on your code: https://github.com/fishcakez/dialyze https://github.com/fishcakez/dialyze

pron 11y ago

Not about Elixir specifically, but don't people get tired of switching languages? What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO who gets a job at such an early-adopter company in 15 years, and finds out the codebase is made up of 7 different languages, four of them have been defunct for years? I mean, a language's benefit must at least cover all the switching costs, the fractured codebase costs and then some to justify adoption. Are all the new languages such huge advances over older ones that they do that?

slayed0 11y ago
I think the issue is that many CTO's don't take all of these factors into account when they do decide to switch to or add a new language to the companies codebase. It seems many are shortsighted and simply see A > B without evaluating all of the costs of switching from B to A.
yellowapple 11y ago
> Are all the new languages such huge advances over older ones that they do that? I don't know about other languages, but having personally migrated from Perl and Ruby to Erlang/Elixir, I at least believe that to be the case in that particular circumstance. A big part of it is that parallel programming is starting to catch on as mainstream rather than something to be shunned or avoided; whereas in the past folks were conditioned to avoid having to deal with threading or forking because of having to think about thread safety, there are now languages like Erlang (and its kids Elixir and LFE), Rust, Go, Scala, Julia, etc. that are meant to make parallel computing easier to reason about or less dangerous (or sometimes even both). On top of this, though, Erlang-and-kids' reliability features allow them to achieve the legendary "nine-nines" of uptime (99.9999999%) relatively easily (I say "relatively" because - while you certainly still have to think about it (particularly if you're trying to push a change to, say, how data is represented on the (D)ETS or Mnesia or CouchDB or SQL or whatever side of things) - it's much easier than with a lot of other languages). That level of availability has huge implications for a company's bottom line, particularly those companies that measure downtime in "thousands of dollars per second" instead of just seconds. A well-written Erlang/OTP (or Elixir/OTP or LFE/OTP or anything/OTP) application can do this on the software side rather effectively (on the hardware side, you'd still want redundancy wherever possible/feasible, including on the network side of things; most well-run hospitals, for example, will have connections with at least two different ISPs so that if one goes out, they still have the other, and will only lose connectivity in very extreme circumstances). In the case of Elixir, it makes for a very solid migration target from, say, a Rails codebase; the syntax is a bit more modern (I personally prefer Erlang's in many cases, but Elixir's pipe operator is a godsend) and familiar to Rubyists ("do" blocks, more flexible pipelining with the |> operator, etc.), while being fully compatible with the existing Erlang and growing Elixir ecosystems.

vezzy-fnord 11y ago

I think part of it is that with Erlang it is not as easy to get up and running with a new website. I'm doing this at present and there is no special difficulty. And things like package management, build tools, meta-programming, unicode handling and web frameworks are not as straight forward as in languages such as Ruby. Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. The rest - dependency management and building, is handled quite well by tools like Rebar. One can also leave Rebar as a dependency tool strictly (which is its primary purpose anyway) and use whatever they like for a build system. Plain old Makefiles can work just fine, and it's not like most language-targeted build systems aren't some shiny variation of make, anyway. Metaprogramming isn't quite as easy as in many OO languages, but it's hardly out of reach. The parser, the lexical scanner and other components are all exposed as Erlang modules, and there are projects such as the BossDB ORM that use parser transforms to provide features such as parameterized modules, which allow for using Rails-like ActiveRecord patterns, among other things. Unicode handling? I think this might be a knock on Erlang's string handling. Strings are represented as iolists of Unicode points (integers) which goes with much of Erlang's philosophy in lists and tuples as being the prime data types. Space efficiency and real-world usage usually has strings passed as binaries, but most web frameworks and libs can handle them plainly nonetheless. Web frameworks? Chicago Boss for a Rails-like, Nitrogen and N2O for real-time and extremely high load applications, or even just plugging in to web servers like Cowboy or Yaws can be enough for a RESTful backend.

pawelkowal 11y ago
> Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. Sure, modules provide a way to "package" functions, but that is 5% of what a package manager does. Being able to distribute, fetch and do dependency resolution is certainly the bulk of it. I definitely prefer my deployments to rely on packages than fetching git repositories from Github and Bitbucket. There are recent discussions in Erlang mailing list regarding packages and the OTP team (the team behind Erlang) is looking into package managers too. > The rest - dependency management and building, is handled quite well by tools like Rebar. Sorry, Rebar does not handle dependencies well. Rebar does not even guarantee repeatable builds. Once I fetch dependencies on my machine, my co-worker can end-up with versions different than mine and that is dependency management 101. Rebar 3 seems to improve in this area but is still alpha. erlang.mk idea of package manager is a file on github in tsv format (and still no repeatable builds). > Unicode handling? I think this might be a knock on Erlang's string handling. Erlang needs better unicode support, regardless of using lists or binaries. Strings support only latin1 in literal format. If I want to write my name as a binary, it needs to be written as <<"paweł"/utf8>>. This is nowhere close to acceptable to anyone that has to write strings in formats other than latin1. Things are getting better in Erlang 18 but there won't be any conveniences for handling unicode. There is no function to calculate the grapheme length (essential if you want to support languages like japanese or korean and do a size validation on an input), to convert to lowercase/uppercase and so on. Be it if the underlying representation is a list or a binary.

pbowyer 11y ago

Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?

hackerboos 11y ago
Can there only be 1 next big thing at a time?
- pbowyer 11y ago
  When Rails came along it became the one big thing in the web world (something I look back at and wish the fanbois hadn't put me off so much). And looking at the state of competing and ever-growing landscape of Javascript frameworks, I'm not convinced multiple big things is better.
  - karmajunkie 11y ago
    I don't think its a matter of "multiple big things". Its a matter of having multiple solid options.
bnchrch 11y ago
I would like this answer as well. Both boast on their ability to handle concurrency. The main differences I see is that: 1. elixir is less strongly typed than go 2. elixir is more purely functional 3. elixir has a smaller community and is less backed
- wcummings 11y ago
  The Elixir runtime (BEAM) is mature (20+ years old) and soft-realtime [1] [1] http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...
dragonwriter 11y ago
> Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Its a completely different language, with a completely different set of people thinking it is the way to go going forward. They have very little in common. > Or where Go didn't live up to its promises? As there are in the present, there will probably be more than one significant web application language in the future. Its not impossible that Go and Elixir could both be among them. Its not really an XOR type of situation.

filereaper 11y ago

I've been monitoring Elixir on HN for a while now, looks like an interesting direction to take. I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Is there a plan to change Rails enough to run on Elixir? How does the community feel about Elixir? I'm certainly interested in the concurrency aspects of Elixir (ie. no GIL) and everything else that Erlang has to offer. The developers of Elixir were core Rails developers so please forgive me if I'm getting the wrong impression here.

dragonwriter 11y ago
> I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Elixir is not even approximately compatible with Ruby, nor is it intended to be. It just has syntax that is very loosely reminiscent of Ruby. Someone might one day write a Rails-like framework for Elixir, but it will never be the same Rails that runs on Ruby. OTOH, if you want something no GIL that can run Rails, there is always JRuby.
jtwebman 11y ago
Rails is just one way to solve data problems. I don't see Rails being written in Elixir as it is not a functional way to solve that problem. Nothing against rails it is a good way to solve the problem in a modern object oriented way though Active Record has it's issues as well.
yellowapple 11y ago
> Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Most likely not. However, it might be possible to run Ruby programs in OTP-style supervision trees, thus managed by a supervisor written in Erlang or Elixir of LFE or some other BEAM-based language and thus made able to leverage some or all of the advantages of Erlang (a good potential proof-of-concept would be a replacement for Puma or Unicorn or Passenger - in other words, a Rack-compatible web server (or wrapper around an existing web server, like Cowboy) written in Elixir or Erlang or LFE or what have you). > Is there a plan to change Rails enough to run on Elixir? Also most likely not; most of the Rails community is currently heavily dependent on the Ruby ecosystem, and there's not really much of a point in changing that. That isn't to say that there's no place for Elixir in a Rails development framework; there are plenty of Rails shops that use Erlang for dispatching requests to Rails instances (I believe Github is one such shop). > How does the community feel about Elixir? The Elixir community obviously feels elated :) The Ruby/Rails crowd is a bit harder to read. I personally work for a Rails consultancy, and right now my coworkers don't seem universally interested in it quite yet. That may change in the future, though, especially as more folks realize the merits of using Elixir and Ruby side-by-side and more packages (whether from the Ruby side or the Elixir/Erlang side) are developed to allow easy communication between those two worlds. The Erlang community seems to be mildly positive about it. At least one of Erlang's original creators has expressed a modestly-positive opinion of Elixir's direction (with a particular excitement about Elixir's Clojure-inspired "|>" (pipe) operator - something that a lot of Elixirists seem to like using, myself included). There's some deviation from the more Erlangy ways of doing things, however, and it's not as mature as Erlang itself, so (from what I understand based on my observations of the Erlang community - particularly mailing lists and conference recordings/transcripts) there's still a bit of resistance there.

ksec 11y ago

I thought Erlang was abandon within Ericsson, and it was Open Sourced so people can continue to use it. Can anyone explain what is Erlang Public License? Why not something like Apache, GPL or MIT?

yellowapple 11y ago
> I thought Erlang was abandon within Ericsson, and it was Open Sourced so people can continue to use it. It was temporarily "abandoned" because Ericsson had (has?) a policy forbidding the use of non-free languages. In response, the Erlang devs open-sourced it, and now (IIRC) it's not banned anymore. > Can anyone explain what is Erlang Public License? It's derived from the Mozilla Public License. It differs mainly in terms of legal jurisdiction (i.e. Swedish law being specified as the applicable legal jurisdiction). > Why not something like Apache, GPL or MIT? Good question. The answer's probably similar to the reasons why Mozilla created the MPL (partial copyleft, in contrast with the GPL's strict copyleft, and with the Apache's and MIT's and BSD's and crowd's copycenter/copyfree).
alco 11y ago
Erlang/OTP is being developed continuously, primarily by a team at Ericsson. They ship one new major release roughly once per year, with a few minor releases in-between.

deleted 11y ago

[deleted]