Live data from Hacker News

Rails 3.2.13 - Performance regressions and major bugs

blog.bugsnag.com

21–30 of 76 posts

Re: Rails 3.2.13 - Performance regressions and major bugs

#21
post #4

Earlier quoted context omitted.

You do know there are other Ruby frameworks than Rails, and other development environments than ASP and Ruby right?

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.

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.

Re: Rails 3.2.13 - Performance regressions and major bugs

#22

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 smar…

I've been running Java and Rails since 2006 in my company (large), we use C# for a small number of desktop applications. This will come out harsh, but I'm being honest: If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), or any framework at all. In fact, developing larger more complex software might not even be possible…

>If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), of any framework at all. In fact, developing larger more complex software might not even be possible without adapting frameworks for your specific problems.

Huh what? Stack Overflow with it's extreme load works quite well with ASP.NET.

>try a google search on asp.net issues

Okay, I did, what I am supposed to be looking at?

Re: Rails 3.2.13 - Performance regressions and major bugs

#23

Earlier quoted context omitted.

I've been running Java and Rails since 2006 in my company (large), we use C# for a small number of desktop applications. This will come out harsh, but I'm being honest: If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), or any framework at all. In fact, developing larger more complex software might not even be possible…

>If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), of any framework at all. In fact, developing larger more complex software might not even be possible without adapting frameworks for your specific problems. Huh what? Stack Overflow with it's extreme load works quite well with ASP.NET. >try a google search on asp.net…

The point is, SO almost certainly aren't using vanilla ASP.net. Nobody can succeed for too long without maintaining and cultivating their stack.

Re: Rails 3.2.13 - Performance regressions and major bugs

#24
post #11

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?

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.

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-...).

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/.

Re: Rails 3.2.13 - Performance regressions and major bugs

#25

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 smar…

Wow, you're either one of those incredibly rare ruby devs who actually run windows, or you're going to switch your entire environment in order to switch frameworks. Something doesn't smell right

Re: Rails 3.2.13 - Performance regressions and major bugs

#26

Earlier quoted context omitted.

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/ ) which announces release candidate builds too.

You can also subscribe to the rails-core mailing list, all betas, RC and full releases get announced there.

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 :-)

Re: Rails 3.2.13 - Performance regressions and major bugs

#27
post #25

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 smar…

Wow, you're either one of those incredibly rare ruby devs who actually run windows, or you're going to switch your entire environment in order to switch frameworks. Something doesn't smell right

I'm a polyglot. I don't encase myself in any 1-thing. I use Mac at work, Windows at home for media and games, and Linux Mint 13 on my laptop for Ruby/Rails. I only used Linux because of Rails, but since I'm switching back (I have Visual Studio 2012 downloading as I type this), I'll have no need for Linux on my end-user machines anymore.

Re: Rails 3.2.13 - Performance regressions and major bugs

#28

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

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.

Re: Rails 3.2.13 - Performance regressions and major bugs

#29

Earlier quoted context omitted.

>If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), of any framework at all. In fact, developing larger more complex software might not even be possible without adapting frameworks for your specific problems. Huh what? Stack Overflow with it's extreme load works quite well with ASP.NET. >try a google search on asp.net…

The point is, SO almost certainly aren't using vanilla ASP.net. Nobody can succeed for too long without maintaining and cultivating their stack.

I don't know about Vanilla ASP.NET but they are pretty much using stock config'd IIS and Servers. So I would be very surprised if they weren't using stock ASP.NET (with their own filters, etc using public APIs I'm sure)
Post reply on HN