Hacker News Reader

Comment by moe | Hacker News Reader

culture of not giving a shit about performance

Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations.

My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plenty more - reviewing rails gems for performance is generally an exercise in frustration.

It's a pity. Moore's Law mostly mitigates the low performance of MRI and we could be fine that way. But it can not mitigate a culture of incompetent design.

View on HN

Well, this comment just comes across as sour grapes to me. You could be criticising any memory managed programming language. Old timers have been complaining about the kids not knowing about assembly, registers, punch cards, valves, etc since computers were invented.

As for "incompetent design" - I don't know what you are on about. I think that Rails 3 is a frigging triumph of elegant, modular design. There are very many gems in the ruby ecosystem that I believe any unbiased person would say demonstrate exemplary design. In fact, I would say that the average rubyist is much more concerned with good design than, say, your average java dev. The whole reason I switched to ruby was because of the beauty of the language. And what is beauty but good design applied?

Of course there are always exceptions but on the whole I think this comment is quite unfair.

You could be criticising any memory managed programming language.

No, I'm explicitly criticizing Ruby. I've spent years in Python-land and the average code quality (and btw documentation standard) is much higher over there. Which is not to say Python doesn't have its own problems, but less so in this particular area.

say that the average rubyist is much more concerned with good design than, say, your average java dev.

Good design is a relative term. In ruby I frequently see it interpreted as: Pack as many layers of magic as possible, and then test that with as many layers of testing-frameworks as possible.

That's not too different from the common architecture-astronouting in java. One could argue it's just a different flavor. In either ecosystem the implementation of the actual business concerns ("What does this code actually do?") too often feels like an afterthought.

Disclaimer: I'm not condemning either language. I like Ruby and use it a lot, but this is one aspect that I can't ignore.

> Good design is a relative term. In ruby I frequently see it interpreted as: Pack as many layers of magic as possible, and then test that with as many layers of testing-frameworks as possible.

I have the same feeling sometimes. I wish the Ruby community would not be so concerned with magic and aesthetics, and target clarity.

From experience and observation, I'd say that in most developer communities (include Rubyists) aesthetics and clarity are one and the same..

I'm referring really to functional clarity. Fancy ruby DSLs that invoke method_missing and parse function names make for aesthetically pleasing end user code, but obfuscate the functionality for anyone unfamiliar with the code base.

Aesthetics and clarity are most certainly different in other ways (think pretty sites vs simple clear sites) but that's another discussion.

I've never ever gotten why people get so mad that the database gets hit on every request. It's going to get hit anyway on every request for something else. I've seen how easy it is to break into systems that don't re-auth the user on each request. I guess I just feel like people spend an inordinate amount of time worrying about database performance. A single select from a single table shouldn't be a performance bottleneck. It seems to me that a good database will have that query cached in memory. It may sound "icky" but if you look at the times, I bet your Rails app spends way more time in the renderer than it does for the "select users.* from user" that it uses to populat current_user.

I'm happy to be proven wrong, but I've written a lot of apps before I moved to Rails, and we used to avoid re-authing the user / looking it up on each request, and it's just never made a bit of difference to us.

Query execution time is only part of the equation. But even that gets ugly fast when you have locking going on. E.g., try adding an index to a non-trivially sized table in MySQL and see how fast that (unnecessary) SELECT performs.

We're a postgres shop and the problem we've run into lately is just the sheer number of open connections to the DB. Using something like PgBouncer helps tremendously, but it still is contingent on there being idle connections. Certainly read slaves could be thrown at the problem, too. But it's mounting complexity for something that isn't all that necessary shrug

> On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations.

Isn't the entire goal of computer science to abstract away complexity?

The goal of abstraction is not to prevent you from knowing what's going on underneath the covers. It's generally to allow you to work on the whole with higher level constructs.

It makes a great deal of sense to understand the complexity you're abstracting away, first. Otherwise, you never really know what you're doing. At the end of the day, you're executing on a computer and you're doing yourself a serious disservice if you're ignoring that fact and hoping either Moore's Law or horizontal scaling are the answer.

You can drive a car without knowing how an engine works. But you can't design a [good] car without that knowledge.

I'm not convinced analogies such as this are particularly useful.

I'm pretty sure you could design a perfectly good car by treating an engine as a black box with a clearly defined set of inputs an outputs without caring how those inputs are translated in the outputs. Which is the goal of a framework such as rails.

But I doubt that you could maintain it without knowing how it worked. The moment anything went wrong, you would be in trouble.

I'm sure you could build a car that looked pretty, but not one that ran well.

Out of curiosity, to which "popular rails auth framework" are you referring? Devise? Authlogic?

Clearance probably. It's really not a big deal with the index in place and it gives you more flexibility for revoking access to specific users without blowing out everyone's cookie. In practice, it's not a big deal performance wise. In a system where it would matter, you'd probably be past the point of an off-the-shelf gem being a good solve.

Reply on news.ycombinator.com