4 ms·

I honestly cannot believe that this is a solid metric. I believe the question, or their answers are poorly parsed. I presume a lot of the dread is really about

by berkes 6y ago

I honestly cannot believe that this is a solid metric. I believe the question, or their answers are poorly parsed. I presume a lot of the dread is really about Rails. And the rest partly hearsay of the slow performance of Ruby. Rails is, to me, a blessing, but also a terrible framework. It helps to rapidly ship products. Just cobble some gems together in a controller or two, mix a gem or three into your models and you have a demo. A rapid Proof of Concept. But also a product that is practically unmaintainable. I've been doing Rails from its very beginning, solving this (trying to) has been my primary job for over seven years now. And performance? Yes Ruby is slow. But the speed of the language is unmeasurable in, I daresay, the vast majority of the projects of people who tell you it is too slow. That legacy mysql setup, this poorly evolved domain model, or that badly integrated external API is almost always the thing making it slow. The ms of Ruby handling that JSON to CSV conversion then is practically unmeasurable. Rust is not going to speed up those 3000ms spend in that ugly SQL query. Go's multithreading is not going to solve the slow API which you call thrice per minute. And Java is not magically making the tangle of classes, jobs, callbacks, listeners and whatnot dissapear.

joelbluminator 6y ago
Rails is alright. It's just a great scapegoat for bad teams working under impossible deadlines: "Our code is unmaintainable because Rails! We need 1 year to rewrite it in Go/Elixir/Java". I mean, because Rails has a flat structure you couldn't ever take the time to reactor that piece of crap code you wrote for 2 years? really? You didn't notice a model stopped making sense or growing in complexity? I see the same criticism with PHP. It's perfectly fine, stop blaming the tool.
- berkes 6y ago
  Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns. On contrary: often it encourages bad practices through "defacto" standard gems, or by making "the wrong choice" easier than "the proper design pattern". A "concern" is a simple way to turn a 800-lines controller into four 300 lines modules that amount to the same ball-of-mud, for example. (Concerns have great use-cases, but most often it is not the solution to your problem). Rails offers things like `try(:foo)` to quickly solve that equivalent of the "null-pointer"- exception, without forcing the developers to dive and in and solve the reason why it is nil, or solve it with some design pattern (adapters, null-pattern etc) either: just keep sprinkling `try()` keeps it rattling along too. Somewhat. So, yes: lack of proper design and architecture is the real problem behind those "ball-of-mud" rails projects. But Rails' lack of training-wheels and the ease at which to make the wrong choices, really doesn't help teams aim at proper design and archicture either.
  - joelbluminator 6y ago
    Rails has a flat structure, it has no knowledge how big your project will become. For many, many code bases this is good enough. Look at Gitlab, which is quite big. If you need more structure there are many design patterns you can follow and introduce into your codebase.
    - pdimitar 6y ago
      GitLab is also notoriously difficult to deploy by yourself (okay, lately it has been better though) and slow as hell.
      - joelbluminator 6y ago
        I like their UI just fine. Speed, smoothness, never had much of a problem. And the amounts of features they were able to come up with the last few years is pretty impressive.
        pdimitar 6y ago
        In terms of features I quite like GitLab as well. I just think it's time they rewrote it in something much faster than Rails. I have literally never used a fast GitLab instance. Anecdotal evidence, I am aware. I'd still venture out to claim this says something about the average speed of your average GitLab installation though. I'm rooting for them. GitHub needs competition.
        joelbluminator 6y ago
        Hmm don't see any rewrite in their cards though...they're pretty much gonna ride this thing with Ruby. If Shopify did it with their monster scale I bet they can as well.
  - e12e 6y ago
    > Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns. I think this is only half true. Rails certainly forces very little on you - but has lots of documentation and helping hands pushing you towards tdd - and it has fairly powerful and simple tools to help with data modeling - as long as your data can fit reasonably in the ActiveRecord pattern. More complex subsystems can be split out into rails engines or services. All that said,it is indeed easy, without some discipline, to roll out complected controllers and views. But I don't think it's fair to say that rails the framework via structure or its official guides, encourages that. Quite the opposite. As for "try" (now for a long time largely subsumed by ruby's built in &-operator) - that can be helpful where appropriate, like with handling input,and occasionally with explicitly optional relationships and nullable values. But of course NULLs should normally be avoided, and the database should be leveraged to ensure data integrity. And rails allow you to do that.
- pdimitar 6y ago
  Well, what you said would be true if management was sympathetic to the argument of "the language and framework we are using no longer serves the project well, so let's rewrite". Since they are not, projects are, 99% of the time, stuck with their first choice of language / framework for life.
  - joelbluminator 6y ago
    What I meant was you can take a messy Rails monolith and do a million things to improve it (including breaking it into smaller independent services if that's your thing). Rewriting in another language is the last thing I would do if the project is big.
- e12e 6y ago
  Having worked and working with rails projects spanning ruby 1.9 through 2.4 and rails 3.2, 4.1, 4.2 and 5.2 - the major issue I've seen with legacy rails is how difficult it is to keep views refactored and seperateted into widgets. Some teams seem to blame erb for this and run towards various different template dsls like haml (equivalent to writing a template language for php, which already is a template language, because the team can't keep views/templates simple). Fat/smart models help - but the old/standard tools in rails (helpers and partials) INMHO is poor tooling for the "view" layer - and this just gets worse with Javascript in the mix. That is finally being addressed - I've yet to experiment with it, but I like the idea: https://github.blog/2020-12-15-encapsulating-ruby-on-rails-views/ https://github.blog/2020-12-15-encapsulating-ruby-on-rails-v... Another option is of course to just use rails as an api server, and do the front end in react/vue etc. Although, at that point, you might be better off just using postgraphile or hasura. The other real problem I see in some of our projects, is developers simply not trying to learn minimal best practices (just reading a few paragraphs on rails guides...). And that leads to many awkward choices, a lot of re-inventing subsystems that already exist in rails (because developers didn't have a look before coding up a quick fix) - and few tests and poor testability. But those strike me as much more cases of people "holding it wrong" than rails being the problem. Finally, I think there's still some issues in rails 6 with asset handling - but overall rails 6 seems like a comprehensive, solid and easy to use framework.
  - berkes 6y ago
    > But those strike me as much more cases of people "holding it wrong" than rails being the problem. My idea exactly. To stretch that analogy: Rails has guides, books and neat API documentation explaining how you should "hold it properly" (and when not to etc.). But it also lacks "notches", "crossbeams" or "ridges" that help people "hold it properly" on a daily basis.
twic 6y ago
> And Java is not magically making the tangle of classes, jobs, callbacks, listeners and whatnot dissapear. Make it disappear, no, but it can make it much easier to create, using Spring's ClassJobCallbackListenerTangleFactory.

by berkes 6y ago

joelbluminator 6y ago

Rails is alright. It's just a great scapegoat for bad teams working under impossible deadlines: "Our code is unmaintainable because Rails! We need 1 year to rewrite it in Go/Elixir/Java". I mean, because Rails has a flat structure you couldn't ever take the time to reactor that piece of crap code you wrote for 2 years? really? You didn't notice a model stopped making sense or growing in complexity? I see the same criticism with PHP. It's perfectly fine, stop blaming the tool.

berkes 6y ago
Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns. On contrary: often it encourages bad practices through "defacto" standard gems, or by making "the wrong choice" easier than "the proper design pattern". A "concern" is a simple way to turn a 800-lines controller into four 300 lines modules that amount to the same ball-of-mud, for example. (Concerns have great use-cases, but most often it is not the solution to your problem). Rails offers things like `try(:foo)` to quickly solve that equivalent of the "null-pointer"- exception, without forcing the developers to dive and in and solve the reason why it is nil, or solve it with some design pattern (adapters, null-pattern etc) either: just keep sprinkling `try()` keeps it rattling along too. Somewhat. So, yes: lack of proper design and architecture is the real problem behind those "ball-of-mud" rails projects. But Rails' lack of training-wheels and the ease at which to make the wrong choices, really doesn't help teams aim at proper design and archicture either.
- joelbluminator 6y ago
  Rails has a flat structure, it has no knowledge how big your project will become. For many, many code bases this is good enough. Look at Gitlab, which is quite big. If you need more structure there are many design patterns you can follow and introduce into your codebase.
  - pdimitar 6y ago
    GitLab is also notoriously difficult to deploy by yourself (okay, lately it has been better though) and slow as hell.
    - joelbluminator 6y ago
      I like their UI just fine. Speed, smoothness, never had much of a problem. And the amounts of features they were able to come up with the last few years is pretty impressive.
      - pdimitar 6y ago
        In terms of features I quite like GitLab as well. I just think it's time they rewrote it in something much faster than Rails. I have literally never used a fast GitLab instance. Anecdotal evidence, I am aware. I'd still venture out to claim this says something about the average speed of your average GitLab installation though. I'm rooting for them. GitHub needs competition.
        joelbluminator 6y ago
        Hmm don't see any rewrite in their cards though...they're pretty much gonna ride this thing with Ruby. If Shopify did it with their monster scale I bet they can as well.
- e12e 6y ago
  > Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns. I think this is only half true. Rails certainly forces very little on you - but has lots of documentation and helping hands pushing you towards tdd - and it has fairly powerful and simple tools to help with data modeling - as long as your data can fit reasonably in the ActiveRecord pattern. More complex subsystems can be split out into rails engines or services. All that said,it is indeed easy, without some discipline, to roll out complected controllers and views. But I don't think it's fair to say that rails the framework via structure or its official guides, encourages that. Quite the opposite. As for "try" (now for a long time largely subsumed by ruby's built in &-operator) - that can be helpful where appropriate, like with handling input,and occasionally with explicitly optional relationships and nullable values. But of course NULLs should normally be avoided, and the database should be leveraged to ensure data integrity. And rails allow you to do that.
pdimitar 6y ago
Well, what you said would be true if management was sympathetic to the argument of "the language and framework we are using no longer serves the project well, so let's rewrite". Since they are not, projects are, 99% of the time, stuck with their first choice of language / framework for life.
- joelbluminator 6y ago
  What I meant was you can take a messy Rails monolith and do a million things to improve it (including breaking it into smaller independent services if that's your thing). Rewriting in another language is the last thing I would do if the project is big.
e12e 6y ago
Having worked and working with rails projects spanning ruby 1.9 through 2.4 and rails 3.2, 4.1, 4.2 and 5.2 - the major issue I've seen with legacy rails is how difficult it is to keep views refactored and seperateted into widgets. Some teams seem to blame erb for this and run towards various different template dsls like haml (equivalent to writing a template language for php, which already is a template language, because the team can't keep views/templates simple). Fat/smart models help - but the old/standard tools in rails (helpers and partials) INMHO is poor tooling for the "view" layer - and this just gets worse with Javascript in the mix. That is finally being addressed - I've yet to experiment with it, but I like the idea: https://github.blog/2020-12-15-encapsulating-ruby-on-rails-views/ https://github.blog/2020-12-15-encapsulating-ruby-on-rails-v... Another option is of course to just use rails as an api server, and do the front end in react/vue etc. Although, at that point, you might be better off just using postgraphile or hasura. The other real problem I see in some of our projects, is developers simply not trying to learn minimal best practices (just reading a few paragraphs on rails guides...). And that leads to many awkward choices, a lot of re-inventing subsystems that already exist in rails (because developers didn't have a look before coding up a quick fix) - and few tests and poor testability. But those strike me as much more cases of people "holding it wrong" than rails being the problem. Finally, I think there's still some issues in rails 6 with asset handling - but overall rails 6 seems like a comprehensive, solid and easy to use framework.
- berkes 6y ago
  > But those strike me as much more cases of people "holding it wrong" than rails being the problem. My idea exactly. To stretch that analogy: Rails has guides, books and neat API documentation explaining how you should "hold it properly" (and when not to etc.). But it also lacks "notches", "crossbeams" or "ridges" that help people "hold it properly" on a daily basis.

twic 6y ago

> And Java is not magically making the tangle of classes, jobs, callbacks, listeners and whatnot dissapear. Make it disappear, no, but it can make it much easier to create, using Spring's ClassJobCallbackListenerTangleFactory.