4 ms·

I love rails, but despite its presense for over a decade, it doesn't feel mature. Something as basic as a native left join in ActiveRecord wasn't added until R

I love rails, but despite its presense for over a decade, it doesn't feel mature. Something as basic as a native left join in ActiveRecord wasn't added until Rails 5.0, on June 30, 2016. Something as basic as native multiple database support wasn't released until Rails 6.0, on August 16, 2019, 15 years after its initial release... These are just two examples.

joevandyk 6y ago
I've worked with Rails for since 2005, I've never needed those features yet.
tyre 6y ago
Multi-database support is not "basic". At what point do you need that? What percentage of users do? Regardless, it was fully supported in gems for years before it went into Rails. It's nice to have it in core. But to say that Rails doesn't feel mature without it? Come on.
- zbentley 6y ago
  > At what point do you need that? What percentage of users do? In my experience, rather a lot.
  - obiefernandez 6y ago
    If you need to connect to multiple databases at a time for your business logic then you're doing it wrong.
    - zbentley 6y ago
      ...are you serious? Virtually every software shop I've worked at has had most backend code communicating with multiple databases to get the job done. Sometimes those databases were behind [micro]service abstractions and the communication was indirected by RPC/one-way async dispatch. Sometimes it wasn't. But multiple backend datastores' contents were required for most business operations. The only places I've worked with that didn't need that were very, very small (single digits of thousands or fewer users).
- yxhuvud 6y ago
  Of six rails shops I've worked on, half used connection to a secondary sql database in one way or another. Exact use cases has differed but I wouldn't be surprised if it is actually a rather high percentage of medium sized to big apps that use multiples.
whycombagator 6y ago
Do you have any examples of features that haven't been added yet, which prevent Rails from being considered mature?
deleted 6y ago
[deleted]
loktarogar 6y ago
Rails _did_ support multiple databases up until then, it just wasn't _as easy_ as everything else in rails. You just defined another database in database.yml (say "second_database") and then ran something like class Foo < ActiveRecord::Base establish_connection :second_database end Still pretty straight forward and simple - just opaque. A lot was available in the Rails ecosystem or using Rails code without being explicitly supported by Rails itself. Much of the last few years has been including support for stuff like this that was already being used. To me, that's what a mature framework does.
- viraptor 6y ago
  That's just per-model database annotation. It's not enough for use cases like: data sharding, switching reader/writer endpoints at runtime, and a few others. I wouldn't count the basic case as "multi-db support"
  - mathnmusic 6y ago
    I built a Rails app with exactly that set up: sharding, dynamic switching of read/write queries across multiple slaves 10 years ago. It wasn't hard at all. Ruby's full dynamic nature makes many things easy.
    - viraptor 6y ago
      Yes, I mentioned it too https://news.ycombinator.com/item?id=24937220 https://news.ycombinator.com/item?id=24937220 - it's relatively easy to add this if needed. But I would not describe it as supported natively.
viraptor 6y ago
> native multiple database support wasn't released until Rails 6.0 While it wasn't in rails natively, you could do it in rails 5 in ~10 extra lines and before with... considerably more hacking. But there were external projects which gave you the possibility.
jrochkind1 6y ago
Do you mean it didn't feel mature before June 2016 or August 2019? Cause... those things are there now, so how can they be examples of it not feeling mature now? What's it missing for you now to feel mature? (And also, lots of people and code definitely did left joins and multiple databases in Rails before those dates, without needing to add any sort of plugin/additional dependency. I did myself, plenty of times! Rails just added features to make them smoother and more complete. Which is actually examples of how mature it is, that it went back and made smoother things people were already doing in less smooth ways, isn't that what maturity looks like?)
- herpderperator 6y ago
  Well, business don't jump on the latest version right away for many reasons (stability, bugs, upgrade woes...) Maturity is closely correlated to how long things have been around. Just because multiple database support was officially added on August 2019 it doesn't make it mature after that date. It takes a long time to achieve maturity - people to adopt and improve on that functionality without breaking things. We have been using multiple databases for years as well, done our own way, which will now have to be re-done in the upgrade to Rails 6. It's obviously not a plug-and-play replacement. It's never clear how long gems will be maintaned for, and when a new gem (like multiverse, which is the multi-database gem I suppose others are referring to) comes out, it doesn't mean that businesses are going to jump on it right away. It needs to be around for some time so that support and its reputation start to build up a case to use it in production. That's why having it in core is important.
  - jrochkind1 6y ago
    So I have been accessing multiple databases for years, without any third-party gems. But it's true I've been doing it in limited ways, only a few tables that aren't the 'main' database, the secondary database being managed externally. The things that were difficult before (that I didn't do), that are now supported/smoother, include: migrations (schema-history-as-code) for multiple databases; and the really new exciting feature, different database connections used for read and for write. (i'm sure there are other platforms that support that, but I know it's not universal). To me these seem like fairly advanced features, I am not sure how many/which other "competing" frameworks support these features; it's a matter of opinion whether these features are required for 'maturity' or not, I'm not going to argue about that. But to be clear that basic ability to connect to multiple databases has existed since long before August 2019. For the other feature mentioned as being introduced four years ago in 2016, trying to make the argument that it indicates a lack of maturity because it should have existed for even more than 4 years in order to call it 'mature'? I think it's clear there is just some axe-grinding going on there. In general, whatever Rails faults are (and of course it has plenty) I don't think a lack of "maturity" is one of them. There are few frameworks/platforms more mature (and I would actually be interested in what examples you are thinking of). If I wanted to talk about the places where Rails isn't as mature as would be liked, it's not features that don't exist or features that were introduced "only" four years ago -- it's in some new features that IMO were introduced with insufficient stability and polish, like webpack integration. That, or ActionCable, are much better examples if you want places where Rails isn't mature. The examples in this thread are... silly.

joevandyk 6y ago

I've worked with Rails for since 2005, I've never needed those features yet.

tyre 6y ago

Multi-database support is not "basic". At what point do you need that? What percentage of users do? Regardless, it was fully supported in gems for years before it went into Rails. It's nice to have it in core. But to say that Rails doesn't feel mature without it? Come on.

zbentley 6y ago
> At what point do you need that? What percentage of users do? In my experience, rather a lot.
- obiefernandez 6y ago
  If you need to connect to multiple databases at a time for your business logic then you're doing it wrong.
  - zbentley 6y ago
    ...are you serious? Virtually every software shop I've worked at has had most backend code communicating with multiple databases to get the job done. Sometimes those databases were behind [micro]service abstractions and the communication was indirected by RPC/one-way async dispatch. Sometimes it wasn't. But multiple backend datastores' contents were required for most business operations. The only places I've worked with that didn't need that were very, very small (single digits of thousands or fewer users).
yxhuvud 6y ago
Of six rails shops I've worked on, half used connection to a secondary sql database in one way or another. Exact use cases has differed but I wouldn't be surprised if it is actually a rather high percentage of medium sized to big apps that use multiples.

whycombagator 6y ago

Do you have any examples of features that haven't been added yet, which prevent Rails from being considered mature?

deleted 6y ago

[deleted]

loktarogar 6y ago

Rails _did_ support multiple databases up until then, it just wasn't _as easy_ as everything else in rails. You just defined another database in database.yml (say "second_database") and then ran something like class Foo < ActiveRecord::Base establish_connection :second_database end Still pretty straight forward and simple - just opaque. A lot was available in the Rails ecosystem or using Rails code without being explicitly supported by Rails itself. Much of the last few years has been including support for stuff like this that was already being used. To me, that's what a mature framework does.

viraptor 6y ago
That's just per-model database annotation. It's not enough for use cases like: data sharding, switching reader/writer endpoints at runtime, and a few others. I wouldn't count the basic case as "multi-db support"
- mathnmusic 6y ago
  I built a Rails app with exactly that set up: sharding, dynamic switching of read/write queries across multiple slaves 10 years ago. It wasn't hard at all. Ruby's full dynamic nature makes many things easy.
  - viraptor 6y ago
    Yes, I mentioned it too https://news.ycombinator.com/item?id=24937220 https://news.ycombinator.com/item?id=24937220 - it's relatively easy to add this if needed. But I would not describe it as supported natively.

viraptor 6y ago

> native multiple database support wasn't released until Rails 6.0 While it wasn't in rails natively, you could do it in rails 5 in ~10 extra lines and before with... considerably more hacking. But there were external projects which gave you the possibility.

jrochkind1 6y ago

Do you mean it didn't feel mature before June 2016 or August 2019? Cause... those things are there now, so how can they be examples of it not feeling mature now? What's it missing for you now to feel mature? (And also, lots of people and code definitely did left joins and multiple databases in Rails before those dates, without needing to add any sort of plugin/additional dependency. I did myself, plenty of times! Rails just added features to make them smoother and more complete. Which is actually examples of how mature it is, that it went back and made smoother things people were already doing in less smooth ways, isn't that what maturity looks like?)

herpderperator 6y ago
Well, business don't jump on the latest version right away for many reasons (stability, bugs, upgrade woes...) Maturity is closely correlated to how long things have been around. Just because multiple database support was officially added on August 2019 it doesn't make it mature after that date. It takes a long time to achieve maturity - people to adopt and improve on that functionality without breaking things. We have been using multiple databases for years as well, done our own way, which will now have to be re-done in the upgrade to Rails 6. It's obviously not a plug-and-play replacement. It's never clear how long gems will be maintaned for, and when a new gem (like multiverse, which is the multi-database gem I suppose others are referring to) comes out, it doesn't mean that businesses are going to jump on it right away. It needs to be around for some time so that support and its reputation start to build up a case to use it in production. That's why having it in core is important.
- jrochkind1 6y ago
  So I have been accessing multiple databases for years, without any third-party gems. But it's true I've been doing it in limited ways, only a few tables that aren't the 'main' database, the secondary database being managed externally. The things that were difficult before (that I didn't do), that are now supported/smoother, include: migrations (schema-history-as-code) for multiple databases; and the really new exciting feature, different database connections used for read and for write. (i'm sure there are other platforms that support that, but I know it's not universal). To me these seem like fairly advanced features, I am not sure how many/which other "competing" frameworks support these features; it's a matter of opinion whether these features are required for 'maturity' or not, I'm not going to argue about that. But to be clear that basic ability to connect to multiple databases has existed since long before August 2019. For the other feature mentioned as being introduced four years ago in 2016, trying to make the argument that it indicates a lack of maturity because it should have existed for even more than 4 years in order to call it 'mature'? I think it's clear there is just some axe-grinding going on there. In general, whatever Rails faults are (and of course it has plenty) I don't think a lack of "maturity" is one of them. There are few frameworks/platforms more mature (and I would actually be interested in what examples you are thinking of). If I wanted to talk about the places where Rails isn't as mature as would be liked, it's not features that don't exist or features that were introduced "only" four years ago -- it's in some new features that IMO were introduced with insufficient stability and polish, like webpack integration. That, or ActionCable, are much better examples if you want places where Rails isn't mature. The examples in this thread are... silly.