3 ms·

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 li

by pbowyer 12y 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 12y ago
Can there only be 1 next big thing at a time?
- pbowyer 12y 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 12y ago
    I don't think its a matter of "multiple big things". Its a matter of having multiple solid options.
bnchrch 12y 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 12y 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 12y 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.
lectrick 12y ago
Some of this is opinion, but I looked at Go and didn't like its exception model (or total lack thereof). Checking for errors after every possible bit of code that could go wrong seemed like an ugliness to me (disclaimer: beauty is in the eye of the beholder, and I'm certain a Go guy will chirp up here in its defense... which is fine!). Elixir/Erlang almost couldn't be more different in this regard, which basically embrace runtime failures (things fail, so... "Let it fail quickly"). An uncaught runtime error in Elixir/Erlang causes the node to shut down after logging the error and, if it has a supervisor node (which is quite likely), the node is restarted in a fraction of a microsecond. The developer is expected to monitor the logs and watch for common faults and fix those. This is in fact where the "nine nines" reliability comes from- restarting nodes extremely quickly after runtime errors. The Erlang philosophy is basically, "these systems exist in the real world, which is sometimes unpredictable and flaky... accept it and allow the code to move on quickly." This happens to be a good strategy for website code- Remember that Erlang was built to run cell networks... How often are cell networks down these days? I was also a "disenfranchised" Ruby guy, tired of working on classes of bugs that would never even see the light of day in a functional language, which is why Elixir's syntax was appealing (I had already looked at Erlang, but I didn't like its syntax). Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late. There's a class of programmers who don't care about syntax or don't see the point of it. Ruby/Rails folks are not typically that type of programmer, and that's the first group who will likely migrate to Elixir. Finally, what really raised my eyebrows about Elixir was its macro facility http://elixir-lang.org/getting-started/meta/macros.html http://elixir-lang.org/getting-started/meta/macros.html Prior to Elixir, full-fledged macros were only a feature of homoiconic languages (the Lispy ones where the syntax is also a data structure). Elixir came up with a clever way to do macros, while retaining syntax.
- pbowyer 12y ago
  Thanks, that's a really helpful answer. > Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late. I agree and that's a really enlightened view. But I'm quite glad - it means the ecosystem is maturing if we now can be fashion driven, rather than having to care about "does it work?"
copsarebastards 12y ago
I think it's too early to tell whether Go will live up to it's promises. However, the promises of Go are generally shit: Go has promised to help us relive the horrors of static code generation and empty interfaces in exchange for being able to compile our shitty code quickly. I'm also not sure elixir is so great (not enough experience with the language and no time to try it right now) but at least at a glance it seems to put a cleaner face on some of Erlang's strengths, so at least it brings something new to the table.

by pbowyer 12y 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 12y ago

Can there only be 1 next big thing at a time?

pbowyer 12y 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 12y ago
  I don't think its a matter of "multiple big things". Its a matter of having multiple solid options.

bnchrch 12y 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 12y 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 12y 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.

lectrick 12y ago

Some of this is opinion, but I looked at Go and didn't like its exception model (or total lack thereof). Checking for errors after every possible bit of code that could go wrong seemed like an ugliness to me (disclaimer: beauty is in the eye of the beholder, and I'm certain a Go guy will chirp up here in its defense... which is fine!). Elixir/Erlang almost couldn't be more different in this regard, which basically embrace runtime failures (things fail, so... "Let it fail quickly"). An uncaught runtime error in Elixir/Erlang causes the node to shut down after logging the error and, if it has a supervisor node (which is quite likely), the node is restarted in a fraction of a microsecond. The developer is expected to monitor the logs and watch for common faults and fix those. This is in fact where the "nine nines" reliability comes from- restarting nodes extremely quickly after runtime errors. The Erlang philosophy is basically, "these systems exist in the real world, which is sometimes unpredictable and flaky... accept it and allow the code to move on quickly." This happens to be a good strategy for website code- Remember that Erlang was built to run cell networks... How often are cell networks down these days? I was also a "disenfranchised" Ruby guy, tired of working on classes of bugs that would never even see the light of day in a functional language, which is why Elixir's syntax was appealing (I had already looked at Erlang, but I didn't like its syntax). Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late. There's a class of programmers who don't care about syntax or don't see the point of it. Ruby/Rails folks are not typically that type of programmer, and that's the first group who will likely migrate to Elixir. Finally, what really raised my eyebrows about Elixir was its macro facility http://elixir-lang.org/getting-started/meta/macros.html http://elixir-lang.org/getting-started/meta/macros.html Prior to Elixir, full-fledged macros were only a feature of homoiconic languages (the Lispy ones where the syntax is also a data structure). Elixir came up with a clever way to do macros, while retaining syntax.

pbowyer 12y ago
Thanks, that's a really helpful answer. > Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late. I agree and that's a really enlightened view. But I'm quite glad - it means the ecosystem is maturing if we now can be fashion driven, rather than having to care about "does it work?"

copsarebastards 12y ago

I think it's too early to tell whether Go will live up to it's promises. However, the promises of Go are generally shit: Go has promised to help us relive the horrors of static code generation and empty interfaces in exchange for being able to compile our shitty code quickly. I'm also not sure elixir is so great (not enough experience with the language and no time to try it right now) but at least at a glance it seems to put a cleaner face on some of Erlang's strengths, so at least it brings something new to the table.