7 ms·

I'm a hardcore Ruby fan who moved to Elixir and rarely writes/maintains Ruby code. The language grows on you and once you master it, there's nothing quite like

by neya 8y ago

I'm a hardcore Ruby fan who moved to Elixir and rarely writes/maintains Ruby code. The language grows on you and once you master it, there's nothing quite like it. You could argue this for other languages - But, I am an experienced programmer who has written production applications in quite a handful of major languages and frameworks out there. I've tried almost everything that trended on HN in the past years - Scala, NodeJS, Ruby, Python, GoLang, R, PHP, Java, and a handful more and I can tell you this - there's nothing quite like Elixir for me till date. These days, even for my consulting work, I use Elixir. It's almost as if I just push code and forget. (Except for watching out for security vulnerabilities, other regular audits). Everything isn't as green since it's a fairly new language, there's still libraries lacking for some basic stuff - such as authentication (only a handful of them are maintained). But still, I wouldn't consider downgrading to anything else. Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code. I love how fast I can develop apps, SPAs and what not with Elixir/Phoenix. Coming from a NodeJS experience, Elixir is a 100-fold upgrade from JS. In fact, you will realize how terrible JS is (as a language) once you start programming in Elixir. The closest to Elixir that I like is Scala. They are almost like cousins. Elixir runs on Erlang's VM, Scala runs on JVM. In fact, I prefer Scala.js for my frontend these days, which converts Scala code to JS with strong typing support. But, Scala is more verbose and way too advanced for someone new to the language. There's a 101 ways to do the same thing and it's very academic as well (The Scala book was over 700 pages when I bought it). If you are looking for a new language/framework to learn in 2019 - pick Elixir + Phoenix. If not, then go with Ruby + Rails, you couldn't be wrong with either choice.

lawn 8y ago
> Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code. Interesting, I haven't seen that as a strong point for Elixir. Granted I'm comparing it to Haskell and Rust which really give you errors in compile time. They aren't very popular for web dev though and compared to the other languages you list I guess I can see where you're coming from.
- dasil003 8y ago
  Relative to Ruby it's a lot better without sacrificing the rapid prototyping. If you need real correctness then Haskell and Rust are in a class of their own, but they'll never be as fast for hacking (although admittedly Rust has a high ceiling). I think the magic of Elixir is the happy middle ground where you get more correctness than a multi-paradigm highly dynamic language like Ruby with minimal overhead, and then you strengthen the operational story with a deeply embedded crash-and-restart tooling from Erlang/OTP encouraging less statefulness and easier recovery by design across the board.
- yawaramin 8y ago
  Elixir doesn't do type-checking by default, but you can rather easily get it to enforce that records must specify certain fields on creation. Other things, like setting up the optional typechecker (Dialyzer) and writing type specifications for your code, take a bit more effort but do help find problems.
  - dnautics 8y ago
    Im new (1yr or so) to elixir, never really believed in dialyzer, but a few weeks ago I noticed my vscode started dialyzing my code in real time and it's caught several errors that would have been hard to catch, and whatever vscode plugin I'm using makes it hard to not write typespecs.
    - yawaramin 8y ago
      Ah, you're probably using the ElixirLS extension, IIRC it has an auto-setup process for Dialyzer when it first gets installed. After that one-time setup it continuously typechecks open projects.
    - QuinnWilton 8y ago
      Dialyzer really gives you what you put into it. It never false-positives (by design), even while working with limited information, so if you're not writing typespecs, there's only so much it can do. If, though, you make a habit of writing typespecs for everything, and defining domain-specific types rather than relying just on the primitives, it can get you surprisingly far. It'll never be as powerful as Haskell or Idris, but it's absolutely a tool all Elixir (and Erlang) developers should be using. Also, if anyone ever wants an easy way to contribute to open-source Elixir, just start running Dialyzer on popular projects. Every warning that pops up will be a bug, and often they'll be easy to fix.
spapas82 8y ago
Have you tried python/ Django? I haven't used elixir but I my productivity with Django is much bigger than when compared with other solutions like php, node, java/spring, c#.net etc. I am talking about good ol' traditional web apps, no fancy spa stuff where I can use Django in all its glory: cbvs, forms, admin, auth and the huge package ecosystem. Give it a try if you haven't, even just the Django tutorial should give you a hint of the productivity enchantment you'll have!
- neya 8y ago
  Of course, I have used Django (and I still do for data-heavy applications). Python and ruby are quite similar syntactically, but very different philosophically. This is beautifully elaborated on this page here: https://rubyonrails.org/doctrine/ https://rubyonrails.org/doctrine/ and hence my preference for Ruby over Python. Not saying python is bad at all, just that I only have specific use cases I like to use Python for, mostly stuff that needs Pandas.
- weberc2 8y ago
  One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. The problem tends to be difficult to debug since it often manifests itself in timeouts for requests that aren't actually issuing the blocking request, but for which can't be serviced because the event loop is blocked nonetheless. It's also easy to add bugs in async code (e.g., forgetting to 'await' and getting back a promise instead of a response object). Of course, we could stick with sync Python, but that has lots of other problems (namely it's difficult to pack Python server processes onto hosts with passable efficiency). Elixir and Go just skirt these problems altogether because all I/O is async under the hood (no need for "await" keywords), and both languages support efficient concurrency and parallelism. One process can fully utilize a host. Of course, this doesn't speak to the quality of available web frameworks, which may or may not matter for your application.
  - jashmatthews 8y ago
    Not a Python dev but I worked a lot with Ruby performance a lot for the past few years. Do you really need async IO? Even at Google scale[1] it's kinda a waste of time for web/job servers and only required for proxying etc. The overhead of threads is massively overstated [2] Ruby scales a long way using Puma or Phusion Passenger with one process per core (just like NodeJS) and adding threads until you hit CPU saturation. Python must have something similar? [1] https://www.slideshare.net/e456/tyma-paulmultithreaded1 https://www.slideshare.net/e456/tyma-paulmultithreaded1 [2] https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/ https://eli.thegreenplace.net/2018/measuring-context-switchi...
hinkley 8y ago
>Javascript I’ve been working in Node for a few years now, on a project that suffers a lot of warts from adopting Node early and not benefitting from the wisdom of the group. Something I didn’t know about myself as a full stack developer is that I work on UI because I like human factors, and I work on backend because I like solving architectural or data problems and sometimes I’m just tired of writing Javascript. Trying to homogenize everything at work removes a vey important pressure relief valve, both for individuals and team dynamics. I figured this out about a year ago and if not for major life events I’d be out there somewhere writing Elixir or Rust or Scala code. ES6 and beyond has some things worth experiencing so I’m focusing on that as much as I can. Just a few more months and I can pivot outta here.
yawaramin 8y ago
You sound like you have similar tastes to mine. If so, I'm guessing Scala.js's slow compiles and heavy output size is an annoyance. Check out BuckleScript/ReasonML. Reason provides a new syntax for OCaml, in a way like what Elixir does for Erlang. Compile times are instant (I'm not exaggerating ... much), type system and inference are powerful (more than Scala), and output is extremely minimalistic ES5.
- virtualwhys 8y ago
  > I'm guessing Scala.js's slow compiles and heavy output size is an annoyance Compared to BuckleScript, sure, but that's an extreme outlier, near instantaneous whole project (wtf) compilation times with tiny output is most definitely not the norm. As a Scala.js user that is also subjected to the Angular/Ionic/Webpack world, the former is very fast, as in, 1-2 seconds incremental compilation, whereas the latter is a lumbering beast, often taking over 10 seconds for "live reload" for even the simplest of changes. In terms of output size, yes, there is the Scala collections "tax" (@150KB), but thereafter the bang-for-buck factor pays off -- all the power of Scala with minimal increase in bundle size.
  - yawaramin 8y ago
    Well, sometimes you can't avoid it :-) But since you mentioned live reload, BuckleScript now also has instant live reload via a WebSocket connection to the browser: https://bucklescript.github.io/blog/2018/07/17/release-4-0-0#a-simple-approach-to-accelerate-feedback-loop-in-a-reliable-way https://bucklescript.github.io/blog/2018/07/17/release-4-0-0...
brightball 8y ago
Couldn’t agree more. Learning Elixir completely changed the way I think about programming problems. The downside is that it raises your awareness of deficiencies in other languages that you never really noticed before.
- weberc2 8y ago
  I would really like to try Elixir or Erlang, but the learning curve seems steep and I haven't heard much in the way of specifics to justify why it would be a good time investment (just "supervisor trees are the shit!" and "functional languages are great!"). I'm particularly wary of dynamic languages; I program in Python and JavaScript all day, but I use Go and TypeScript in my spare time and find myself both more productive and more confident that my code works as intended. I'm aware that Elixir has some sort of optional typing, but the vibe I get is that few really use it and it's not very practical. I would be really interested to hear someone speak to these concerns.
  - brightball 8y ago
    That’s asking for a very detailed reply, but since you already work with Go let me just share the comparison that I wrote up not too long ago. https://www.brightball.com/articles/comparing-elixir-and-go https://www.brightball.com/articles/comparing-elixir-and-go That is just the summary link that includes a link to the original article I wrote for Codeship as well as the big discussion from when it hit HN. The HN discussion, especially, was great.

by neya 8y ago

lawn 8y ago

> Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code. Interesting, I haven't seen that as a strong point for Elixir. Granted I'm comparing it to Haskell and Rust which really give you errors in compile time. They aren't very popular for web dev though and compared to the other languages you list I guess I can see where you're coming from.

dasil003 8y ago
Relative to Ruby it's a lot better without sacrificing the rapid prototyping. If you need real correctness then Haskell and Rust are in a class of their own, but they'll never be as fast for hacking (although admittedly Rust has a high ceiling). I think the magic of Elixir is the happy middle ground where you get more correctness than a multi-paradigm highly dynamic language like Ruby with minimal overhead, and then you strengthen the operational story with a deeply embedded crash-and-restart tooling from Erlang/OTP encouraging less statefulness and easier recovery by design across the board.
yawaramin 8y ago
Elixir doesn't do type-checking by default, but you can rather easily get it to enforce that records must specify certain fields on creation. Other things, like setting up the optional typechecker (Dialyzer) and writing type specifications for your code, take a bit more effort but do help find problems.
- dnautics 8y ago
  Im new (1yr or so) to elixir, never really believed in dialyzer, but a few weeks ago I noticed my vscode started dialyzing my code in real time and it's caught several errors that would have been hard to catch, and whatever vscode plugin I'm using makes it hard to not write typespecs.
  - yawaramin 8y ago
    Ah, you're probably using the ElixirLS extension, IIRC it has an auto-setup process for Dialyzer when it first gets installed. After that one-time setup it continuously typechecks open projects.
  - QuinnWilton 8y ago
    Dialyzer really gives you what you put into it. It never false-positives (by design), even while working with limited information, so if you're not writing typespecs, there's only so much it can do. If, though, you make a habit of writing typespecs for everything, and defining domain-specific types rather than relying just on the primitives, it can get you surprisingly far. It'll never be as powerful as Haskell or Idris, but it's absolutely a tool all Elixir (and Erlang) developers should be using. Also, if anyone ever wants an easy way to contribute to open-source Elixir, just start running Dialyzer on popular projects. Every warning that pops up will be a bug, and often they'll be easy to fix.

spapas82 8y ago

Have you tried python/ Django? I haven't used elixir but I my productivity with Django is much bigger than when compared with other solutions like php, node, java/spring, c#.net etc. I am talking about good ol' traditional web apps, no fancy spa stuff where I can use Django in all its glory: cbvs, forms, admin, auth and the huge package ecosystem. Give it a try if you haven't, even just the Django tutorial should give you a hint of the productivity enchantment you'll have!

neya 8y ago
Of course, I have used Django (and I still do for data-heavy applications). Python and ruby are quite similar syntactically, but very different philosophically. This is beautifully elaborated on this page here: https://rubyonrails.org/doctrine/ https://rubyonrails.org/doctrine/ and hence my preference for Ruby over Python. Not saying python is bad at all, just that I only have specific use cases I like to use Python for, mostly stuff that needs Pandas.
weberc2 8y ago
One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. The problem tends to be difficult to debug since it often manifests itself in timeouts for requests that aren't actually issuing the blocking request, but for which can't be serviced because the event loop is blocked nonetheless. It's also easy to add bugs in async code (e.g., forgetting to 'await' and getting back a promise instead of a response object). Of course, we could stick with sync Python, but that has lots of other problems (namely it's difficult to pack Python server processes onto hosts with passable efficiency). Elixir and Go just skirt these problems altogether because all I/O is async under the hood (no need for "await" keywords), and both languages support efficient concurrency and parallelism. One process can fully utilize a host. Of course, this doesn't speak to the quality of available web frameworks, which may or may not matter for your application.
- jashmatthews 8y ago
  Not a Python dev but I worked a lot with Ruby performance a lot for the past few years. Do you really need async IO? Even at Google scale[1] it's kinda a waste of time for web/job servers and only required for proxying etc. The overhead of threads is massively overstated [2] Ruby scales a long way using Puma or Phusion Passenger with one process per core (just like NodeJS) and adding threads until you hit CPU saturation. Python must have something similar? [1] https://www.slideshare.net/e456/tyma-paulmultithreaded1 https://www.slideshare.net/e456/tyma-paulmultithreaded1 [2] https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/ https://eli.thegreenplace.net/2018/measuring-context-switchi...

hinkley 8y ago

>Javascript I’ve been working in Node for a few years now, on a project that suffers a lot of warts from adopting Node early and not benefitting from the wisdom of the group. Something I didn’t know about myself as a full stack developer is that I work on UI because I like human factors, and I work on backend because I like solving architectural or data problems and sometimes I’m just tired of writing Javascript. Trying to homogenize everything at work removes a vey important pressure relief valve, both for individuals and team dynamics. I figured this out about a year ago and if not for major life events I’d be out there somewhere writing Elixir or Rust or Scala code. ES6 and beyond has some things worth experiencing so I’m focusing on that as much as I can. Just a few more months and I can pivot outta here.

yawaramin 8y ago

You sound like you have similar tastes to mine. If so, I'm guessing Scala.js's slow compiles and heavy output size is an annoyance. Check out BuckleScript/ReasonML. Reason provides a new syntax for OCaml, in a way like what Elixir does for Erlang. Compile times are instant (I'm not exaggerating ... much), type system and inference are powerful (more than Scala), and output is extremely minimalistic ES5.

virtualwhys 8y ago
> I'm guessing Scala.js's slow compiles and heavy output size is an annoyance Compared to BuckleScript, sure, but that's an extreme outlier, near instantaneous whole project (wtf) compilation times with tiny output is most definitely not the norm. As a Scala.js user that is also subjected to the Angular/Ionic/Webpack world, the former is very fast, as in, 1-2 seconds incremental compilation, whereas the latter is a lumbering beast, often taking over 10 seconds for "live reload" for even the simplest of changes. In terms of output size, yes, there is the Scala collections "tax" (@150KB), but thereafter the bang-for-buck factor pays off -- all the power of Scala with minimal increase in bundle size.
- yawaramin 8y ago
  Well, sometimes you can't avoid it :-) But since you mentioned live reload, BuckleScript now also has instant live reload via a WebSocket connection to the browser: https://bucklescript.github.io/blog/2018/07/17/release-4-0-0#a-simple-approach-to-accelerate-feedback-loop-in-a-reliable-way https://bucklescript.github.io/blog/2018/07/17/release-4-0-0...

brightball 8y ago

Couldn’t agree more. Learning Elixir completely changed the way I think about programming problems. The downside is that it raises your awareness of deficiencies in other languages that you never really noticed before.

weberc2 8y ago
I would really like to try Elixir or Erlang, but the learning curve seems steep and I haven't heard much in the way of specifics to justify why it would be a good time investment (just "supervisor trees are the shit!" and "functional languages are great!"). I'm particularly wary of dynamic languages; I program in Python and JavaScript all day, but I use Go and TypeScript in my spare time and find myself both more productive and more confident that my code works as intended. I'm aware that Elixir has some sort of optional typing, but the vibe I get is that few really use it and it's not very practical. I would be really interested to hear someone speak to these concerns.
- brightball 8y ago
  That’s asking for a very detailed reply, but since you already work with Go let me just share the comparison that I wrote up not too long ago. https://www.brightball.com/articles/comparing-elixir-and-go https://www.brightball.com/articles/comparing-elixir-and-go That is just the summary link that includes a link to the original article I wrote for Codeship as well as the big discussion from when it hit HN. The HN discussion, especially, was great.