7 ms·

The New Ruby Ecosystem

104 points by Jim_Neath 16y ago

mark_l_watson 16y ago
Paolo sounds a bit like a fanboy but he makes a lot of interesting points. I work in a Clojure+Java shop yet I use Ruby whenever I can get away with it because it is the fastest language (for me) for getting stuff done. The article talks about Ruby's ecosystem, and that is key to Ruby productivity. That said, I think that Clojure will be super-awesome in a few years as its ecosystem continues to develop.
angelbob 16y ago
Much as I love Ruby and all the things he talks about, I worry that publicizing all these self-congratulatory posts about the Ruby community will create a lot more resistance to what we do. I get the impression that that's how SmallTalk died.
- aaronblohowiak 16y ago
  It is my impression that corporate drama around the smalltalk vendors helped to quicken its demise. Image-based development (in the smalltalk, not "rockstar" sense of image) also didn't sit well with a lot of people, though there were projects to support exporting source to files.
  - nmk 16y ago
    GNU Smalltalk supports both file based and image based development. Exporting source files is no means to an end — image based development is not widespread because it forces people out of emacs and vim.
    - masklinn 16y ago
      Smalltalk "died" before GNU Smalltalk was even usable, if it existed at all.
      - stcredzero 16y ago
        GNU Smalltalk has been around a very, very long time. It was also just about the gimpiest Smalltalk environment out there. Most of the people on the commercial environments just wished it would go away, because so many people downloaded it to try it and got the wrong impression of what Smalltalk is about. In the mid to late 90's, Smalltalk was still going strong. (It still is by some accounts.) I used GNU Smalltalk back then and it was pitifully gimpy in comparison to the commercial environments. If you want to check out Smalltalk, check out Squeak or Pharo. You can also download VisualWorks noncommercial. Also, to be fair, GNU Smalltalk has come a long way since then.
        masklinn 16y ago
        > If you want to check out Smalltalk, check out Squeak or Pharo. You can also download VisualWorks noncommercial. If you're running a windows machine, I found Dolphin pretty enjoyable (if the noncommercial edition is still available, i believe they're working on their next generation but x6 was pretty nice)
  - stcredzero 16y ago
    It is my impression that corporate drama around the smalltalk vendors helped to quicken its demise. Absolutely true! The merger-politics, the marketing missteps, and the cool technology that got buried are all epic. Image-based development also didn't sit well with a lot of people Not so true, for those who really "got it" and hit their stride, and anyone who comments who didn't get to that point is commenting as a clueless newbie. In image-based development, all of your programming meta-data are there as live Objects, instantly scriptable, totally and instantly obedient to your every whim. Ditto for runtime state -- everything available as live Objects and instantly scriptable. Really, once you learn a suitable style, it's heavenly, intoxicating and addictive. The same thing is true for Python and Ruby, but only about half as much. For example, a lot of advanced IDE functions require one to detect changes to files and re-parse things to keep programming metadata current. That problem just vanishes with image-based development. Literally hundreds of problems just vanish because everything is an object and they're all instantly available. On the other hand, image-based deployment SUCKS. Sucks sucks sucks. Just about every Smalltalker agrees. The big advantage of being file based is that your development test environment resembles your deployment, or is at least halfway to deployment by comparison. Image-based Smalltalk development is like the ultimate monkey-patching uber-debugger. Very cool to develop in, but you do not want to give it to your users!
    - deleted 16y ago
      [deleted]
    - cageface 16y ago
      Isn't it possible in image-based environments to have live objects but not the code that created them? This idea makes me extremely uneasy. Being able to derive everything in a running system from source code seems almost necessary for maintainability and comprehensibility.
      - stcredzero 16y ago
        You have that in the Smalltalk environment in the Changes Log. It is -- wait for it -- a text file! In fact, it gives you database-log like replay-ability in your entire development environment. "Being able to derive everything in a running system from source code," is exactly what it's for, and it's actually more capable and powerful than what you can get from source files. All of that scripting against the objects I was talking about? You can replay all that stuff too! If you do something stupid-dangerous like, "Semaphore allInstances do: [ :each | each release ]" then you can just exclude that last action when you replay the Change Log. Combined with image save, it gives you the freedom to live as dangerously as you like! The classic demo -- have your students spend 1/2 hour writing some toy system. Then have them hard-reboot their machines without saving the image. Show them how they can restart the image, grab the Change List tool, and voila, all their source code is back! To answer your question: it's possible that the source can be absent, but you have to execute an explicit command or do some sort of willful sabotage to make it happen that way. Really, it isn't so different from having separate source and executable files.
- smitjel 16y ago
  I'd like to think that concrete examples of ruby's successful production deployments and higher developer productivity mean more to companies than some blog ramblings.
  - angelbob 16y ago
    You'd think. And yet, the "Rails doesn't scale" meme survived for a remarkably long time... Still does, really.
- petercooper 16y ago
  The difference is that Rubyists just get on with shipping code and products without obsessing over the one true toolkit or vendor.
- skybrian 16y ago
  My impression from this post (as someone more familiar with Java and Python but who has tried Ruby a bit) is that it's a complex, fast-moving ecosystem that's somewhat difficult to keep up with. Not a bad thing, but a bit daunting for people who don't do it full time. There are other fast-moving ecosystems that I already have to keep up with. It likely has the side effect that that web searches will bring up a lot of obsolete articles.
jamesbritt 16y ago
"So, where did the once-vocal Ruby community go?" Well, it turns out there are many Ruby communities, some vocal, some not. Talking abut the Ruby community is going to end up missing a lot of what is going on. Mostly, though when people talk about a singular Ruby community they mean Rails. "In a world where a standard can take years to be discussed, approved, implemented and supported, Ruby standards such as Rack skip from conception to widespread support at blazing speed." Wish the same could be said for Ruby itself. Everyone who's completely moved to 1.9, raise your hand. Overall the points made are interesting, but much the same is happening in other language communities. People building stuff in Haskell, Clojure, JavaScript, Scala, etc. are more than happy to steal the best ideas from other realms and make them their own. So long as people don't start believing in The One True Framework or The One True Languge, we're doing quit well.
- manveru 16y ago
  Seems like there are now around 1/4 on 1.9: http://survey.hamptoncatlin.com/survey/stats http://survey.hamptoncatlin.com/survey/stats I expect that to increase a lot once 1.9.2 is out and Rubinius, MacRuby, and JRuby match the spec. And I raise my hand, I'm happily on 1.9 for over a year now.
  - jamesbritt 16y ago
    "Rubinius, MacRuby, and JRuby match the spec." What specs do they all match right now? The implementation teams are doing stunning work, but last I heard they were not all completely compatible and complete. "And I raise my hand, I'm happily on 1.9 for over a year now." Sure, but you're part of one those quiet Ruby communities that gets ignored by surveys such as Hampton's.
    - WALoeIII 16y ago
      Rubinius, MacRuby and JRuby are all 1.8 implementations now with 1.9 still on the roadmap.
- petercooper 16y ago
cageface 16y ago
Agreed. I was a little worried about the state of ruby a few years ago when MRI was flaky and Rails deployment was a real hassle but now it's just such a productive and pleasant environment to work in. There's still work to do, of course, but I still reach for Ruby when I need to get something done quickly.
adbge 16y ago
I do my dev on an archlinux box and the standard Ruby version in the repo (1.9.1_p378-2, I think) was doing something screwy to Jekyll. After reading this article, I checked out RVM and installed a couple different Ruby versions to play with. If you're doing anything with Ruby, I'd definitely suggest checking it out. Set up a 1.8.7-head install inside of RVM and fixed all my Jekyll woes. It also gave me a chance to play with Rubinius and the latest 1.9.3dev release. I always enjoyed being able to use eselect to switch between Ruby versions on Gentoo and RVM is able to duplicate this functionality and then some.
- steveklabnik 16y ago
  Ruby 1.9.1 had some pretty serious threading issues, if I remember. 1.9.2 fixed them. Don't know if that'd affect Jekyll, but I know it affected Rails.
- telemachos 16y ago
  To the best of my recollection, Jekyll itself plays nicely with 1.9.1. It's Liquid that was a problem for me. The Gemcutter.org version of Liquid (2.0) is not 1.9 safe. However, the version at Github (2.1) is. http://github.com/tobi/liquid http://github.com/tobi/liquid Since the commit to fix Liquid for 1.9.1 was in April of 2009, I wonder why it's not the version on Gemcutter? (Or some version of that version, if there are other issues...) Edit: Yup, just checked. Jekyll with Liquid 2.1 is fine on 1.9.1. (I'm on OSX here, but the 1.9.1 I checked is also patch level 378.) All of that said, rvm is outstanding.
papertiger 16y ago
I find the frequent major changes in the Ruby ecosystem to be quite frustrating. That's not to say that I wish this progress wouldn't occur... I just wish it would occur in a more controlled manner. Documentation seems to suffer the most and I have definitely come across a few libraries that don't "just work". I love Ruby and the Ruby community, but I long for the day when things move at a less frenzied pace... I know it would put my managers at ease, too.
donw 16y ago
I will be happier when more Ruby coders take the time to actually document their code; rolling through the Rails source has been an exercise in pain, even with all the cleanups that have gone into Rails 3. I recall an unhappy core contributor awhile back ranting about how people file bug reports but not fixes; the reason is because it takes a significant time investment to find and fix problems if you aren't a core contributor and have no interest in becoming one. Sinatra and Sequel do it right -- solid documentation, both on the website, and in the .rb files.

104 points by Jim_Neath 16y ago

Paolo sounds a bit like a fanboy but he makes a lot of interesting points. I work in a Clojure+Java shop yet I use Ruby whenever I can get away with it because it is the fastest language (for me) for getting stuff done. The article talks about Ruby's ecosystem, and that is key to Ruby productivity. That said, I think that Clojure will be super-awesome in a few years as its ecosystem continues to develop.

angelbob 16y ago

Much as I love Ruby and all the things he talks about, I worry that publicizing all these self-congratulatory posts about the Ruby community will create a lot more resistance to what we do. I get the impression that that's how SmallTalk died.

aaronblohowiak 16y ago
It is my impression that corporate drama around the smalltalk vendors helped to quicken its demise. Image-based development (in the smalltalk, not "rockstar" sense of image) also didn't sit well with a lot of people, though there were projects to support exporting source to files.
- nmk 16y ago
  GNU Smalltalk supports both file based and image based development. Exporting source files is no means to an end — image based development is not widespread because it forces people out of emacs and vim.
  - masklinn 16y ago
    Smalltalk "died" before GNU Smalltalk was even usable, if it existed at all.
    - stcredzero 16y ago
      GNU Smalltalk has been around a very, very long time. It was also just about the gimpiest Smalltalk environment out there. Most of the people on the commercial environments just wished it would go away, because so many people downloaded it to try it and got the wrong impression of what Smalltalk is about. In the mid to late 90's, Smalltalk was still going strong. (It still is by some accounts.) I used GNU Smalltalk back then and it was pitifully gimpy in comparison to the commercial environments. If you want to check out Smalltalk, check out Squeak or Pharo. You can also download VisualWorks noncommercial. Also, to be fair, GNU Smalltalk has come a long way since then.
      - masklinn 16y ago
        > If you want to check out Smalltalk, check out Squeak or Pharo. You can also download VisualWorks noncommercial. If you're running a windows machine, I found Dolphin pretty enjoyable (if the noncommercial edition is still available, i believe they're working on their next generation but x6 was pretty nice)
- stcredzero 16y ago
  It is my impression that corporate drama around the smalltalk vendors helped to quicken its demise. Absolutely true! The merger-politics, the marketing missteps, and the cool technology that got buried are all epic. Image-based development also didn't sit well with a lot of people Not so true, for those who really "got it" and hit their stride, and anyone who comments who didn't get to that point is commenting as a clueless newbie. In image-based development, all of your programming meta-data are there as live Objects, instantly scriptable, totally and instantly obedient to your every whim. Ditto for runtime state -- everything available as live Objects and instantly scriptable. Really, once you learn a suitable style, it's heavenly, intoxicating and addictive. The same thing is true for Python and Ruby, but only about half as much. For example, a lot of advanced IDE functions require one to detect changes to files and re-parse things to keep programming metadata current. That problem just vanishes with image-based development. Literally hundreds of problems just vanish because everything is an object and they're all instantly available. On the other hand, image-based deployment SUCKS. Sucks sucks sucks. Just about every Smalltalker agrees. The big advantage of being file based is that your development test environment resembles your deployment, or is at least halfway to deployment by comparison. Image-based Smalltalk development is like the ultimate monkey-patching uber-debugger. Very cool to develop in, but you do not want to give it to your users!
  - deleted 16y ago
    [deleted]
  - cageface 16y ago
    Isn't it possible in image-based environments to have live objects but not the code that created them? This idea makes me extremely uneasy. Being able to derive everything in a running system from source code seems almost necessary for maintainability and comprehensibility.
    - stcredzero 16y ago
      You have that in the Smalltalk environment in the Changes Log. It is -- wait for it -- a text file! In fact, it gives you database-log like replay-ability in your entire development environment. "Being able to derive everything in a running system from source code," is exactly what it's for, and it's actually more capable and powerful than what you can get from source files. All of that scripting against the objects I was talking about? You can replay all that stuff too! If you do something stupid-dangerous like, "Semaphore allInstances do: [ :each | each release ]" then you can just exclude that last action when you replay the Change Log. Combined with image save, it gives you the freedom to live as dangerously as you like! The classic demo -- have your students spend 1/2 hour writing some toy system. Then have them hard-reboot their machines without saving the image. Show them how they can restart the image, grab the Change List tool, and voila, all their source code is back! To answer your question: it's possible that the source can be absent, but you have to execute an explicit command or do some sort of willful sabotage to make it happen that way. Really, it isn't so different from having separate source and executable files.
smitjel 16y ago
I'd like to think that concrete examples of ruby's successful production deployments and higher developer productivity mean more to companies than some blog ramblings.
- angelbob 16y ago
  You'd think. And yet, the "Rails doesn't scale" meme survived for a remarkably long time... Still does, really.
petercooper 16y ago
The difference is that Rubyists just get on with shipping code and products without obsessing over the one true toolkit or vendor.
skybrian 16y ago
My impression from this post (as someone more familiar with Java and Python but who has tried Ruby a bit) is that it's a complex, fast-moving ecosystem that's somewhat difficult to keep up with. Not a bad thing, but a bit daunting for people who don't do it full time. There are other fast-moving ecosystems that I already have to keep up with. It likely has the side effect that that web searches will bring up a lot of obsolete articles.

jamesbritt 16y ago

"So, where did the once-vocal Ruby community go?" Well, it turns out there are many Ruby communities, some vocal, some not. Talking abut the Ruby community is going to end up missing a lot of what is going on. Mostly, though when people talk about a singular Ruby community they mean Rails. "In a world where a standard can take years to be discussed, approved, implemented and supported, Ruby standards such as Rack skip from conception to widespread support at blazing speed." Wish the same could be said for Ruby itself. Everyone who's completely moved to 1.9, raise your hand. Overall the points made are interesting, but much the same is happening in other language communities. People building stuff in Haskell, Clojure, JavaScript, Scala, etc. are more than happy to steal the best ideas from other realms and make them their own. So long as people don't start believing in The One True Framework or The One True Languge, we're doing quit well.

manveru 16y ago
Seems like there are now around 1/4 on 1.9: http://survey.hamptoncatlin.com/survey/stats http://survey.hamptoncatlin.com/survey/stats I expect that to increase a lot once 1.9.2 is out and Rubinius, MacRuby, and JRuby match the spec. And I raise my hand, I'm happily on 1.9 for over a year now.
- jamesbritt 16y ago
  "Rubinius, MacRuby, and JRuby match the spec." What specs do they all match right now? The implementation teams are doing stunning work, but last I heard they were not all completely compatible and complete. "And I raise my hand, I'm happily on 1.9 for over a year now." Sure, but you're part of one those quiet Ruby communities that gets ignored by surveys such as Hampton's.
  - WALoeIII 16y ago
    Rubinius, MacRuby and JRuby are all 1.8 implementations now with 1.9 still on the roadmap.
petercooper 16y ago

cageface 16y ago

Agreed. I was a little worried about the state of ruby a few years ago when MRI was flaky and Rails deployment was a real hassle but now it's just such a productive and pleasant environment to work in. There's still work to do, of course, but I still reach for Ruby when I need to get something done quickly.

adbge 16y ago

I do my dev on an archlinux box and the standard Ruby version in the repo (1.9.1_p378-2, I think) was doing something screwy to Jekyll. After reading this article, I checked out RVM and installed a couple different Ruby versions to play with. If you're doing anything with Ruby, I'd definitely suggest checking it out. Set up a 1.8.7-head install inside of RVM and fixed all my Jekyll woes. It also gave me a chance to play with Rubinius and the latest 1.9.3dev release. I always enjoyed being able to use eselect to switch between Ruby versions on Gentoo and RVM is able to duplicate this functionality and then some.

steveklabnik 16y ago
Ruby 1.9.1 had some pretty serious threading issues, if I remember. 1.9.2 fixed them. Don't know if that'd affect Jekyll, but I know it affected Rails.
telemachos 16y ago
To the best of my recollection, Jekyll itself plays nicely with 1.9.1. It's Liquid that was a problem for me. The Gemcutter.org version of Liquid (2.0) is not 1.9 safe. However, the version at Github (2.1) is. http://github.com/tobi/liquid http://github.com/tobi/liquid Since the commit to fix Liquid for 1.9.1 was in April of 2009, I wonder why it's not the version on Gemcutter? (Or some version of that version, if there are other issues...) Edit: Yup, just checked. Jekyll with Liquid 2.1 is fine on 1.9.1. (I'm on OSX here, but the 1.9.1 I checked is also patch level 378.) All of that said, rvm is outstanding.

papertiger 16y ago

I find the frequent major changes in the Ruby ecosystem to be quite frustrating. That's not to say that I wish this progress wouldn't occur... I just wish it would occur in a more controlled manner. Documentation seems to suffer the most and I have definitely come across a few libraries that don't "just work". I love Ruby and the Ruby community, but I long for the day when things move at a less frenzied pace... I know it would put my managers at ease, too.

donw 16y ago

I will be happier when more Ruby coders take the time to actually document their code; rolling through the Rails source has been an exercise in pain, even with all the cleanups that have gone into Rails 3. I recall an unhappy core contributor awhile back ranting about how people file bug reports but not fixes; the reason is because it takes a significant time investment to find and fix problems if you aren't a core contributor and have no interest in becoming one. Sinatra and Sequel do it right -- solid documentation, both on the website, and in the .rb files.