8 ms·

If you were choosing today, would you recommend choosing Elixir over Go for web/back-end development? Would you say Go is more suited for high-performance comma

by lpsz 11y ago

If you were choosing today, would you recommend choosing Elixir over Go for web/back-end development? Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff? I'm an indie developer building such a back-end (social networking/chat space), have full choice of language. Started using Go earlier this year and mostly happy with it. Should I switch to Elixir in my next iteration? Would it make me more productive, or save me from various deployment hurdles in long-term? (Please don't take this as one of those mostly aimless "Hey, is Ruby or Python better?" type of questions. I hate those myself. I'm going to be investing thousands of hours into Go at this point. Hoping for some serious pro-vs-con discussion, hoping people who have architected something big in either language could chime in -- such is the major plus of asking on HN.) I tried Googling, and the best/most recent I found was this thread. [1] [1] https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_compare_to_elixir/ https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_...

kamac 11y ago
Out of curiosity, which libs/frameworks are you using in Go? (that are web related)
- lpsz 11y ago
  Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla. Using "lib/pq" (Postgres) for the db. Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet. Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)
  - kamac 11y ago
    Relating to redeploying code, did you give https://github.com/codegangsta/gin https://github.com/codegangsta/gin a look? Also, any particular reason to not use a web framework such as gin-gonic for routing and templating? It simplifies some things down for me.
    - lpsz 11y ago
      Re: gin, thanks for the tip. I feel like this one makes more sense in development than in production, would like to avoid side effects (first HTTP request restarts the server), also an extra proxy layer. Re: web framework. Absolutely, no intention to reinvent the wheel. Just informative to rewrite various pieces in the initial stages to get a better grasp on the language/patterns.
      - kamac 11y ago
        About gin, you're right, I think. But what else to use in case the app crashes? A simple shell script to restart the executable whenever it crashes (even though it shouldn't)? :) And what about hot code reloads? You'd have to stop the app for a second there, and replace the executable yourself. You'd also probably interrupt whatever the app was doing at the time, which could turn out pretty bad.
        lpsz 11y ago
        I use upstart to respawn if crashes, but there's definitely more than one way to solve this one :) Hot code reloads is the more interesting issue.
  - rubiquity 11y ago
    > Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet. Elixir does nicely here, too. For caching, ets[0] tables are very easy to setup. For reload, you can use IEx to connect to a remote node and do whatever you need to do. 0 - http://www.erlang.org/doc/man/ets.html http://www.erlang.org/doc/man/ets.html
  - elithrar 11y ago
    > Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla. Good pick. The gorilla toolkit is definitely flexible. I typically use a mix of gorilla (context, csrf, schema) and Goji (routing, middleware chaining). My 'hard and fast rule' is that everything needs to implement the http.Handler interface if I'm going to use it, so I don't get abandoned with a bunch of custom libraries that I need to refactor away from. > Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.) Most typically use the system's init daemon, and/or Supervisor/Circus/monit. I'm partial to Supervisor on that front for the cross-platform compat.
aaron-lebo 11y ago
Elixir, in my experience, is a much more productive and powerful language. If you are a one-man-show I'd pick Elixir any day. Here I am pimping my own stuff but I wrote a related article on this: http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-an-alternative-to-go.html http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-...
- lpsz 11y ago
  Thanks, I actually read! "The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps." I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go, and so many intro examples focus on that.
  - MCRed 11y ago
    And elixir/erlang are great for writing custom servers handling custom protocols.... but you're better off just dropping in Cowboy and working at a higher level. Go is really compelling in producing a single-binary application... but for web apps, I think Elixir wins because it's working at a much higher level, and thus you're more productive.
- otis_inf 11y ago
  That was a great read, thanks for sharing!
encoderer 11y ago
All of our servers and daemons at Cronitor have been built using Python. I know you're asking just about these two languages but i would consider a language with a bigger library and user base. It takes discipline with language features but we've had a lot of success writing stateless daemons that are under heavy load 24/7. It's been far easier to think from a fan-out pov vs worrying about every clock cycle wasted by, for example, the garbage collector.
tbrooks 11y ago
I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir: Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc. BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9 9's of reliability and scaled WhatsApp to millions of simultaneous connections. HEX: like Rubygems was for Ruby, Elixir/Erlang has a budding package management system via Hex. Hopefully this becomes the canonical source for libraries. Phoenix: Rails popularized Ruby and became the framework of choice for quickly and pragmatically developing CRUD apps. Phoenix has Rails-like conventions in building an Elixir app and has built in support for websockets. This framework is built for today's technology. Syntax: Coming from Ruby, the Elixir syntax is approachable and understandable. It's easy to jump into without having much prior knowledge. Kinda subjective, but those are reasons why I'm excited and choosing Elixir to build future projects upon.
- nathan_long 11y ago
  One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success. By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant. That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208 https://twitter.com/josevalim/status/621933537009246208
  - davelnewton 11y ago
    Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here. Elixir's functionality comes from BEAM and the language, not Erlang.
    - strmpnk 11y ago
stock_toaster 11y ago
One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc). After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly.
- lpsz 11y ago
  Yes, and the standard Go workspace layout (and therefore not even needing a makefile) is great.
- rubiquity 11y ago
  Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.
  - nailer 11y ago
    Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.
    - rubiquity 11y ago
      There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deployment http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy... Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go. 0 - https://github.com/bitwalker/exrm https://github.com/bitwalker/exrm 1 - https://github.com/smpallen99/exrm-rpm https://github.com/smpallen99/exrm-rpm
namelezz 11y ago
You are probably more productive in Elixir at the early stage of development. However, I personally think Go would be better for long-term development because it is statically typed. You can read more about pros and cons of statically and dynamically type languages [1] [1] http://programmers.stackexchange.com/questions/122205/what-is-the-supposed-productivity-gain-of-dynamic-typing http://programmers.stackexchange.com/questions/122205/what-i...
- josevalim 11y ago
  The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime. Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...). I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting. Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.
  - niklasni1 11y ago
    > The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? They're both statically typed, but the type systems obviously aren't equal. I would argue that stricter types are in fact one of the main things that helps me be more productive in languages with MLish type systems compared to C which lacks e.g. generics and proper sum types. That said, I find Elixir very interesting for the exact reasons you said.
deleted 11y ago
[deleted]
walterstucco 11y ago
No, I won't! I would advice you to learn them both instead, they are on such opposite sides, than knowing both will expand your knowledge in a very fulfilling way.
- happywolf 11y ago
  Nice insight. Learning more languages, especially those that seem to be different, could widen one's perspectives, and able to avoid the issue of learning only hammer and treat all problems as nails.
bjourne 11y ago
My advice would be to find out for yourself and don't believe the hype: > Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff? Like Go isn't very high performance. See for yourself: http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/ (I know, lies, damn lies and benchmarks, but it's the best we got!). Elixir is it good for marathons because it's based on Erlang and Ericsson claims six nines uptime? Just use the tech you find is most FUN to work with because it's better to have fun programming than being bored.
- jtwebman 11y ago
  Also it depends on the system you are building. Elixir and Erlang scale great and send messages even between servers fast! So if you need to scale it is great. Go I am sure is faster performance wiz but Elixir/Erlang will stay running longer and be easier to reason about as the system gets bigger. Go will be easier to find devs then Elixir/Erlang will be harder. So there are trade offs. In the end you could use both, use the right tool for the job.

by lpsz 11y ago

kamac 11y ago

Out of curiosity, which libs/frameworks are you using in Go? (that are web related)

lpsz 11y ago
Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla. Using "lib/pq" (Postgres) for the db. Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet. Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)
- kamac 11y ago
  Relating to redeploying code, did you give https://github.com/codegangsta/gin https://github.com/codegangsta/gin a look? Also, any particular reason to not use a web framework such as gin-gonic for routing and templating? It simplifies some things down for me.
  - lpsz 11y ago
    Re: gin, thanks for the tip. I feel like this one makes more sense in development than in production, would like to avoid side effects (first HTTP request restarts the server), also an extra proxy layer. Re: web framework. Absolutely, no intention to reinvent the wheel. Just informative to rewrite various pieces in the initial stages to get a better grasp on the language/patterns.
    - kamac 11y ago
      About gin, you're right, I think. But what else to use in case the app crashes? A simple shell script to restart the executable whenever it crashes (even though it shouldn't)? :) And what about hot code reloads? You'd have to stop the app for a second there, and replace the executable yourself. You'd also probably interrupt whatever the app was doing at the time, which could turn out pretty bad.
      - lpsz 11y ago
        I use upstart to respawn if crashes, but there's definitely more than one way to solve this one :) Hot code reloads is the more interesting issue.
- rubiquity 11y ago
  > Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet. Elixir does nicely here, too. For caching, ets[0] tables are very easy to setup. For reload, you can use IEx to connect to a remote node and do whatever you need to do. 0 - http://www.erlang.org/doc/man/ets.html http://www.erlang.org/doc/man/ets.html
- elithrar 11y ago
  > Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla. Good pick. The gorilla toolkit is definitely flexible. I typically use a mix of gorilla (context, csrf, schema) and Goji (routing, middleware chaining). My 'hard and fast rule' is that everything needs to implement the http.Handler interface if I'm going to use it, so I don't get abandoned with a bunch of custom libraries that I need to refactor away from. > Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.) Most typically use the system's init daemon, and/or Supervisor/Circus/monit. I'm partial to Supervisor on that front for the cross-platform compat.

aaron-lebo 11y ago

Elixir, in my experience, is a much more productive and powerful language. If you are a one-man-show I'd pick Elixir any day. Here I am pimping my own stuff but I wrote a related article on this: http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-an-alternative-to-go.html http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-...

lpsz 11y ago
Thanks, I actually read! "The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps." I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go, and so many intro examples focus on that.
- MCRed 11y ago
  And elixir/erlang are great for writing custom servers handling custom protocols.... but you're better off just dropping in Cowboy and working at a higher level. Go is really compelling in producing a single-binary application... but for web apps, I think Elixir wins because it's working at a much higher level, and thus you're more productive.
otis_inf 11y ago
That was a great read, thanks for sharing!

encoderer 11y ago

All of our servers and daemons at Cronitor have been built using Python. I know you're asking just about these two languages but i would consider a language with a bigger library and user base. It takes discipline with language features but we've had a lot of success writing stateless daemons that are under heavy load 24/7. It's been far easier to think from a fan-out pov vs worrying about every clock cycle wasted by, for example, the garbage collector.

tbrooks 11y ago

I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir: Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc. BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9 9's of reliability and scaled WhatsApp to millions of simultaneous connections. HEX: like Rubygems was for Ruby, Elixir/Erlang has a budding package management system via Hex. Hopefully this becomes the canonical source for libraries. Phoenix: Rails popularized Ruby and became the framework of choice for quickly and pragmatically developing CRUD apps. Phoenix has Rails-like conventions in building an Elixir app and has built in support for websockets. This framework is built for today's technology. Syntax: Coming from Ruby, the Elixir syntax is approachable and understandable. It's easy to jump into without having much prior knowledge. Kinda subjective, but those are reasons why I'm excited and choosing Elixir to build future projects upon.

nathan_long 11y ago
One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success. By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant. That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208 https://twitter.com/josevalim/status/621933537009246208
- davelnewton 11y ago
  Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here. Elixir's functionality comes from BEAM and the language, not Erlang.
  - strmpnk 11y ago

stock_toaster 11y ago

One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc). After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly.

lpsz 11y ago
Yes, and the standard Go workspace layout (and therefore not even needing a makefile) is great.
rubiquity 11y ago
Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.
- nailer 11y ago
  Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.
  - rubiquity 11y ago
    There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deployment http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy... Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go. 0 - https://github.com/bitwalker/exrm https://github.com/bitwalker/exrm 1 - https://github.com/smpallen99/exrm-rpm https://github.com/smpallen99/exrm-rpm

namelezz 11y ago

You are probably more productive in Elixir at the early stage of development. However, I personally think Go would be better for long-term development because it is statically typed. You can read more about pros and cons of statically and dynamically type languages [1] [1] http://programmers.stackexchange.com/questions/122205/what-is-the-supposed-productivity-gain-of-dynamic-typing http://programmers.stackexchange.com/questions/122205/what-i...

josevalim 11y ago
The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime. Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...). I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting. Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.
- niklasni1 11y ago
  > The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? They're both statically typed, but the type systems obviously aren't equal. I would argue that stricter types are in fact one of the main things that helps me be more productive in languages with MLish type systems compared to C which lacks e.g. generics and proper sum types. That said, I find Elixir very interesting for the exact reasons you said.

deleted 11y ago

[deleted]

walterstucco 11y ago

No, I won't! I would advice you to learn them both instead, they are on such opposite sides, than knowing both will expand your knowledge in a very fulfilling way.

happywolf 11y ago
Nice insight. Learning more languages, especially those that seem to be different, could widen one's perspectives, and able to avoid the issue of learning only hammer and treat all problems as nails.

bjourne 11y ago

My advice would be to find out for yourself and don't believe the hype: > Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff? Like Go isn't very high performance. See for yourself: http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/ (I know, lies, damn lies and benchmarks, but it's the best we got!). Elixir is it good for marathons because it's based on Erlang and Ericsson claims six nines uptime? Just use the tech you find is most FUN to work with because it's better to have fun programming than being bored.

jtwebman 11y ago
Also it depends on the system you are building. Elixir and Erlang scale great and send messages even between servers fast! So if you need to scale it is great. Go I am sure is faster performance wiz but Elixir/Erlang will stay running longer and be easier to reason about as the system gets bigger. Go will be easier to find devs then Elixir/Erlang will be harder. So there are trade offs. In the end you could use both, use the right tool for the job.