7 ms·

Rails 3.2.13 - Performance regressions and major bugs

125 points by sephine 14y ago

scottshea 14y ago
You know when you're already having performance issues on Heroku having a performance regression is not fun.
- nifoc 14y ago
  How is this > […] handing that task to Sprockets instead of resolving internally […] even remotely related to performance issues because of random routing? You're mixing two issues that have nothing in common.
  - josephlord 14y ago
    1) Grandparent has performance problems on Heroku. 2) The Rails release has performance regressions (i.e. in at least some scenarios is slower). In situation (1) you don't want to add further slowdown so (2) is a bad thing. Grandparent doesn't even blame his Heroku performance problems on the routing issue (although it is a plausible guess). Actually effect of the routing problem can be significantly worsened if even a subset of requests are slowed down.
    - nifoc 14y ago
      I'm under the impression that the Sprockets regression should not affect you in production, because your assets are precompiled. Is that not the case?
      - josephlord 14y ago
        To be honest I don't know and I wouldn't have negatively responded to a comment indicating that or questioning it. However reading the article it sounds like it is an issue resolving asset paths so may affect you even when assets are precompiled. Performance Regressions There are performance regressions in 3.2.13 for both view loading and asset loading. Rails 3.2.13 changed the way assets paths are resolved, handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues.
        fredwu 14y ago
        Actually, the performance degradation to the precompiled assets is minimal - for a typical production environment it only effects your asset compiling time as the assets are served statically from your public directory.
- kawsper 14y ago
  The asset path and sprocket performance hit doesn't seem to affect most Rails apps, they precompile their assets, so that shouldn't be a problem.
  - calinet6 14y ago
    But it does slow down dev, which doesn't not suck.
sergiotapia 14y ago
At this point I'm seriously considering dropping Rails as my framework of choice and reverting back to ASP.Net MVC. Why? 1. Security fixes are released very quickly (good thing), but more often then not they break existing code (bad thing) - and while you _can_ wait for the next patch to fix those break points, you're left wide open since everybody can see what was broken and how to exploit it. 2. I'm not nearly smart enough with Ruby to apply 'band-aids' I read people write in Rails source code. I just don't have the time and energy to fix code in the actual framework when I need to be fixing _my_ code. ====== So there you have it; I'm bailing. It was a fantastic ride, Ruby is a beautiful language, but Rails is just a clusterfuck (_for me_). I need stability and predictable behavior. If that means releases every 6 month to 1 year, so be it. So long and thanks for all the gems.
- masklinn 14y ago
  You do know there are other Ruby frameworks than Rails, and other development environments than ASP and Ruby right?
  - sergiotapia 14y ago
    Yes, I used to use ASP.Net MVC for pet projects, then switched to Rails - I also use CakePHP and Django for actual paying work/contracting. But thanks for the passive aggresive comment.
    - JonnieCache 14y ago
      While that may be a passive aggressive comment, sinatra is bloody brilliant all the same. You can basically pretend you're writing rails code, but with a tiny fraction of the dependencies, and actual fast response times. Sinatra, sequel and postgresql is a dream combo. I wouldn't use rails for a new project these days, I got bored of the un-navigable code a while ago. These patches and regressions are the icing on the cake.
    - masklinn 14y ago
      > Yes Because your comment didn't exactly hint at it considering its completely binary assertion of "Rails or ASP" > But thanks for the passive aggresive comment. I'm very sorry you found it passive, that was not intended.
ryanSrich 14y ago
As someone who is relatively new to Rails can someone explain to me why it seems to update more than anything else I've used?
- davidw 14y ago
  Mostly to give people on forums something to bitch about. Serious answer: a few months ago, some serious vulnerabilities were found in Rails. This apparently had a "blood in the water" effect on security people, who started dissecting the entire thing. Predictably, more vulnerabilities have emerged and rapidly been fixed. All in all, it means that things are improving because it's getting a ton of attention.
  - philipDS 14y ago
    This. I think the rapid release cycle of Rails is a good thing, rather than a bad thing. The past few months, some serious vulnerabilities were found in Rails, and I guess this made the Rails core team a little anxious. One might argue that these performance regressions are unacceptable, and they are. I agree. Still, Rails is relatively young framework and these things happen. I expect any framework that is widely used will see some serious vulnerabilities in the next few months/years. By the way, a good explanation of what these past Rails security issues mean is explained on patio11's blog (http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/ http://www.kalzumeus.com/2013/01/31/what-the-rails-security-...). OT: I'm also writing a book on upgrading your Rails 3 app to Rails 4. With these rapid releases, a lot of things change and it's not always clear what has changed or what is new. Feel free to check it out at http://upgradetorails4.com/ http://upgradetorails4.com/.
- evilduck 14y ago
  Bad timing. The JVM has had an abnormal increase in security patches over the same time frame too.
- bluedino 14y ago
  You don't have to stay on the bleeding edge. We're stuck with Ruby 1.8.7, and we've got a mix of Rails 1, 2, and 3 apps. For better or for worse.
thinkbohemian 14y ago
Not happy? Do something about it: try release candidates, report bugs, and help triage and fix reported bugs.
- calinet6 14y ago
  Ok, yes, that's an extremely great and open-source way to handle this. But seriously, can we at least expect moderately stable releases? I do not think that's too much to ask, especially for a framework which has, in the past, achieved that.
- foobar2k 14y ago
  I completely agree with this. We (bugsnag) are running on rails 4 beta right now to help iron out any production issues before that is released. We didn't, however, realize that "patch" releases also have release candidates. I'd recommend following the rails blog (http://weblog.rubyonrails.org/ http://weblog.rubyonrails.org/) which announces release candidate builds too.
  - thibaut_barrere 14y ago
    Thanks for the blog post - and I didn't realize that patch releases also had RC. It looks like this release was quite fat, for a patch release. I added "check rails diff" to my deploy todo list. EDIT: I just noticed that http://weblog.rubyonrails.org/ http://weblog.rubyonrails.org/ doesn't have a way to subscribe by email. I signed-up by email with this site instead http://blogtrottr.com http://blogtrottr.com, in case it helps other here.
  - thinkbohemian 14y ago
    You can also subscribe to the rails-core mailing list, all betas, RC and full releases get announced there.
    - thibaut_barrere 14y ago
      There's quite a bit more discussions on rails-core apart from RC and releases, so subscribing to the blog is a good idea if your time is limited :-)
jrochkind1 14y ago
Okay, some of these problems are (unintended) direct side effects of the security fix bugs. Like I the one about scopes that effected Github -- github quoted [this commit](https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23 https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...) as introducing the bug, which is the commit meant to address CVE-2013-1854. So, okay, bugs happen, even with security fixes, I can forgive bugs. But others of those performance regressions... " handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues." This doesn't sound like the unanticipated side effect of a security fix. This _sounds_ like an independent change they threw into the same patch release with four (four!) security patches. Why is Rails putting security fixes and other non-security-related enhancements together in the same patch, so you can't get the security fixes without also getting the possibly buggy new features/refactors? Does Rails actually do this by policy? Was it a mistake? Bugs happen, including bugs in security fixes, sure. But it's BECAUSE bugs will happen that you don't throw unrelated new features or refactors into the same patch release as a security patch, so the only way to get the security patch is to risk MORE problems from the other stuff too! Come on!
- badgar 14y ago
  AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs. This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.
  - obviouslygreen 14y ago
    And as is to be expected with Rails at this point, point releases break apps. As a primarily Django guy with an interest in Rails... is this hyperbole/overstatement or is this a common perception?
    - hoka 14y ago
      I'm also a Python dev, and my observation from several threads here (and elsewhere) is that the perception is quite common. IANARailsDev, obviously.
FuzzyDunlop 14y ago
I think the only mistake made with this patch release was merging in 250+ commits, ranging from last year to the present day. Maybe that's standard for such a large project, but it feels like a hell of a lot of tweaks for a minor release. As for the rest - I think the issues in January has put Rails in the spotlight, and while scrutiny is certainly warranted, I think the extra pressure on the project over the past months to clear this stuff up has had its consequences.
- yxhuvud 14y ago
  I think the problem is that they do too many patch releases and not enough minor releases. This could easily have been a minor.
renownedmedia 14y ago
Since when do Rails developers worry about performance?
1qaz2wsx3edc 14y ago
296 commits for a security patch is silly; What the shit tenderlove.
- calinet6 14y ago
  Seriously. Usually Rails feels like riding in an Uber, but this release felt like Crazy Taxi.
ChrisInEdmonton 14y ago
There's been a few people suggesting that, if you are bitten by a bug, you fix it and submit a pull request. That's a good idea. I did exactly this to a regression introduced in 3.2.9, complete with a unit test and a pull request against 3-2-stable and one against master. It took two months to get anyone to look at it, and while one of the two pull requests has a thumbs-up, it's still not been merged. Admittedly, this isn't a security issue as far as I can see, but still.
- steveklabnik 14y ago
  I personally read every single issue and comment filed against rails/rails. I often don't comment if it's not a part of the codebase I'm not familiar with, and it's the same with merging. Can you point me to the specific ones so I can look at them again?
  - tvongaza 14y ago
    Pretty sure Chris is talking about: https://github.com/rails/rails/issues/8856 https://github.com/rails/rails/issues/8856
    - steveklabnik 14y ago
      Ah yes, ActiveRecord is one of those parts I am _not_ an expert in.
  - ChrisInEdmonton 14y ago
    Yeah, tvongaza is correct. Admittedly, it's not a _big_ issue, and perhaps I'm going about things the wrong way. If you could tell me a better way of getting this issue fixed, I'd love to hear it. The only other time I tried, it took more than two years. Luckily, it was pretty easy to monkey-patch our own code to deal with this, once it broke our live site.
    - steveklabnik 14y ago
      Other than tenderlove and (sort of) myself, nobody is paid to work on Rails. This means that it's an entirely volunteer effort, and people's lives are busy, so sometimes, tickets take a while to merge. I try to stay on top of it actively and thing still sometimes slip through the cracks for me. It's not that you're going about it the wrong way, it's that projects with ~200 open pulls are slow to merge, sometimes. Sorry it's taking so long with this one. :/ I'll bump this up in my personal list; I should really learn AR better anyway.
bratsche 14y ago
I disagree with the final statement of this, that a "security only" release would have somehow helped the situation. I feel like part of the problem is that things are being merged into 3-2-stable and nobody is using them because they're never put into a release. 3.2.11 and 3.2.12 were both security-only releases, and so fixes and patches that were not security-related have just been piling up for the longest time. Seems like a "release often" mindset might be better and might ensure that things are actually being used. Sure, I know someone is going to blast me saying that bugs like this shouldn't make it into 3-2-stable at all, and since this is Hacker News so whoever says that knows they're ten times the developer that everyone on the Rails core team is. But the reality is that bugs make it into stable branches, and almost nobody is running against the stable branch (Rails core people are probably mostly running against the 4.0 branch, everyone else is running against the latest release).
- mnarayan01 14y ago
  Actually 3.2.12 also added some sort of silly (and broken) patch related to quoting numeric values in ActiveRecord. The primary thing I want out of 3.2.13 is reverting this. To your more general point, while I don't disagree with your diagnosis of things piling up in stable, I'm also not a big fan of your proposed solution. It looks to me like 3-2-stable is getting filled with a lot of stuff that just should not there; increasing the release frequency is not going to solve this problem.
asm_o_dan 14y ago
Rails - ruining Ruby and putting the fail train on the right tracks since 2004.
martinced 14y ago
I'm sure that Rails is great and powers many websites and that many devs loves it. I'm also sure that people are working hard to fix these recent security issues and perfs issues. But as a non-Rails dev I can tell you one thing: with all the attention that Rails got lately I'm sure I'll never be learning Ruby / Rails. I'm into Clojure right now. Next target is Go. Sadly all these Rails exploits do have a negative effect for Rails: I'm not saying this to criticize Rails. I'm saying this because I'm honestly 100% sure I'll never ever be doing anything serious with Rails and I know I'm not the only one in this case. So, Rails devs, fix this and fix this rather sooner than later because every exploit is missed opportunities.
- erydo 14y ago
  When you bring up Clojure, I think it's fair to point out that, beyond even the default-unsafe reader thing brought up a couple weeks ago, the JVM itself has had several fatal security issues recently. No platform is completely without bugs. That said, I don't really know if RoR has had more than normal or whether they're just more widely talked about. It does have a huge and vocal user-base.
- ldh 14y ago
  I don't write Ruby either right now, but I would suggest you not discount it as a nice language because of your perceptions of Rails.

125 points by sephine 14y ago

scottshea 14y ago

You know when you're already having performance issues on Heroku having a performance regression is not fun.

nifoc 14y ago
How is this > […] handing that task to Sprockets instead of resolving internally […] even remotely related to performance issues because of random routing? You're mixing two issues that have nothing in common.
- josephlord 14y ago
  1) Grandparent has performance problems on Heroku. 2) The Rails release has performance regressions (i.e. in at least some scenarios is slower). In situation (1) you don't want to add further slowdown so (2) is a bad thing. Grandparent doesn't even blame his Heroku performance problems on the routing issue (although it is a plausible guess). Actually effect of the routing problem can be significantly worsened if even a subset of requests are slowed down.
  - nifoc 14y ago
    I'm under the impression that the Sprockets regression should not affect you in production, because your assets are precompiled. Is that not the case?
    - josephlord 14y ago
      To be honest I don't know and I wouldn't have negatively responded to a comment indicating that or questioning it. However reading the article it sounds like it is an issue resolving asset paths so may affect you even when assets are precompiled. Performance Regressions There are performance regressions in 3.2.13 for both view loading and asset loading. Rails 3.2.13 changed the way assets paths are resolved, handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues.
      - fredwu 14y ago
        Actually, the performance degradation to the precompiled assets is minimal - for a typical production environment it only effects your asset compiling time as the assets are served statically from your public directory.
kawsper 14y ago
The asset path and sprocket performance hit doesn't seem to affect most Rails apps, they precompile their assets, so that shouldn't be a problem.
- calinet6 14y ago
  But it does slow down dev, which doesn't not suck.

sergiotapia 14y ago

At this point I'm seriously considering dropping Rails as my framework of choice and reverting back to ASP.Net MVC. Why? 1. Security fixes are released very quickly (good thing), but more often then not they break existing code (bad thing) - and while you _can_ wait for the next patch to fix those break points, you're left wide open since everybody can see what was broken and how to exploit it. 2. I'm not nearly smart enough with Ruby to apply 'band-aids' I read people write in Rails source code. I just don't have the time and energy to fix code in the actual framework when I need to be fixing _my_ code. ====== So there you have it; I'm bailing. It was a fantastic ride, Ruby is a beautiful language, but Rails is just a clusterfuck (_for me_). I need stability and predictable behavior. If that means releases every 6 month to 1 year, so be it. So long and thanks for all the gems.

masklinn 14y ago
You do know there are other Ruby frameworks than Rails, and other development environments than ASP and Ruby right?
- sergiotapia 14y ago
  Yes, I used to use ASP.Net MVC for pet projects, then switched to Rails - I also use CakePHP and Django for actual paying work/contracting. But thanks for the passive aggresive comment.
  - JonnieCache 14y ago
    While that may be a passive aggressive comment, sinatra is bloody brilliant all the same. You can basically pretend you're writing rails code, but with a tiny fraction of the dependencies, and actual fast response times. Sinatra, sequel and postgresql is a dream combo. I wouldn't use rails for a new project these days, I got bored of the un-navigable code a while ago. These patches and regressions are the icing on the cake.
  - masklinn 14y ago
    > Yes Because your comment didn't exactly hint at it considering its completely binary assertion of "Rails or ASP" > But thanks for the passive aggresive comment. I'm very sorry you found it passive, that was not intended.

ryanSrich 14y ago

As someone who is relatively new to Rails can someone explain to me why it seems to update more than anything else I've used?

davidw 14y ago
Mostly to give people on forums something to bitch about. Serious answer: a few months ago, some serious vulnerabilities were found in Rails. This apparently had a "blood in the water" effect on security people, who started dissecting the entire thing. Predictably, more vulnerabilities have emerged and rapidly been fixed. All in all, it means that things are improving because it's getting a ton of attention.
- philipDS 14y ago
  This. I think the rapid release cycle of Rails is a good thing, rather than a bad thing. The past few months, some serious vulnerabilities were found in Rails, and I guess this made the Rails core team a little anxious. One might argue that these performance regressions are unacceptable, and they are. I agree. Still, Rails is relatively young framework and these things happen. I expect any framework that is widely used will see some serious vulnerabilities in the next few months/years. By the way, a good explanation of what these past Rails security issues mean is explained on patio11's blog (http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/ http://www.kalzumeus.com/2013/01/31/what-the-rails-security-...). OT: I'm also writing a book on upgrading your Rails 3 app to Rails 4. With these rapid releases, a lot of things change and it's not always clear what has changed or what is new. Feel free to check it out at http://upgradetorails4.com/ http://upgradetorails4.com/.
evilduck 14y ago
Bad timing. The JVM has had an abnormal increase in security patches over the same time frame too.
bluedino 14y ago
You don't have to stay on the bleeding edge. We're stuck with Ruby 1.8.7, and we've got a mix of Rails 1, 2, and 3 apps. For better or for worse.

thinkbohemian 14y ago

Not happy? Do something about it: try release candidates, report bugs, and help triage and fix reported bugs.

calinet6 14y ago
Ok, yes, that's an extremely great and open-source way to handle this. But seriously, can we at least expect moderately stable releases? I do not think that's too much to ask, especially for a framework which has, in the past, achieved that.
foobar2k 14y ago
I completely agree with this. We (bugsnag) are running on rails 4 beta right now to help iron out any production issues before that is released. We didn't, however, realize that "patch" releases also have release candidates. I'd recommend following the rails blog (http://weblog.rubyonrails.org/ http://weblog.rubyonrails.org/) which announces release candidate builds too.
- thibaut_barrere 14y ago
  Thanks for the blog post - and I didn't realize that patch releases also had RC. It looks like this release was quite fat, for a patch release. I added "check rails diff" to my deploy todo list. EDIT: I just noticed that http://weblog.rubyonrails.org/ http://weblog.rubyonrails.org/ doesn't have a way to subscribe by email. I signed-up by email with this site instead http://blogtrottr.com http://blogtrottr.com, in case it helps other here.
- thinkbohemian 14y ago
  You can also subscribe to the rails-core mailing list, all betas, RC and full releases get announced there.
  - thibaut_barrere 14y ago
    There's quite a bit more discussions on rails-core apart from RC and releases, so subscribing to the blog is a good idea if your time is limited :-)

jrochkind1 14y ago

Okay, some of these problems are (unintended) direct side effects of the security fix bugs. Like I the one about scopes that effected Github -- github quoted [this commit](https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23 https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...) as introducing the bug, which is the commit meant to address CVE-2013-1854. So, okay, bugs happen, even with security fixes, I can forgive bugs. But others of those performance regressions... " handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues." This doesn't sound like the unanticipated side effect of a security fix. This _sounds_ like an independent change they threw into the same patch release with four (four!) security patches. Why is Rails putting security fixes and other non-security-related enhancements together in the same patch, so you can't get the security fixes without also getting the possibly buggy new features/refactors? Does Rails actually do this by policy? Was it a mistake? Bugs happen, including bugs in security fixes, sure. But it's BECAUSE bugs will happen that you don't throw unrelated new features or refactors into the same patch release as a security patch, so the only way to get the security patch is to risk MORE problems from the other stuff too! Come on!

badgar 14y ago
AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs. This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.
- obviouslygreen 14y ago
  And as is to be expected with Rails at this point, point releases break apps. As a primarily Django guy with an interest in Rails... is this hyperbole/overstatement or is this a common perception?
  - hoka 14y ago
    I'm also a Python dev, and my observation from several threads here (and elsewhere) is that the perception is quite common. IANARailsDev, obviously.

FuzzyDunlop 14y ago

I think the only mistake made with this patch release was merging in 250+ commits, ranging from last year to the present day. Maybe that's standard for such a large project, but it feels like a hell of a lot of tweaks for a minor release. As for the rest - I think the issues in January has put Rails in the spotlight, and while scrutiny is certainly warranted, I think the extra pressure on the project over the past months to clear this stuff up has had its consequences.

yxhuvud 14y ago
I think the problem is that they do too many patch releases and not enough minor releases. This could easily have been a minor.

renownedmedia 14y ago

Since when do Rails developers worry about performance?

1qaz2wsx3edc 14y ago

296 commits for a security patch is silly; What the shit tenderlove.

calinet6 14y ago
Seriously. Usually Rails feels like riding in an Uber, but this release felt like Crazy Taxi.

ChrisInEdmonton 14y ago

There's been a few people suggesting that, if you are bitten by a bug, you fix it and submit a pull request. That's a good idea. I did exactly this to a regression introduced in 3.2.9, complete with a unit test and a pull request against 3-2-stable and one against master. It took two months to get anyone to look at it, and while one of the two pull requests has a thumbs-up, it's still not been merged. Admittedly, this isn't a security issue as far as I can see, but still.

steveklabnik 14y ago
I personally read every single issue and comment filed against rails/rails. I often don't comment if it's not a part of the codebase I'm not familiar with, and it's the same with merging. Can you point me to the specific ones so I can look at them again?
- tvongaza 14y ago
  Pretty sure Chris is talking about: https://github.com/rails/rails/issues/8856 https://github.com/rails/rails/issues/8856
  - steveklabnik 14y ago
    Ah yes, ActiveRecord is one of those parts I am _not_ an expert in.
- ChrisInEdmonton 14y ago
  Yeah, tvongaza is correct. Admittedly, it's not a _big_ issue, and perhaps I'm going about things the wrong way. If you could tell me a better way of getting this issue fixed, I'd love to hear it. The only other time I tried, it took more than two years. Luckily, it was pretty easy to monkey-patch our own code to deal with this, once it broke our live site.
  - steveklabnik 14y ago
    Other than tenderlove and (sort of) myself, nobody is paid to work on Rails. This means that it's an entirely volunteer effort, and people's lives are busy, so sometimes, tickets take a while to merge. I try to stay on top of it actively and thing still sometimes slip through the cracks for me. It's not that you're going about it the wrong way, it's that projects with ~200 open pulls are slow to merge, sometimes. Sorry it's taking so long with this one. :/ I'll bump this up in my personal list; I should really learn AR better anyway.

bratsche 14y ago

I disagree with the final statement of this, that a "security only" release would have somehow helped the situation. I feel like part of the problem is that things are being merged into 3-2-stable and nobody is using them because they're never put into a release. 3.2.11 and 3.2.12 were both security-only releases, and so fixes and patches that were not security-related have just been piling up for the longest time. Seems like a "release often" mindset might be better and might ensure that things are actually being used. Sure, I know someone is going to blast me saying that bugs like this shouldn't make it into 3-2-stable at all, and since this is Hacker News so whoever says that knows they're ten times the developer that everyone on the Rails core team is. But the reality is that bugs make it into stable branches, and almost nobody is running against the stable branch (Rails core people are probably mostly running against the 4.0 branch, everyone else is running against the latest release).

mnarayan01 14y ago
Actually 3.2.12 also added some sort of silly (and broken) patch related to quoting numeric values in ActiveRecord. The primary thing I want out of 3.2.13 is reverting this. To your more general point, while I don't disagree with your diagnosis of things piling up in stable, I'm also not a big fan of your proposed solution. It looks to me like 3-2-stable is getting filled with a lot of stuff that just should not there; increasing the release frequency is not going to solve this problem.

asm_o_dan 14y ago

Rails - ruining Ruby and putting the fail train on the right tracks since 2004.

martinced 14y ago

I'm sure that Rails is great and powers many websites and that many devs loves it. I'm also sure that people are working hard to fix these recent security issues and perfs issues. But as a non-Rails dev I can tell you one thing: with all the attention that Rails got lately I'm sure I'll never be learning Ruby / Rails. I'm into Clojure right now. Next target is Go. Sadly all these Rails exploits do have a negative effect for Rails: I'm not saying this to criticize Rails. I'm saying this because I'm honestly 100% sure I'll never ever be doing anything serious with Rails and I know I'm not the only one in this case. So, Rails devs, fix this and fix this rather sooner than later because every exploit is missed opportunities.

erydo 14y ago
When you bring up Clojure, I think it's fair to point out that, beyond even the default-unsafe reader thing brought up a couple weeks ago, the JVM itself has had several fatal security issues recently. No platform is completely without bugs. That said, I don't really know if RoR has had more than normal or whether they're just more widely talked about. It does have a huge and vocal user-base.
ldh 14y ago
I don't write Ruby either right now, but I would suggest you not discount it as a nice language because of your perceptions of Rails.