I agree with DHH’s statement that programmer happiness is all that matters. However, I haven’t met a Rails programmer that was happy writing Rails in, probably years. Everyone writing Rails constantly complains about how nothing works like expected, all apps become unmainable nightmares etc etc.
If programmer happiness matters to the Rails team, what’s being done to increase it?
I’ve said it before, but I wish the Rails team would invest more resources into maintaining an LTS branch. It’s easier to create happiness when a developer can just learn the tool once and get back to work without having to constantly learn the new version, spend time migrating code to it, fix broken tests, deal with incompatible plugins, etc. Unfortunately I think a lot of newer developers equate a stable project with a dead one, and they constantly want new shiny things.
I’m a happy Rails developer because most of the projects I work on are stuck on old versions like 2.3 and 4. I never have to think about upgrading Rails unless it’s for the occasional security update, so I can just focus on writing my application. If I thought about what it would take to pull all of these things up to whatever the current version is, it would make me unhappy.
Things like PHP succeeded because the language/interpreter moved very slowly (although this was bad for security, because certain things needed to change quicker) so developers could write code that still worked years down the road. This is kind of why I am apprehensive about learning Swift for iOS projects once it was open sourced - I think there are too many cooks in the kitchen trying to form the language around what they want, and it’s going to be a moving target for a long time.
IMO, it all depends on scale. Once the experiential barrier is overcome, Ruby provides short-term programmer happiness with its object-oriented/procedural orientation and eclectic grammar (deriving from Perl and Smalltalk), while Haskell provides long-term programmer happiness with its extremely versatile type system and pure functional-ness. Each has a clean syntax, but the underlying paradigms make for radically different programmer experiences. Ruby is great for churning out code that’s fun and natural to write without jumping through functional hoops, while for more sophisticated tasks it may perl in comparison with Haskell’s strong maintainability and reasonableness. That’s just one example, but you might see how what makes me happy may not make you happy, and vice versa.
Nevertheless, I wouldn’t call this a failure of Rails to make programmers happy per se; maintainability is a whole other problem that operates on an entirely different scale.
A big part of this is because frameworks try to cram all of programming into a tiny color-by-number box and call it good. Eventually what you’re doing doesn’t fit so well, but you’re already stuck there, so you just hack atop it.
Rails has enabled lots of projects to get bigger than they would have without it, but it doesn’t fix the fact that you need to know architecture eventually.
I’ve worked professionally for the past 5+ years on 7 or 8 projects that used Rails in various capacities. For me personally, Rails is awesome when you aren’t stuck using all of it. If you’re using the routing/controllers, sticking your business logic in a service layer and leaving everything else out, it’s a joy. While there is some small level of efficiency you gain from all the automagical stuff, my opinion these days is that the opacity hurts more than it helps.
Not to mention the… trendiness? Fad-culture? I’m not sure what the right way to label it is, but if you’re stuck trying to decide whether it’s fashionable this year to use helpers vs decorators (or was it presenters?), and wondering whether _changed? methods are deprecated this month, Rails can be quite a nuisance. Did “rake db:test:prepare” get undeprecated? Oh, lovely, I suppose we can use that again. Need to build an administrative backend for your own people? I guess it’s cool now to use ActiveAdmin, a deus ex machina gem that somehow attempts to what, simplify writing CRUD apps? I thought that’s what Rails was for.
</rant>
On a somewhat more serious note, I have worked on a very large Rails project where the performance of the application was perhaps the single biggest problem we had - largely ActiveRecord generating complex and inefficient queries which ended up being tediously re-written by hand. This wasn’t a Twitter-scale application, either. The Ruby language wasn’t at fault, but pieces of Rails certainly were.
While it may or may not be impossible to remedy the programmer happiness problem within Ruby/Rails, I think we’re missing something if we only look within that community. Jose Valim created a language and community that is making people really happy. Elixir was heavily influenced by Ruby, and (at the moment) it nails the programmer happiness point - so to say “Ruby/Rails makes people sad” is a little bleaker than reality, it certainly fostered some good ideas that made their way into other microcosms. I’m sure there are other examples, but the point is that all software ends up becoming unwieldy and unpleasant, but the nice aspects generally make their way into other projects.
We’ve still never had a complete rewrite but have been really good about keeping tabs on tech debt and making sure we’re running as close to edge as possible.
This blog is mostly a non-statement. It is only noteworthy as a response to myriad “Ruby isn’t fast enough” non-statements.
Most discussions of performance should focus on set of uses, and leaving them unstated leaves people to mentally assume the anything ever use case set or, perhaps more likely, the use cases they are most familiar with. So an unstated-cum-blanket “Ruby is fast enough” by people working on text-shuffling web applications is met with “Ruby is anything but fast enough” by the company struggling to afford the compute costs for their OpenCV processing in Python, and are gazing longingly at some performance metrics for Cython and C++. For the first group, the smidgen of dinero saved might not move the needle, for the latter, it means survival.
But claims of “Ruby is fast enough” that are bounded in an actual discussion of “Fast enough for what?” aren’t noteworthy enough to share on social news sites.
The only bold statement in this blog post is:
It’s a luxury that the 99% can afford, but the 1% might struggle with.
Many readers won’t get there before having already made up their minds (or already closed the article to upvote/downvote/comment).
I like Ruby and use it every day, but for the referenced group of “most people doing most things”, or even an implicit “most [web] people doing most [web] things”, I would be hesitant to peg it anywhere higher than an 80/20 split. Especially when you consider the push to have web technologies present in verticals like Healthcare.
“Fast enough” is a strange term. I generally agree that there’s a huge amount of FUD around languages that doesn’t apply to most cases.
The problems are that (a) business people know what they want, but none of the tactics, nor are they willing to give the engineers real equity (life-changing equity, not 0.02%) and prestige that would align them with the business, while (b) programmers, as a group, don’t have a clear articulation of what they want.
For example, Ruby and Python are probably in a state where most web businesses could run entirely on them and be fine. This has been true for at least a decade. (Obviously, the rules are different if you’re doing embedded systems, where C and assembly languages are still necessary.) Even though I prefer static typing, the quality of engineers (and management) is far more important than the traits of the language are. If you hire a team of open-plan Scrum drones, no language can save you.
If I were building a production infrastructure that I knew would last 10+ years and that was intended to be a multi-developer project from the start, I’d strongly consider Haskell. That said, I think we as programmers tend to be attracted to premature scaling. Our attraction to hard technical challenges blinds us to occurrences when we should take the easy path and write a 100-line Python script instead. That said, this is also the fault of the business: since our work and careers are evaluated on the difficulty of the challenges we overcome, and since business people aren’t willing to give the real equity and status that would make programmers actually care about the business proper, this is exactly what one would expect.
I think this is confusing the binary “success vs failure” with the nuanced “more successful vs less successful”. Outright, binary, failure is pretty uncommon. Most people find a way to turn anything into some form of success. The difficult question is what could Basecamp have done if it could do more with less? Ruby may be fast enough, but is that an advantage?
I agree with DHH’s statement that programmer happiness is all that matters. However, I haven’t met a Rails programmer that was happy writing Rails in, probably years. Everyone writing Rails constantly complains about how nothing works like expected, all apps become unmainable nightmares etc etc.
If programmer happiness matters to the Rails team, what’s being done to increase it?
I’ve said it before, but I wish the Rails team would invest more resources into maintaining an LTS branch. It’s easier to create happiness when a developer can just learn the tool once and get back to work without having to constantly learn the new version, spend time migrating code to it, fix broken tests, deal with incompatible plugins, etc. Unfortunately I think a lot of newer developers equate a stable project with a dead one, and they constantly want new shiny things.
I’m a happy Rails developer because most of the projects I work on are stuck on old versions like 2.3 and 4. I never have to think about upgrading Rails unless it’s for the occasional security update, so I can just focus on writing my application. If I thought about what it would take to pull all of these things up to whatever the current version is, it would make me unhappy.
Things like PHP succeeded because the language/interpreter moved very slowly (although this was bad for security, because certain things needed to change quicker) so developers could write code that still worked years down the road. This is kind of why I am apprehensive about learning Swift for iOS projects once it was open sourced - I think there are too many cooks in the kitchen trying to form the language around what they want, and it’s going to be a moving target for a long time.
IMO, it all depends on scale. Once the experiential barrier is overcome, Ruby provides short-term programmer happiness with its object-oriented/procedural orientation and eclectic grammar (deriving from Perl and Smalltalk), while Haskell provides long-term programmer happiness with its extremely versatile type system and pure functional-ness. Each has a clean syntax, but the underlying paradigms make for radically different programmer experiences. Ruby is great for churning out code that’s fun and natural to write without jumping through functional hoops, while for more sophisticated tasks it may perl in comparison with Haskell’s strong maintainability and reasonableness. That’s just one example, but you might see how what makes me happy may not make you happy, and vice versa.
Nevertheless, I wouldn’t call this a failure of Rails to make programmers happy per se; maintainability is a whole other problem that operates on an entirely different scale.
A big part of this is because frameworks try to cram all of programming into a tiny color-by-number box and call it good. Eventually what you’re doing doesn’t fit so well, but you’re already stuck there, so you just hack atop it.
Rails has enabled lots of projects to get bigger than they would have without it, but it doesn’t fix the fact that you need to know architecture eventually.
I’ve worked professionally for the past 5+ years on 7 or 8 projects that used Rails in various capacities. For me personally, Rails is awesome when you aren’t stuck using all of it. If you’re using the routing/controllers, sticking your business logic in a service layer and leaving everything else out, it’s a joy. While there is some small level of efficiency you gain from all the automagical stuff, my opinion these days is that the opacity hurts more than it helps.
Not to mention the… trendiness? Fad-culture? I’m not sure what the right way to label it is, but if you’re stuck trying to decide whether it’s fashionable this year to use helpers vs decorators (or was it presenters?), and wondering whether _changed? methods are deprecated this month, Rails can be quite a nuisance. Did “rake db:test:prepare” get undeprecated? Oh, lovely, I suppose we can use that again. Need to build an administrative backend for your own people? I guess it’s cool now to use ActiveAdmin, a deus ex machina gem that somehow attempts to what, simplify writing CRUD apps? I thought that’s what Rails was for.
</rant>
On a somewhat more serious note, I have worked on a very large Rails project where the performance of the application was perhaps the single biggest problem we had - largely ActiveRecord generating complex and inefficient queries which ended up being tediously re-written by hand. This wasn’t a Twitter-scale application, either. The Ruby language wasn’t at fault, but pieces of Rails certainly were.
While it may or may not be impossible to remedy the programmer happiness problem within Ruby/Rails, I think we’re missing something if we only look within that community. Jose Valim created a language and community that is making people really happy. Elixir was heavily influenced by Ruby, and (at the moment) it nails the programmer happiness point - so to say “Ruby/Rails makes people sad” is a little bleaker than reality, it certainly fostered some good ideas that made their way into other microcosms. I’m sure there are other examples, but the point is that all software ends up becoming unwieldy and unpleasant, but the nice aspects generally make their way into other projects.
Rails dev here at Shopify. Still loving it!
We’ve still never had a complete rewrite but have been really good about keeping tabs on tech debt and making sure we’re running as close to edge as possible.
This blog is mostly a non-statement. It is only noteworthy as a response to myriad “Ruby isn’t fast enough” non-statements.
Most discussions of performance should focus on set of uses, and leaving them unstated leaves people to mentally assume the anything ever use case set or, perhaps more likely, the use cases they are most familiar with. So an unstated-cum-blanket “Ruby is fast enough” by people working on text-shuffling web applications is met with “Ruby is anything but fast enough” by the company struggling to afford the compute costs for their OpenCV processing in Python, and are gazing longingly at some performance metrics for Cython and C++. For the first group, the smidgen of dinero saved might not move the needle, for the latter, it means survival.
But claims of “Ruby is fast enough” that are bounded in an actual discussion of “Fast enough for what?” aren’t noteworthy enough to share on social news sites.
The only bold statement in this blog post is:
Many readers won’t get there before having already made up their minds (or already closed the article to upvote/downvote/comment).
I like Ruby and use it every day, but for the referenced group of “most people doing most things”, or even an implicit “most [web] people doing most [web] things”, I would be hesitant to peg it anywhere higher than an 80/20 split. Especially when you consider the push to have web technologies present in verticals like Healthcare.
“Fast enough” is a strange term. I generally agree that there’s a huge amount of FUD around languages that doesn’t apply to most cases.
The problems are that (a) business people know what they want, but none of the tactics, nor are they willing to give the engineers real equity (life-changing equity, not 0.02%) and prestige that would align them with the business, while (b) programmers, as a group, don’t have a clear articulation of what they want.
For example, Ruby and Python are probably in a state where most web businesses could run entirely on them and be fine. This has been true for at least a decade. (Obviously, the rules are different if you’re doing embedded systems, where C and assembly languages are still necessary.) Even though I prefer static typing, the quality of engineers (and management) is far more important than the traits of the language are. If you hire a team of open-plan Scrum drones, no language can save you.
If I were building a production infrastructure that I knew would last 10+ years and that was intended to be a multi-developer project from the start, I’d strongly consider Haskell. That said, I think we as programmers tend to be attracted to premature scaling. Our attraction to hard technical challenges blinds us to occurrences when we should take the easy path and write a 100-line Python script instead. That said, this is also the fault of the business: since our work and careers are evaluated on the difficulty of the challenges we overcome, and since business people aren’t willing to give the real equity and status that would make programmers actually care about the business proper, this is exactly what one would expect.
I think this is confusing the binary “success vs failure” with the nuanced “more successful vs less successful”. Outright, binary, failure is pretty uncommon. Most people find a way to turn anything into some form of success. The difficult question is what could Basecamp have done if it could do more with less? Ruby may be fast enough, but is that an advantage?
As with so many other things, it depends.