5 ms·

Ruby has put food on my table for the better part of the last fifteen years and there's a lot I love about the language. But it also feels increasingly unlikely

Ruby has put food on my table for the better part of the last fifteen years and there's a lot I love about the language. But it also feels increasingly unlikely that it will escape the Rails ecosystem to any significant extent. In the dynamic language space Javascript seems unstoppable and with the ES6 and ES7 features and vastly better performance I don't see much advantage in sticking with Ruby in the long run other than the excellent Gem ecosystem. And for larger codebases I think opt-in typing a-la Typescript is a huge win. I'll always applaud creative projects like this but I'm not optimistic about the longer term health of Ruby at this point.

Argorak 12y ago
> But it also feels increasingly unlikely that it will escape the Rails ecosystem to any significant extent. It already did, with Puppet, Chef and Vagrant. Also, mruby is gaining adoption and Rubymotion seems to be in an interesting niche. There's a lot of new projects currently (like Lotus), so I wouldn't as negative as this. Also, don't ignore the foothold that Ruby has in the asian markets.
- Kalium 12y ago
  Puppet is only "escaping" in that it's implemented in Ruby. It's not people outside the Rails world picking up Ruby. Chef, in my experience, is favored almost exclusively by people who are already Rubyists. The concept of applying The Power Of Ruby (TM) to system configuration is not attractive to non-Rubyists. I don't see Vagrant much these days. I suspect Docker is displacing it.
  - pwelch 12y ago
    The fact that Ruby is the language chosen to implement these tools is the proof it's not just for Rails. Also, Docker may become more popular but I doubt it is going to replace Vagrant. There are just too many times where you need a full VM instead of a container process. Not every problem can be solved with containers.
    - Argorak 12y ago
      Also where do you test your docker containers in?
- btucker 12y ago
  Also, SketchUp. (http://www.sketchup.com/intl/en/developer/ http://www.sketchup.com/intl/en/developer/)
infraruby 12y ago
> And for larger codebases I think opt-in typing a-la Typescript is a huge win. You can have static typing with InfraRuby (at http://infraruby.com/live http://infraruby.com/live), and it's opt-in in the sense that InfraRuby code runs on Ruby interpreters without modification, but (un)fortunately InfraRuby doesn't support reflection so it doesn't run Rails.
pjmlp 12y ago
Ruby devs could look at Dylan and Lisp for inspiration how to improve the language performance, but I doubt it will ever happen. Me personally, I tinkered with Ruby when Rails initially came out and it was about it, as it didn't brought anything new to my toolset.
- cageface 12y ago
  I found Rails to be a massive productivity boost from the Java frameworks that I was using at the time (Tapestry, Struts, etc). And I still think it's the most productive framework for the typical web CRUD app. But the typical web CRUD app is a dying breed these days and the poor performance and maintainability of Ruby/Rails for building fast, concurrent APIs puts it at a disadvantage.
  - gentoopenguin 12y ago
    I wonder how much of Ruby's adoption was driven by Rails, and how much of Rails' adoption was driven by developers who previously only had experience with languages like Java or PHP. I say this because as nice as Ruby is (at least in some ways), someone already familiar with Lisp or Smalltalk will learn nothing new from it, and yet there are no shortage of blog posts by Rubyists touting its borrowed features as if they didn't exist before Ruby, suggesting, perhaps, ignorance on the part of its more vocal advocates and of those persuaded by them
    - cageface 12y ago
      I actually got into Ruby before Rails hit and was immediately taken by it because it brought some of the best features of Lisp and Smalltalk and Icon into a language with a very practical, unix-friendly implementation. So I could drop in Ruby where I previously might have used Python or Perl. This was much harder to do with Lisp or Smalltalk, for example. But I didn't have a good excuse to really use it at work until Rails came along and completely blew the existing Java frameworks out of the water for productivity.
    - vidarh 12y ago
      I've used 20+ languages over the years, and Ruby is by far my favourite not because it has "new" features, but because of it does it's best to ensure syntax gets out of the way. And that is incidentally why I have no interest in Lisp or Smalltalk. I have a very visual interpretation of code. I can remember the visual layout of programs I worked on 20 years ago. Those visuals matters greatly to me to be productive with code, and means I am extremely picky about formatting that works for me, and I have nothing but hate for the layout of Lisp and Smalltalk code. I'm greatful for all the great stuff to have come out of Lisp and Smalltalk. I just pefer to use those features in the nice embrace of Ruby syntax.
geniium 12y ago
+1
gentoopenguin 12y ago
What I can't understand is why Ruby's standard implementation still has such terrible performance after all these years. Yes, the language is quite complicated, at least syntactically, but semantically it's similar enough to Smalltalk, and most Smalltalks have fast jitting VMs, including Squeak and Pharo (CogVM). The Ruby community is enormous by comparison and full of productive, opinionated developers who write tons of code, books, and blog posts, and yet the standard implementation (MRI) remains abysmal (sorry). It's really unfortunate that the MRI devs won't support Rubinius or event adopt RSpec to ensure interoperability with it: http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use-rubyspec/ http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use...
- cageface 12y ago
  I've wondered about this too and my best guess it that writing a good optimizing compiler for a dynamic language like Ruby or Javascript is quite difficult and beyond the abilities of most developers. The JS engines in the major browsers are only fast because tremendous resources have been devoted to making them fast. I don't think PyPy or Rubinius have had anything close to the same level of investment. This is why I think JS is pretty much guaranteed to "win" the dynamic language race in the long run.
  - pjmlp 12y ago
    Alongside Julia, most likely.
  - MrBra 12y ago
    You're reasoning is taking a bit too much for granted that the best engineered solutions will be the ones coming off big corporations investments but in this field this has been proven wrong many times... that's not always the one and only win factor.. fortunately.
    - cageface 12y ago
      It's true that LuaJit is mostly the work of one person, as far as I understand. Maybe talent does take precedence in most cases. But the incentive for browser developers to improve and optimize JS is just vastly stronger, despite its flaws, for practical reasons. The impact of the work is just orders of magnitude larger.
nateberkopec 12y ago
I'm optimistic about the future of Ruby speed. We've seen a lot of improvement in the 2.x series of releases, to the point where we're as-fast-or-faster than Python in most cases. I'm also very optimistic on the future of JRuby, as with the new 9000 release it has the potential to bring Ruby speed in line with base Java. It's got decent corporate backing now as well with Red Hat and Oracle funding people to work on it.
MrBra 12y ago
Are you sure? From https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List#mri-matz-ruby-interpreter https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List#mri-mat... "List of ideas for improving Ruby during Google Summer of Code 2015", little summary: - Fine-grained locking (a.k.a. removing the MRI global lock) - JIT Compiler - Type System - New C Extension API - Cross-thread Fiber support

Argorak 12y ago

> But it also feels increasingly unlikely that it will escape the Rails ecosystem to any significant extent. It already did, with Puppet, Chef and Vagrant. Also, mruby is gaining adoption and Rubymotion seems to be in an interesting niche. There's a lot of new projects currently (like Lotus), so I wouldn't as negative as this. Also, don't ignore the foothold that Ruby has in the asian markets.

Kalium 12y ago
Puppet is only "escaping" in that it's implemented in Ruby. It's not people outside the Rails world picking up Ruby. Chef, in my experience, is favored almost exclusively by people who are already Rubyists. The concept of applying The Power Of Ruby (TM) to system configuration is not attractive to non-Rubyists. I don't see Vagrant much these days. I suspect Docker is displacing it.
- pwelch 12y ago
  The fact that Ruby is the language chosen to implement these tools is the proof it's not just for Rails. Also, Docker may become more popular but I doubt it is going to replace Vagrant. There are just too many times where you need a full VM instead of a container process. Not every problem can be solved with containers.
  - Argorak 12y ago
    Also where do you test your docker containers in?
btucker 12y ago
Also, SketchUp. (http://www.sketchup.com/intl/en/developer/ http://www.sketchup.com/intl/en/developer/)

infraruby 12y ago

> And for larger codebases I think opt-in typing a-la Typescript is a huge win. You can have static typing with InfraRuby (at http://infraruby.com/live http://infraruby.com/live), and it's opt-in in the sense that InfraRuby code runs on Ruby interpreters without modification, but (un)fortunately InfraRuby doesn't support reflection so it doesn't run Rails.

pjmlp 12y ago

Ruby devs could look at Dylan and Lisp for inspiration how to improve the language performance, but I doubt it will ever happen. Me personally, I tinkered with Ruby when Rails initially came out and it was about it, as it didn't brought anything new to my toolset.

cageface 12y ago
I found Rails to be a massive productivity boost from the Java frameworks that I was using at the time (Tapestry, Struts, etc). And I still think it's the most productive framework for the typical web CRUD app. But the typical web CRUD app is a dying breed these days and the poor performance and maintainability of Ruby/Rails for building fast, concurrent APIs puts it at a disadvantage.
- gentoopenguin 12y ago
  I wonder how much of Ruby's adoption was driven by Rails, and how much of Rails' adoption was driven by developers who previously only had experience with languages like Java or PHP. I say this because as nice as Ruby is (at least in some ways), someone already familiar with Lisp or Smalltalk will learn nothing new from it, and yet there are no shortage of blog posts by Rubyists touting its borrowed features as if they didn't exist before Ruby, suggesting, perhaps, ignorance on the part of its more vocal advocates and of those persuaded by them
  - cageface 12y ago
    I actually got into Ruby before Rails hit and was immediately taken by it because it brought some of the best features of Lisp and Smalltalk and Icon into a language with a very practical, unix-friendly implementation. So I could drop in Ruby where I previously might have used Python or Perl. This was much harder to do with Lisp or Smalltalk, for example. But I didn't have a good excuse to really use it at work until Rails came along and completely blew the existing Java frameworks out of the water for productivity.
  - vidarh 12y ago
    I've used 20+ languages over the years, and Ruby is by far my favourite not because it has "new" features, but because of it does it's best to ensure syntax gets out of the way. And that is incidentally why I have no interest in Lisp or Smalltalk. I have a very visual interpretation of code. I can remember the visual layout of programs I worked on 20 years ago. Those visuals matters greatly to me to be productive with code, and means I am extremely picky about formatting that works for me, and I have nothing but hate for the layout of Lisp and Smalltalk code. I'm greatful for all the great stuff to have come out of Lisp and Smalltalk. I just pefer to use those features in the nice embrace of Ruby syntax.

geniium 12y ago

gentoopenguin 12y ago

What I can't understand is why Ruby's standard implementation still has such terrible performance after all these years. Yes, the language is quite complicated, at least syntactically, but semantically it's similar enough to Smalltalk, and most Smalltalks have fast jitting VMs, including Squeak and Pharo (CogVM). The Ruby community is enormous by comparison and full of productive, opinionated developers who write tons of code, books, and blog posts, and yet the standard implementation (MRI) remains abysmal (sorry). It's really unfortunate that the MRI devs won't support Rubinius or event adopt RSpec to ensure interoperability with it: http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use-rubyspec/ http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use...

cageface 12y ago
I've wondered about this too and my best guess it that writing a good optimizing compiler for a dynamic language like Ruby or Javascript is quite difficult and beyond the abilities of most developers. The JS engines in the major browsers are only fast because tremendous resources have been devoted to making them fast. I don't think PyPy or Rubinius have had anything close to the same level of investment. This is why I think JS is pretty much guaranteed to "win" the dynamic language race in the long run.
- pjmlp 12y ago
  Alongside Julia, most likely.
- MrBra 12y ago
  You're reasoning is taking a bit too much for granted that the best engineered solutions will be the ones coming off big corporations investments but in this field this has been proven wrong many times... that's not always the one and only win factor.. fortunately.
  - cageface 12y ago
    It's true that LuaJit is mostly the work of one person, as far as I understand. Maybe talent does take precedence in most cases. But the incentive for browser developers to improve and optimize JS is just vastly stronger, despite its flaws, for practical reasons. The impact of the work is just orders of magnitude larger.

nateberkopec 12y ago

I'm optimistic about the future of Ruby speed. We've seen a lot of improvement in the 2.x series of releases, to the point where we're as-fast-or-faster than Python in most cases. I'm also very optimistic on the future of JRuby, as with the new 9000 release it has the potential to bring Ruby speed in line with base Java. It's got decent corporate backing now as well with Red Hat and Oracle funding people to work on it.

MrBra 12y ago

Are you sure? From https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List#mri-matz-ruby-interpreter https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List#mri-mat... "List of ideas for improving Ruby during Google Summer of Code 2015", little summary: - Fine-grained locking (a.k.a. removing the MRI global lock) - JIT Compiler - Type System - New C Extension API - Cross-thread Fiber support