5 ms·

I can't take his opinions too seriously because his 3 central gripes, which he wrote extensively about, boil down to: 1) Too much complexity is hidden by simpl

I can't take his opinions too seriously because his 3 central gripes, which he wrote extensively about, boil down to: 1) Too much complexity is hidden by simple interfaces Those simple interfaces make programming enjoyable and don't break, so... 2) Your app logic is going to be too tightly coupled to core Rails features like AR, helpers, controllers ("your app is Rails") Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem? 3) ActiveSupport. "No actual solutions, no solid abstractions, just nasty workarounds" ActiveSupport has saved me bajillions of hours and never broke anything for clients. I wasn't aware it was such a flawed library, if it is? Rails is maximized for developer happiness by, among other things, making things simple (yes, which to a large extent means hiding complexity), giving you a bunch of Omikase core features that you can in fact use, and gives you a lot of sugary methods for handling things that are tedious. I understand people wanting to try other things and leave Rails, no problem with that, but his stated reasons reveal a lot more about him than about Rails.

BinaryIdiot 10y ago
> Those simple interfaces make programming enjoyable and don't break, so... Speak for yourself. The last time I worked on a rails project this was the part I most disliked. It made debugging annoying, I never knew what each line of code was doing in totality and and I had to practically live in the documentation to figure out the side affects of everything I did. This is versus most other frameworks I've used for web services where most things are explicit enough that, even if you don't know the language well / at all, you can still figure out what most of everything does. Jumping into a rails project without knowing ruby and how rails works? Good luck figuring that out without studying the documentation.
phamilton 10y ago
> his stated reasons reveal a lot more about him than about Rails. They reveal that he has tried to build sotware that didn't fit the Rails approach. They reveal that he has been frustrated trying to build tools that allow him to stray from the standard Rails approach without abandoning Rails completely. They reveal he's tired of the lack of success on that front and is going to just move on.
- alttab 10y ago
  Something something right tool for the job. Totally agree. Rails has its place. If it's all you know, everything looks like a rails app...
  - phamilton 10y ago
    I think the prevailing problem people have with Rails is there narrow definition of a "Rails app" and a very wide space for "what my app will look like in a year".
    - sanderjd 10y ago
      Yes, this - in my experience, most web apps start out as "good Rails apps", but few remain so indefinitely. Many people over the years of Rails' popularity have experienced the transition from feeling supported by the "Rails Way" to feeling like they're fighting it, and it isn't surprising that this burns people out eventually.
clessg 10y ago
I'm sure I'm wrong, but the fact that you keep using the word "simple" makes me feel that you skimmed over the article. The author disagrees that Rails makes things "simple," and argues that it attempts to mask complexity by making things easy/convenient.
- the_gastropod 10y ago
  Yes. But I'm not sure that argument is any more valid here than it is when talking about high level programming languages vs assembly. Of course abstraction hides complexity—that's kind of the point.
  - shiro 10y ago
    Abstraction isn't for hiding complexity. A good abstraction redefines the problem to eliminate complexity.
philwelch 10y ago
> Those simple interfaces make programming enjoyable and don't break, so... If they don't break for you, then use Rails. I find that they break all the time. Hint: What does "validates: :unique" actually do?
- sanderjd 10y ago
  It depends: what does it do when? What does it do when the interpreter parses that line? What does it do when you call `save` on an object? What does it do when you call `create`? What does it do when you call `create!`? Etc. etc. Of course, you always have to know how the tools you're using actually work, but Rails does have a tendency to make it seem like you don't, and to defaults that make it perhaps too easy to create bugs caused by mistaken intuition.
- gkop 10y ago
  There an info box calling this out in the Rails Guide for Validations.
  - philwelch 10y ago
    I don't see an info box for the issue I'm thinking of. Are you thinking of the case sensitivity issue? http://guides.rubyonrails.org/active_record_validations.html#uniqueness http://guides.rubyonrails.org/active_record_validations.html... The expectation is that "validates :field, uniqueness: true" would validate that the value of the indicated field is unique among all rows in the table. However, this abstraction breaks spectacularly. Any web application, even a Rails app, is usually run over multiple processes, often on multiple different hosts. Uniqueness validation does a non-atomic check and set, which is a known race condition in this kind of environment. The guide does say: > ...it may happen that two different database connections create two records with the same value for a column that you intend to be unique. To avoid that, you must create a unique index on both columns in your database. But what actually happens when we do this? The race condition where you would otherwise get non-unique values inserted into a column of unique values is instead a race condition where a database adapter throws a generic exception for "the DB complained" with an error message about a failed constraint, and your site throws a 500. Your only recourse is to capture an overly generic class of exception that's thrown by e.g. the MySQL adapter, pattern-match the exception text for a magic string like "uniqueness constraint failed" depending upon which DB you're using, and write your own custom code to recover from that. That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting" different SQL variants to ActiveRecord doesn't go as far as turning constraint failures, lock wait timeouts, etc. into generic, application-intelligible exception classes. The entire point of ActiveRecord is that your application code should be portable between SQL variants--hell, it shouldn't even have to know what SQL variant it runs on!--but between having to write your own SQL for any use case other than "let's deal with a result set as an array of ActiveRecord objects" and this nonsense, no real-world Rails application achieves this. In other words, something that Rails pretends happens in one line of code does not actually happen at all, and to make it actually happen, you have to write a whole bunch of code that has to resort to string-matching a bucket exception class for "the DB complained" for the specific exception text that your particular DB engine throws. This is probably the worst example, but it's illustrative. Rails provides the illusion of simple interfaces and enjoyable programming. After working in Rails for just a few years, though, the illusion has vanished for me and I spend far too much time asking questions like "how the fuck did THAT get set to nil?" and "what does does it take to turn this multiline string of raw SQL into objects I can actually use?". Honestly, I don't want to come across as too harsh. The sad truth is that nothing is perfect, and if you focus on the imperfections, all software pretty much just sucks. But Rails actually tries to convince you that it doesn't suck, that it abstracts away the complexity for you, and that you don't have to worry about it yourself, leaving you ill-prepared for the reality that it's still there and you do have to worry about it.
goralph 10y ago
Those simple interfaces make programming enjoyable and don't break, so... It's enjoyable until you want to do something else rather than the default behaviour. Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem? Yes, it's terrible architecture. Your business logic should know nothing about what framework it's sitting in or which database it's connected to.
_greim_ 10y ago
Arguably the "central gripe" of the article is one level higher, in which Rails has no competition in Ruby-land, and if you don't agree the architectural preferences of a few thought leaders, your only choice is to abandon not just Rails but the entire Ruby world. At least that was my takeaway.
gamesbrainiac 10y ago
I think you've either not read the article completely, or failed to understand the central point that the author tried to illustrate. The issue is with culture. There is no problem if rails wants to go one way, and the author wants to go another. The issue at hand is that Rails is stymieing growth, not just in its own ecosystem but in the ruby ecosystem as a whole. I think this is a very good point, and in contract I can imagine that if Django had total and utter dominance in the python world, python would be in a similar position.
emodendroket 10y ago
> Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem? A lot of people would argue that you should structure your application in such a way that as little of the behavior as possible is entangled with the Web framework you choose, making it easier to understand and easier to (for example) develop a different application reusing that code. DHH thinks that's "wankery," apparently, which I have to say strikes me as an odd opinion.

BinaryIdiot 10y ago

> Those simple interfaces make programming enjoyable and don't break, so... Speak for yourself. The last time I worked on a rails project this was the part I most disliked. It made debugging annoying, I never knew what each line of code was doing in totality and and I had to practically live in the documentation to figure out the side affects of everything I did. This is versus most other frameworks I've used for web services where most things are explicit enough that, even if you don't know the language well / at all, you can still figure out what most of everything does. Jumping into a rails project without knowing ruby and how rails works? Good luck figuring that out without studying the documentation.

phamilton 10y ago

> his stated reasons reveal a lot more about him than about Rails. They reveal that he has tried to build sotware that didn't fit the Rails approach. They reveal that he has been frustrated trying to build tools that allow him to stray from the standard Rails approach without abandoning Rails completely. They reveal he's tired of the lack of success on that front and is going to just move on.

alttab 10y ago
Something something right tool for the job. Totally agree. Rails has its place. If it's all you know, everything looks like a rails app...
- phamilton 10y ago
  I think the prevailing problem people have with Rails is there narrow definition of a "Rails app" and a very wide space for "what my app will look like in a year".
  - sanderjd 10y ago
    Yes, this - in my experience, most web apps start out as "good Rails apps", but few remain so indefinitely. Many people over the years of Rails' popularity have experienced the transition from feeling supported by the "Rails Way" to feeling like they're fighting it, and it isn't surprising that this burns people out eventually.

clessg 10y ago

I'm sure I'm wrong, but the fact that you keep using the word "simple" makes me feel that you skimmed over the article. The author disagrees that Rails makes things "simple," and argues that it attempts to mask complexity by making things easy/convenient.

the_gastropod 10y ago
Yes. But I'm not sure that argument is any more valid here than it is when talking about high level programming languages vs assembly. Of course abstraction hides complexity—that's kind of the point.
- shiro 10y ago
  Abstraction isn't for hiding complexity. A good abstraction redefines the problem to eliminate complexity.

philwelch 10y ago

> Those simple interfaces make programming enjoyable and don't break, so... If they don't break for you, then use Rails. I find that they break all the time. Hint: What does "validates: :unique" actually do?

sanderjd 10y ago
It depends: what does it do when? What does it do when the interpreter parses that line? What does it do when you call `save` on an object? What does it do when you call `create`? What does it do when you call `create!`? Etc. etc. Of course, you always have to know how the tools you're using actually work, but Rails does have a tendency to make it seem like you don't, and to defaults that make it perhaps too easy to create bugs caused by mistaken intuition.
gkop 10y ago
There an info box calling this out in the Rails Guide for Validations.
- philwelch 10y ago
  I don't see an info box for the issue I'm thinking of. Are you thinking of the case sensitivity issue? http://guides.rubyonrails.org/active_record_validations.html#uniqueness http://guides.rubyonrails.org/active_record_validations.html... The expectation is that "validates :field, uniqueness: true" would validate that the value of the indicated field is unique among all rows in the table. However, this abstraction breaks spectacularly. Any web application, even a Rails app, is usually run over multiple processes, often on multiple different hosts. Uniqueness validation does a non-atomic check and set, which is a known race condition in this kind of environment. The guide does say: > ...it may happen that two different database connections create two records with the same value for a column that you intend to be unique. To avoid that, you must create a unique index on both columns in your database. But what actually happens when we do this? The race condition where you would otherwise get non-unique values inserted into a column of unique values is instead a race condition where a database adapter throws a generic exception for "the DB complained" with an error message about a failed constraint, and your site throws a 500. Your only recourse is to capture an overly generic class of exception that's thrown by e.g. the MySQL adapter, pattern-match the exception text for a magic string like "uniqueness constraint failed" depending upon which DB you're using, and write your own custom code to recover from that. That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting" different SQL variants to ActiveRecord doesn't go as far as turning constraint failures, lock wait timeouts, etc. into generic, application-intelligible exception classes. The entire point of ActiveRecord is that your application code should be portable between SQL variants--hell, it shouldn't even have to know what SQL variant it runs on!--but between having to write your own SQL for any use case other than "let's deal with a result set as an array of ActiveRecord objects" and this nonsense, no real-world Rails application achieves this. In other words, something that Rails pretends happens in one line of code does not actually happen at all, and to make it actually happen, you have to write a whole bunch of code that has to resort to string-matching a bucket exception class for "the DB complained" for the specific exception text that your particular DB engine throws. This is probably the worst example, but it's illustrative. Rails provides the illusion of simple interfaces and enjoyable programming. After working in Rails for just a few years, though, the illusion has vanished for me and I spend far too much time asking questions like "how the fuck did THAT get set to nil?" and "what does does it take to turn this multiline string of raw SQL into objects I can actually use?". Honestly, I don't want to come across as too harsh. The sad truth is that nothing is perfect, and if you focus on the imperfections, all software pretty much just sucks. But Rails actually tries to convince you that it doesn't suck, that it abstracts away the complexity for you, and that you don't have to worry about it yourself, leaving you ill-prepared for the reality that it's still there and you do have to worry about it.

goralph 10y ago

Those simple interfaces make programming enjoyable and don't break, so... It's enjoyable until you want to do something else rather than the default behaviour. Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem? Yes, it's terrible architecture. Your business logic should know nothing about what framework it's sitting in or which database it's connected to.

_greim_ 10y ago

Arguably the "central gripe" of the article is one level higher, in which Rails has no competition in Ruby-land, and if you don't agree the architectural preferences of a few thought leaders, your only choice is to abandon not just Rails but the entire Ruby world. At least that was my takeaway.

gamesbrainiac 10y ago

I think you've either not read the article completely, or failed to understand the central point that the author tried to illustrate. The issue is with culture. There is no problem if rails wants to go one way, and the author wants to go another. The issue at hand is that Rails is stymieing growth, not just in its own ecosystem but in the ruby ecosystem as a whole. I think this is a very good point, and in contract I can imagine that if Django had total and utter dominance in the python world, python would be in a similar position.

emodendroket 10y ago

> Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem? A lot of people would argue that you should structure your application in such a way that as little of the behavior as possible is entangled with the Web framework you choose, making it easier to understand and easier to (for example) develop a different application reusing that code. DHH thinks that's "wankery," apparently, which I have to say strikes me as an odd opinion.