From: Richard Conroy Date: 2006-09-14T04:47:58+09:00 Subject: Re: Joel Spolsky on languages for web programmingr On 9/13/06, James Edward Gray II wrote: > You are changing your story below. I will try to address your > points, but you originally said Ruby 2.0 is in the early discussion > phase. I showed you a running interpreter. To me, those are opposites. Well no I am not changing my story, but I do switch between personal opinion and PHB-style devils advocacy too much for my own good. I concede that the 'early discussion' comment was flippant and didn't convey what I really meant: that Ruby 2.0 'community/user' discussion was at an early stage. I have seen the proposals and what is intended. To properly restate my opinion: I worry about Rails performance, for much the same reasons that Joel identified in his original article, and followed up with on his second. The Rails stack is fine as long as you don't do anything CPU intensive (i.e. use much Ruby code in your controllers). The very example that Joel cited (HTML graphing) is precisely the issue I noticed in the first piece of Rails code I ever wrote that was worth showing off. I haven't found found any satisfactory answers for 'how much is too much' Ruby code in your Rails app, but I would like to know before I commit to a project that might need it. It contributes to the perception of 'Rails performance' that Joel mentioned. The fact that community driven solutions to pure-Ruby performance are years away means that this is an issue you are going to have to live with for some time, and you are going to have to steer away from doing anything CPU related for the foreseeable future. > > Ruby 2.0 has been in development for for years, literally. We now > have a functional VM. My opinion is that it is in late development. Not something I dispute - I have read some of Matz' posts on it - Ruby 2.0 is a significant change, and I have read his migration plans (break stuff early and get it over with in 1.9 to make pure 2.0 migration smoother). I am going to snip your technical details, I did know the answers, but I was speaking in PHB-mode. > In your earlier post, you criticized Ruby because other languages are > evolving to get faster and Ruby is not. That upset me because you > casually diminished the hard work of everyone who has gone to great > lengths to make Ruby faster for years now. I was frustrated myself and it came across. It was not my intention to dismiss the careful efforts of the Ruby-dev team. I am aware that Ruby has a huge installed base, particularly in its country of origin and that this is what slows down development. Keeping compatibility and providing easy migration paths closes down convenient options for rapid gains. Commercial language vendors take note. But my frustration comes from the fact that 'Rails performance' due to ruby performance continues to be unanswered. As far as I am concerned Joel nailed key concerns with using Rails as a primetime framework. I was expecting this concern to be addressed by now, and the only place I can really expect it to be answered is here. If I google or usenet-dive I just get the usual FUD or zealotry. I just would like to know what experienced Railsers think about the suitability of Rails for CPU intensive page serves (i.e. non-pure Rails Stack, Lots of Ruby in controllers). Basically Rails outside the sweetspot (and while we are at it, how big is the sweet spot). And with one main caveat: you have limited or possibly zero control of the server(s) - no possibility to convert slow code to C - no possibility of using OS features The only code you can ship is ruby/rails code that you write, a platform specific Ruby installer and whatever gems that have no binary component. Maybe you are hosted and can't even dictate your Ruby version. I want to know if CPU intensive Ruby code in Rails controllers Is Considered Harmful or Risky, or is otherwise a real concern. I think it is and I would like to hear practical stories on it. I would like to know how an experienced Rails developer implemented non-trivial HTML charting or bayesian filtering withpout resorting to OS executables or C. And also how the optimisation process hit their developer cycles and what approaches worked for them (and what dead ends they encountered). If I am walking on quicksand I would like to know. I could go with Rails and be aware of what to avoid.