15 ms·

LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see

LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case. Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won't know until some ActionCable code is released but it sure didn't look complicated. It does seem odd that -api takes years to get in, but ActionCable gets a go-straight-to-core pass without any community review first. It certainly seems like a weakness in the process, which should be addressed, although I'd agree with the eventual result & priorities. -api probably isn't something I'd ever use: even if I eventually created an API-only app, I'd probably have started from a regular Rails app and gradually optimised things out. Edited to add: I'm actually quite bullish on TurboLinks 3 if it can help me to avoid ever having to write a Javascript MVC app again. It's not so much that these apps are hard to write, it's that they're freaking hard to debug, particularly in the hands of users.

erichmond 11y ago
This is just an anecdote as: - I agree that most rails programmers will not move to clojure. - For monorail apps, rails is still king. That said, for us, when comparing clojure and ruby REST API services we've built, clojure has had the following benefits: - Less code - Less tests needed - Better concurrency - Less developer hours - Less maintenance - About 33% of the servers for same performance - Easier/faster debugging It's been far more then a 10x improvement overall, and if people are looking to move out of the monorail style of app, it's definitely worth a look.
- matthewmacleod 11y ago
  Interestingly, we had a couple of Clojure experiments. Takeaway was that there were some benefits in terms of performance and maintenance, but they weren't worth the tradeoff in expressivity and increased developer time. There's no reason that Rails should be restricted to 'monorail' or monolithic apps. We've had great success writing what are essentially microservices in Rails. Code is easy to read, easy to maintain, and performs well. It's hard to find any compelling reason to use another toolset under those circumstances!
  - erichmond 11y ago
    I appreciate the counterpoint! I guess just another example of different strokes for different folks. For us developer time decreased, and expressivity increased. I wasn't suggesting that rails shouldn't be used for microservices, we actually have a number of rails microservices in production as well. I was more stating that I agree with OP in that if I were to write a monorail style application today, I would use ruby/rails over clojure. I was also pointing out that if you are moving to more of a SOA/microservices framework that we've had great experience with clojure, and that it's worth looking at. I'm a huge fan of rails, and have been using it since pre-1.0. I think as we look back on this period in time, we're only going to appreciate rails more and more for really making self / low funded startups viable. Cheers!
    - matthewmacleod 11y ago
      A great point, of course. That's why we had a crack at Clojure in the first place! Basically, it's great to have a diversity of freely-available, open-source tools that can be used for such a wide variety of different tasks. I expect the 'my toolset is better than your toolset' nonsense will always be with us, and while it's useful to discuss some of the pros and cons, we should all bear in mind that most tools are awesome :)
  - kyllo 11y ago
    If you feel Clojure is less expressive than Ruby, you're not good enough at Clojure yet. I'm not saying you have to prefer Clojure's syntax, and Ruby probably has more libraries for a lot of things you want to do. Going from Ruby to Clojure may be a productivity tradeoff for you and your team, but objectively it's not an expressivity tradeoff. Clojure has a bit more expressive power than Ruby.
    - davidann 11y ago
      Could you reference examples of this assertion please?
      - 11y ago
- klapinat0r 11y ago
  Monorail? Do you mean monolithic? or do you mean "doing only one thing" (one track)?
railsbird 11y ago
> LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! I meant those as examples based on what I see around me. That's exactly my agony, I don't know what is next and, if I did, I would be learning it already. At this point, I just feel it is not Rails. > Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads If you are using Event Machine you can't abstract away from it. You need to do all I/O using Event Machine aware mechanisms. You can get rid of callbacks by using fibers but you are still required to use an API specific to Event Machine. For example, you can't use File.read to read a file as that will block your event loop.
- dragonwriter 11y ago
  You are confusing the real need to use EM aware mechanisms with a not-real inability to use abstractions over EM itself. Those are two different issues.
- dgregd 11y ago
  Nginx HTTP Push Module seems to much better solution than EventMachine. So Nginx keeps opened sockets and a Rails app sends messages via ordinary HTTP. http://wiki.nginx.org/HttpPushStreamModule http://wiki.nginx.org/HttpPushStreamModule
  - moe 11y ago
    Agree, very much. I'm also wary of handling websockets from Ruby, which is demonstrably ill suited for any kind of high concurrency networking (been there, got the t-shirt). Since most people already run nginx in their stack anyway I don't see the advantage of sticking with a Ruby-based solution that is almost guaranteed to be inferior on every metric.
cies 11y ago
> the idea that every Rails programmer will be switching to Clojure or Elixir! [...] I don't see any 10x advantages [...] I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell, which I have moved to from Rails. 10x for me is: 1. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to 700-1500MB of gems, using hundreds of MB while running, serving requests in 50-200ms... More then 10x! And my framework of choice (Yesod) consists of 23kLOC, where Rails has 210kLOC (source: openhub.net)... Another 10x! 2. Less bugs when growing the codebase; "strong compile time guarantees" is now my main weapon when fighting maintenance curve. Back in my Rails days I'd say "typing is a very narrow form of automated testing", which given my exposure to C++/Java was defendable opinion. Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time. TL;DR: I believe 10x frameworks are out there.
- ionforce 11y ago
  But isn't that like saying a healthy person can run 10x faster than someone with a limp? For context, my background has been predominantly in a dynamic language, but now I've drank all the typed kool-aid, so I'm sold, as it seems you are as well. So we're essentially saying typed is 10x better than dynamic, but was dynamic ever really a good place to start with?
  - cies 11y ago
    I'd say dynamic has its place. Especially Ruby since it can serve as a stepping stone for the imperative-minded into functional. > typed is 10x better than dynamic 10x what? Rails' community is many-x larger then Yesod's, in that case dynamic wins. :)
  - chipsy 11y ago
    Dynamic has a nice exploratory quality. It pushes off the moment of reckoning, but sometimes you need that if you're sketching an idea in code. It was good for me when I first learned, and I think that's still true now. For "in the large" systems it's basically required that stuff gets a bit more gooshy and dynamic-y and interact in an indirect, protocol-driven fashion. But when you actually have a specific piece of engineering in mind, it's nowhere near as helpful - it tends to solve things that could probably be solved more soundly with compile-time constructs. But there's a process of building up your understanding to where you can actually have confidence in what you're building, which isn't reached so easily. Having the compiler fail your code before it can run is very "magical" in that sense.
AlwaysBCoding 11y ago
Having used both Rails + Clojure here's my take. As a general comparison, when it comes to building server-side web apps Rails is preferable to Clojure. But for the web stacks / ecosystems as a whole Clojure wins by about 10x. The main reason for this is ClojureScript. For those who aren't familiar ClojureScript is a Clojure->Javascript compiler that lets you write your UI code in Clojure and drastically simplifies Javascript codebases. Given how much time is consumed writing UI code in modern web app development, the benefits that ClojureScript gives you over the turbolinks/js framework of your choice approach that Rails emphasizes cannot be overstated. I've found that writing web-apps/api's in Clojure, using ClojureScript on the front-end, then using Rails to write small services where you want to take advantage of some of the great Ruby libraries is the way to go. You get the best of both worlds.
- pjungwir 11y ago
  I'm curious (as someone who's only dabbled in Clojure): could you write an Ember app in ClojureScript (or Angular/React/Knockout)? Is it like Coffeescript---i.e. just a compiler? If you wanted to build a SPA in ClojureScript, how would you approach it?
  - bgar 11y ago
    You'd use a React wrapper such as Om[1] or Reagent[2]. These take advantage of React's DOM diffing and pair it with ClojureScript's immutable data structures. 1: https://github.com/omcljs/om https://github.com/omcljs/om 2: http://reagent-project.github.io http://reagent-project.github.io
  - AlwaysBCoding 11y ago
    You can write Ember/Angular/Knockout etc... in ClojureScript (I've done it before) but it comes out feeling weird and unnatural. You always feel like you're trying to fit a square peg into a round hole. The preferred solution is to use a ClojureScript wrapper around ReactJS and write your own event handling logic. I'm a big fan of the Reagent library which wraps React with a dead simple API. I believe it's the best UI library ever created and I wish more people knew about it. The big idea is that you store your UI state as one single Clojure data structure. A Reagent component is just a Clojure function that takes the necessary sub-section of the UI state as an argument and returns a Clojure data structure that represents the HTML code that it wants to render. An example of this would be the following component that displays a list of items. (defn [items] [:ul.items (for [item items] [:li.item (:display-name item)]])]) Then whenever you change the state of 'items', the component will automatically re-render and inject the new DOM as necessary using React's diffing algorithm for high performance. The key thing here is that there is no Javascript framework to learn. All you do is manipulate Clojure data with Clojure functions and use React to render it. There's no 'Ember.component.extend' or 'ng-repeat' to worry about. You spend very little time looking through documentation. The Clojure langauge IS your framework, it's really incredible.
juliangregorian 11y ago
Rails programmer switching to Clojure/Elixir here. And my workplace is switching to Scala.
- eranation 11y ago
  I always wondered why Rails programmers prefer Clojure/Elixir over Scala, Scala syntax and concept seems to me much more translatable to Ruby than Clojure. In Scala, just like in Ruby 1 + 1 is 1.+(1), you have a scala version of method_missing, duck typing, pimp my library etc... Is there a reason why Rubists prefer a completely different paradigm such as Clojure?
  - saraid216 11y ago
    I got interested in Clojure because I felt I needed to learn something LISPy. Similarly, I got interested in Elixir because I felt I needed to learn Erlang. I have yet to have any kind of similar motivation for Scala. These are not good reasons, but they are my reasons.
  - juliangregorian 11y ago
    Elixir is extremely Ruby-influenced, much more than Scala. I do appreciate Scala, but Clojure is just cool.
  - danneu 11y ago
    Clojure is simple and Scala is complex. I dove into Scala before Clojure because lisp was so alien to me. After a couple months of Scala, I still felt like I didn't know where to begin with a blank slate, though I was eventually productive. When I finally gave Clojure a shot, I was building things my first week. Kinda like my first experience with Ruby. Clojure felt like a better Ruby to me. The aesthetics that drew me to Ruby were improved in Clojure. > Is there a reason why Rubists prefer a completely different > paradigm such as Clojure? The leap from Ruby to Scala is a larger gulf than Ruby to Clojure, though it's not obvious at a glance.
  - wilmoore 11y ago
    For me, Scala is a great language that continues to present me with good surprises (i.e. literal curry syntax). The only issue for me is the JVM and the package/namespace system (not to mention mvn, sbt). In this way, Erlang/Elixir is more enjoyable for me. I much prefer the Erlang module system (Python and Node.js get a special mention here as well) vs. what you get with Ruby, PHP, Java, etc.
gnufied 11y ago
Eventmachine itself is in kinda unmaintained state. Newer projects are starting with Celluloid and stuff, which arguably offers much easier way to reason about concurrency. I am not sure why they would pick EM as base for ActionCable.
angersock 11y ago
Elixir/Erlang/OTP has a lot of useful stuff to say about testing, deployment, reliability, maintenance, and code quality. Ruby does too, but is constrained in various ways. Honestly, websockets-as-first-class-citizen plus the E/E/O process model is a huge win, and one that Rails just won't have going for it. That doesn't make Rails obsolete, but it's outside of its comfort zone compared to the new/old tech.

erichmond 11y ago

This is just an anecdote as: - I agree that most rails programmers will not move to clojure. - For monorail apps, rails is still king. That said, for us, when comparing clojure and ruby REST API services we've built, clojure has had the following benefits: - Less code - Less tests needed - Better concurrency - Less developer hours - Less maintenance - About 33% of the servers for same performance - Easier/faster debugging It's been far more then a 10x improvement overall, and if people are looking to move out of the monorail style of app, it's definitely worth a look.

matthewmacleod 11y ago
Interestingly, we had a couple of Clojure experiments. Takeaway was that there were some benefits in terms of performance and maintenance, but they weren't worth the tradeoff in expressivity and increased developer time. There's no reason that Rails should be restricted to 'monorail' or monolithic apps. We've had great success writing what are essentially microservices in Rails. Code is easy to read, easy to maintain, and performs well. It's hard to find any compelling reason to use another toolset under those circumstances!
- erichmond 11y ago
  I appreciate the counterpoint! I guess just another example of different strokes for different folks. For us developer time decreased, and expressivity increased. I wasn't suggesting that rails shouldn't be used for microservices, we actually have a number of rails microservices in production as well. I was more stating that I agree with OP in that if I were to write a monorail style application today, I would use ruby/rails over clojure. I was also pointing out that if you are moving to more of a SOA/microservices framework that we've had great experience with clojure, and that it's worth looking at. I'm a huge fan of rails, and have been using it since pre-1.0. I think as we look back on this period in time, we're only going to appreciate rails more and more for really making self / low funded startups viable. Cheers!
  - matthewmacleod 11y ago
    A great point, of course. That's why we had a crack at Clojure in the first place! Basically, it's great to have a diversity of freely-available, open-source tools that can be used for such a wide variety of different tasks. I expect the 'my toolset is better than your toolset' nonsense will always be with us, and while it's useful to discuss some of the pros and cons, we should all bear in mind that most tools are awesome :)
- kyllo 11y ago
  If you feel Clojure is less expressive than Ruby, you're not good enough at Clojure yet. I'm not saying you have to prefer Clojure's syntax, and Ruby probably has more libraries for a lot of things you want to do. Going from Ruby to Clojure may be a productivity tradeoff for you and your team, but objectively it's not an expressivity tradeoff. Clojure has a bit more expressive power than Ruby.
  - davidann 11y ago
    Could you reference examples of this assertion please?
    - 11y ago
klapinat0r 11y ago
Monorail? Do you mean monolithic? or do you mean "doing only one thing" (one track)?

railsbird 11y ago

> LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! I meant those as examples based on what I see around me. That's exactly my agony, I don't know what is next and, if I did, I would be learning it already. At this point, I just feel it is not Rails. > Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads If you are using Event Machine you can't abstract away from it. You need to do all I/O using Event Machine aware mechanisms. You can get rid of callbacks by using fibers but you are still required to use an API specific to Event Machine. For example, you can't use File.read to read a file as that will block your event loop.

dragonwriter 11y ago
You are confusing the real need to use EM aware mechanisms with a not-real inability to use abstractions over EM itself. Those are two different issues.
dgregd 11y ago
Nginx HTTP Push Module seems to much better solution than EventMachine. So Nginx keeps opened sockets and a Rails app sends messages via ordinary HTTP. http://wiki.nginx.org/HttpPushStreamModule http://wiki.nginx.org/HttpPushStreamModule
- moe 11y ago
  Agree, very much. I'm also wary of handling websockets from Ruby, which is demonstrably ill suited for any kind of high concurrency networking (been there, got the t-shirt). Since most people already run nginx in their stack anyway I don't see the advantage of sticking with a Ruby-based solution that is almost guaranteed to be inferior on every metric.

cies 11y ago

> the idea that every Rails programmer will be switching to Clojure or Elixir! [...] I don't see any 10x advantages [...] I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell, which I have moved to from Rails. 10x for me is: 1. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to 700-1500MB of gems, using hundreds of MB while running, serving requests in 50-200ms... More then 10x! And my framework of choice (Yesod) consists of 23kLOC, where Rails has 210kLOC (source: openhub.net)... Another 10x! 2. Less bugs when growing the codebase; "strong compile time guarantees" is now my main weapon when fighting maintenance curve. Back in my Rails days I'd say "typing is a very narrow form of automated testing", which given my exposure to C++/Java was defendable opinion. Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time. TL;DR: I believe 10x frameworks are out there.

ionforce 11y ago
But isn't that like saying a healthy person can run 10x faster than someone with a limp? For context, my background has been predominantly in a dynamic language, but now I've drank all the typed kool-aid, so I'm sold, as it seems you are as well. So we're essentially saying typed is 10x better than dynamic, but was dynamic ever really a good place to start with?
- cies 11y ago
  I'd say dynamic has its place. Especially Ruby since it can serve as a stepping stone for the imperative-minded into functional. > typed is 10x better than dynamic 10x what? Rails' community is many-x larger then Yesod's, in that case dynamic wins. :)
- chipsy 11y ago
  Dynamic has a nice exploratory quality. It pushes off the moment of reckoning, but sometimes you need that if you're sketching an idea in code. It was good for me when I first learned, and I think that's still true now. For "in the large" systems it's basically required that stuff gets a bit more gooshy and dynamic-y and interact in an indirect, protocol-driven fashion. But when you actually have a specific piece of engineering in mind, it's nowhere near as helpful - it tends to solve things that could probably be solved more soundly with compile-time constructs. But there's a process of building up your understanding to where you can actually have confidence in what you're building, which isn't reached so easily. Having the compiler fail your code before it can run is very "magical" in that sense.

AlwaysBCoding 11y ago

Having used both Rails + Clojure here's my take. As a general comparison, when it comes to building server-side web apps Rails is preferable to Clojure. But for the web stacks / ecosystems as a whole Clojure wins by about 10x. The main reason for this is ClojureScript. For those who aren't familiar ClojureScript is a Clojure->Javascript compiler that lets you write your UI code in Clojure and drastically simplifies Javascript codebases. Given how much time is consumed writing UI code in modern web app development, the benefits that ClojureScript gives you over the turbolinks/js framework of your choice approach that Rails emphasizes cannot be overstated. I've found that writing web-apps/api's in Clojure, using ClojureScript on the front-end, then using Rails to write small services where you want to take advantage of some of the great Ruby libraries is the way to go. You get the best of both worlds.

pjungwir 11y ago
I'm curious (as someone who's only dabbled in Clojure): could you write an Ember app in ClojureScript (or Angular/React/Knockout)? Is it like Coffeescript---i.e. just a compiler? If you wanted to build a SPA in ClojureScript, how would you approach it?
- bgar 11y ago
  You'd use a React wrapper such as Om[1] or Reagent[2]. These take advantage of React's DOM diffing and pair it with ClojureScript's immutable data structures. 1: https://github.com/omcljs/om https://github.com/omcljs/om 2: http://reagent-project.github.io http://reagent-project.github.io
- AlwaysBCoding 11y ago
  You can write Ember/Angular/Knockout etc... in ClojureScript (I've done it before) but it comes out feeling weird and unnatural. You always feel like you're trying to fit a square peg into a round hole. The preferred solution is to use a ClojureScript wrapper around ReactJS and write your own event handling logic. I'm a big fan of the Reagent library which wraps React with a dead simple API. I believe it's the best UI library ever created and I wish more people knew about it. The big idea is that you store your UI state as one single Clojure data structure. A Reagent component is just a Clojure function that takes the necessary sub-section of the UI state as an argument and returns a Clojure data structure that represents the HTML code that it wants to render. An example of this would be the following component that displays a list of items. (defn [items] [:ul.items (for [item items] [:li.item (:display-name item)]])]) Then whenever you change the state of 'items', the component will automatically re-render and inject the new DOM as necessary using React's diffing algorithm for high performance. The key thing here is that there is no Javascript framework to learn. All you do is manipulate Clojure data with Clojure functions and use React to render it. There's no 'Ember.component.extend' or 'ng-repeat' to worry about. You spend very little time looking through documentation. The Clojure langauge IS your framework, it's really incredible.

juliangregorian 11y ago

Rails programmer switching to Clojure/Elixir here. And my workplace is switching to Scala.

eranation 11y ago
I always wondered why Rails programmers prefer Clojure/Elixir over Scala, Scala syntax and concept seems to me much more translatable to Ruby than Clojure. In Scala, just like in Ruby 1 + 1 is 1.+(1), you have a scala version of method_missing, duck typing, pimp my library etc... Is there a reason why Rubists prefer a completely different paradigm such as Clojure?
- saraid216 11y ago
  I got interested in Clojure because I felt I needed to learn something LISPy. Similarly, I got interested in Elixir because I felt I needed to learn Erlang. I have yet to have any kind of similar motivation for Scala. These are not good reasons, but they are my reasons.
- juliangregorian 11y ago
  Elixir is extremely Ruby-influenced, much more than Scala. I do appreciate Scala, but Clojure is just cool.
- danneu 11y ago
  Clojure is simple and Scala is complex. I dove into Scala before Clojure because lisp was so alien to me. After a couple months of Scala, I still felt like I didn't know where to begin with a blank slate, though I was eventually productive. When I finally gave Clojure a shot, I was building things my first week. Kinda like my first experience with Ruby. Clojure felt like a better Ruby to me. The aesthetics that drew me to Ruby were improved in Clojure. > Is there a reason why Rubists prefer a completely different > paradigm such as Clojure? The leap from Ruby to Scala is a larger gulf than Ruby to Clojure, though it's not obvious at a glance.
- wilmoore 11y ago
  For me, Scala is a great language that continues to present me with good surprises (i.e. literal curry syntax). The only issue for me is the JVM and the package/namespace system (not to mention mvn, sbt). In this way, Erlang/Elixir is more enjoyable for me. I much prefer the Erlang module system (Python and Node.js get a special mention here as well) vs. what you get with Ruby, PHP, Java, etc.

gnufied 11y ago

Eventmachine itself is in kinda unmaintained state. Newer projects are starting with Celluloid and stuff, which arguably offers much easier way to reason about concurrency. I am not sure why they would pick EM as base for ActionCable.

angersock 11y ago

Elixir/Erlang/OTP has a lot of useful stuff to say about testing, deployment, reliability, maintenance, and code quality. Ruby does too, but is constrained in various ways. Honestly, websockets-as-first-class-citizen plus the E/E/O process model is a huge win, and one that Rails just won't have going for it. That doesn't make Rails obsolete, but it's outside of its comfort zone compared to the new/old tech.