3 ms·

Reminds me of Ruby, IMHO the version jump from 1.8.7 to 1.9.* killed it. Different scoping rules made porting a non-trivial task, many packages have never been

Reminds me of Ruby, IMHO the version jump from 1.8.7 to 1.9.* killed it. Different scoping rules made porting a non-trivial task, many packages have never been ported to 1.9 and one of the early 1.9.* major releases was extremely buggy... Nowadays hardly anybody seems to use Ruby for new projects...

akerl_ 12y ago
I can't tell if this is a poor attempt at sarcasm, but if not: Do you have evidence to back up the claim that Ruby isn't being used for new projects? Even assuming HN is a skewed environment, I see enough Ruby projects popping up here to make that seem unlikely.
- blablabla123 12y ago
  Yes, not sure how much evidence you need. I mean just look at the Tiobe Index: http://www.tiobe.com/content/paperinfo/tpci/images/history_Ruby.png http://www.tiobe.com/content/paperinfo/tpci/images/history_R... 1.9 was initially released 2007, 1.9.1 was released in 2009... Not sure if you remember it, but one of the early 1.9 releases was reeeeally buggy.
Argorak 12y ago
Quite on the contrary. 1.9-compat was very quickly expected of all libs and all important core libs run better on >1.9. 1.9 was the cleanup release after the language became popular and very necessary. Also, everything before 1.9.2 was considered a preview release.
- dragonwriter 12y ago
  > Quite on the contrary. 1.9-compat was very quickly expected of all libs and all important core libs run better on >1.9. That's quite some historical revisionism -- there was quite a while when quite a lot of libraries weren't running on 1.9. It wasn't as bad as with Python, probably because Ruby wasn't popular for as long as Python was, so there weren't as many big libraries that were hard to update. But it was a huge deal. > 1.9 was the cleanup release after the language became popular and very necessary. It was necessary for much the same kind of reasons (and, sometimes, the exact same specific reasons) as Python 3 -- particularly, the string encoding problem.
  - Argorak 12y ago
    > That's quite some historical revisionism I concur. The _expectancy_ that libraries should be updated was there pretty quickly. New libraries were generally created with both versions in mind. It was a huge porting effort, especially with 1.9.0 being very buggy, but there was a general sense in the community that you need to port or die.
- blablabla123 12y ago
  At least the whole Google Appengine Ruby suite never worked on 1.9. Also JRuby took some time to be 100% 1.9 compatible.
pmontra 12y ago
We're at Ruby 2.1.x and every single gem I used in the past six months has been ported to it. I use Ruby only for Rails so I might be seeing a small environment, but it's 96 gems in the project I have in my editor right now. There are still many new projects in Ruby. I probably make half of my income with them.
- dragonwriter 12y ago
  > We're at Ruby 2.1.x and every single gem I used in the past six months has been ported to it. Yeah, but 2.x didn't have major breaking changes. The big breaking change from 1.8.x that parallels the Python 2->3 change was 1.9, which has been out for two years longer than Python 3.

akerl_ 12y ago

I can't tell if this is a poor attempt at sarcasm, but if not: Do you have evidence to back up the claim that Ruby isn't being used for new projects? Even assuming HN is a skewed environment, I see enough Ruby projects popping up here to make that seem unlikely.

blablabla123 12y ago
Yes, not sure how much evidence you need. I mean just look at the Tiobe Index: http://www.tiobe.com/content/paperinfo/tpci/images/history_Ruby.png http://www.tiobe.com/content/paperinfo/tpci/images/history_R... 1.9 was initially released 2007, 1.9.1 was released in 2009... Not sure if you remember it, but one of the early 1.9 releases was reeeeally buggy.

Argorak 12y ago

Quite on the contrary. 1.9-compat was very quickly expected of all libs and all important core libs run better on >1.9. 1.9 was the cleanup release after the language became popular and very necessary. Also, everything before 1.9.2 was considered a preview release.

dragonwriter 12y ago
> Quite on the contrary. 1.9-compat was very quickly expected of all libs and all important core libs run better on >1.9. That's quite some historical revisionism -- there was quite a while when quite a lot of libraries weren't running on 1.9. It wasn't as bad as with Python, probably because Ruby wasn't popular for as long as Python was, so there weren't as many big libraries that were hard to update. But it was a huge deal. > 1.9 was the cleanup release after the language became popular and very necessary. It was necessary for much the same kind of reasons (and, sometimes, the exact same specific reasons) as Python 3 -- particularly, the string encoding problem.
- Argorak 12y ago
  > That's quite some historical revisionism I concur. The _expectancy_ that libraries should be updated was there pretty quickly. New libraries were generally created with both versions in mind. It was a huge porting effort, especially with 1.9.0 being very buggy, but there was a general sense in the community that you need to port or die.
blablabla123 12y ago
At least the whole Google Appengine Ruby suite never worked on 1.9. Also JRuby took some time to be 100% 1.9 compatible.

pmontra 12y ago

We're at Ruby 2.1.x and every single gem I used in the past six months has been ported to it. I use Ruby only for Rails so I might be seeing a small environment, but it's 96 gems in the project I have in my editor right now. There are still many new projects in Ruby. I probably make half of my income with them.

dragonwriter 12y ago
> We're at Ruby 2.1.x and every single gem I used in the past six months has been ported to it. Yeah, but 2.x didn't have major breaking changes. The big breaking change from 1.8.x that parallels the Python 2->3 change was 1.9, which has been out for two years longer than Python 3.