4 ms·

I’m forced to learn rails at a new job — and I really dislike it. There’s so much magic and things are built in an obscure/extremely inefficient way to work ar

I’m forced to learn rails at a new job — and I really dislike it. There’s so much magic and things are built in an obscure/extremely inefficient way to work around/“take advantage” of frameworks limitations/features. There is so much code that is not part of the codebase driving the behavior of the system — and that third party code is very tightly coupled to the actual behavior that will be observed by running the code. Figuring how anything actually works is made massively harder than required and developers are encouraged towards designs that will require ridiculously inefficient database interactions. Rails is terrible I think for experienced developers because there are no mechanisms in the codebase — instead there are layers and layers of “conventions” which often only exist to try to avoid bugs that would’ve been much better to catch or prevent with a combination of a type system, high level tests, and less mutation.

etaioinshrdlu 7y ago
This is a decent criticism of Rails, but there are things you can do to make it smoother: try to avoid doing unusual things. A big point of using a framework is to leverage an ecosystem other people's libraries (and stackoverflow questions!), and they will typically only work well if your code is relatively "normal". If your code looks like "beginner" code in the framework, you're doing it right. As a point of comparison, I switched to Django for a few years after a few years of Rails. Django was a lot less magical and was more debuggable. But Rails' magic actually encourages a better project structure. Django doesn't care about your structure. I also found the thoroughness and completeness of the ecosystem surrounding Rails to be stronger. That is the real selling point to me. For most things you want to do in Rails, you will find a library that integrates with the project and DB structure you already have.
- srazzaque 7y ago
  Disclaimer: I haven't used Rails since around 3, but my assumption is the DX hasn't changed too much. Plus if Rails N was marketed at Rails "N-1" devs, then new devs coming in late have a lot of learning to do. > avoid doing unusual things If by "unusual" you mean "not the Rails way", then this makes sense. But the problem is, the Rails way doesn't always line up with the way an experienced programmer might want to do something. In the specific example of fetching data from a DB - an experienced programmer might intuitively avoid multiple round-trips to the DB, and want to find the appropriate hook point(s) in a request handler to optimise this. Making 20 requests for 20 models is "unusual". Rails doesn't make things like this easy. It's quite opinionated on how you should work. The core assumption in play here is that databases will either be fast, or can be made faster, essentially externalising the problem. Or if you want to address this - find a Gem to do it, or dive into the layered guts of it to figure it out. Related - if I recall correctly, foreign keys were not deemed an important enough feature for inclusion in Active Record, and the Rails way is to embed the logic for joins into your models rather than the database. I'm sure many of us here could name several scenarios where this is just plain wrong.
  - e12e 7y ago
    Activerecord is indeed a major trade-off with rails. For heterogeneous projects, it can be frustrating that rails tends to favour validations, constraints and foreign key relationships in the ruby model files. Eg. You have a dot.net service that needs to write some data to the database, and doing it via REST endpoints on your rails app is really slow compared to accessing the database directly. But now you don't have any constraints on your relationships, and it's easy to shoot yourself in the foot. Extra sad, since you do have some constraints (belongs_to etc) - they're just not communicated to your database. I have some legacy rails projects I maintain, and my job would've been easier if previous developers followed the rails way more closely - and whenever I manage to refractor my way back, code becomes shorter, clearer, more efficient and less error prone. Things like only half of a relationship being defined, and joins being hand-rolled in one direction is a "favorite"...

etaioinshrdlu 7y ago

This is a decent criticism of Rails, but there are things you can do to make it smoother: try to avoid doing unusual things. A big point of using a framework is to leverage an ecosystem other people's libraries (and stackoverflow questions!), and they will typically only work well if your code is relatively "normal". If your code looks like "beginner" code in the framework, you're doing it right. As a point of comparison, I switched to Django for a few years after a few years of Rails. Django was a lot less magical and was more debuggable. But Rails' magic actually encourages a better project structure. Django doesn't care about your structure. I also found the thoroughness and completeness of the ecosystem surrounding Rails to be stronger. That is the real selling point to me. For most things you want to do in Rails, you will find a library that integrates with the project and DB structure you already have.

srazzaque 7y ago
Disclaimer: I haven't used Rails since around 3, but my assumption is the DX hasn't changed too much. Plus if Rails N was marketed at Rails "N-1" devs, then new devs coming in late have a lot of learning to do. > avoid doing unusual things If by "unusual" you mean "not the Rails way", then this makes sense. But the problem is, the Rails way doesn't always line up with the way an experienced programmer might want to do something. In the specific example of fetching data from a DB - an experienced programmer might intuitively avoid multiple round-trips to the DB, and want to find the appropriate hook point(s) in a request handler to optimise this. Making 20 requests for 20 models is "unusual". Rails doesn't make things like this easy. It's quite opinionated on how you should work. The core assumption in play here is that databases will either be fast, or can be made faster, essentially externalising the problem. Or if you want to address this - find a Gem to do it, or dive into the layered guts of it to figure it out. Related - if I recall correctly, foreign keys were not deemed an important enough feature for inclusion in Active Record, and the Rails way is to embed the logic for joins into your models rather than the database. I'm sure many of us here could name several scenarios where this is just plain wrong.
- e12e 7y ago
  Activerecord is indeed a major trade-off with rails. For heterogeneous projects, it can be frustrating that rails tends to favour validations, constraints and foreign key relationships in the ruby model files. Eg. You have a dot.net service that needs to write some data to the database, and doing it via REST endpoints on your rails app is really slow compared to accessing the database directly. But now you don't have any constraints on your relationships, and it's easy to shoot yourself in the foot. Extra sad, since you do have some constraints (belongs_to etc) - they're just not communicated to your database. I have some legacy rails projects I maintain, and my job would've been easier if previous developers followed the rails way more closely - and whenever I manage to refractor my way back, code becomes shorter, clearer, more efficient and less error prone. Things like only half of a relationship being defined, and joins being hand-rolled in one direction is a "favorite"...