Not sure this is what you're getting at. I agree with the author though, this aspect of Rails bothered me quite a bit. Knowing that working on a Rails project meant I could magically generate ranges from dates because of ActiveSupport was unsettling - it made me wonder what else was non-native behaviour and waiting to trip me.
I'm surprised that I haven't seen anything about that respond_to? change in the blogs; maybe I've just missed it. I might blog this, although I hate ending a post with "gosh I don't know about this one". Makes me feel like I haven't done all my homework.
To summarize the argument: ActiveSupport is awesome because it has all kinds of fantastic features that Ruby lacks out of the box. But don't use ActiveSupport in your gems because it's going to cause all kinds of crazy dependency issues in folks' applications, whether or not they use Rails!
It strikes me that what's really harmful here is the glacial pace of change in the Ruby Standard Library. Of course, we shouldn't see untried and untested functionality shoved into the standard library willy-nilly: pollution of the standard library with ill-thought-out code is probably even worse.
But, that said, Rails 1.0 came out almost five years ago. In the same time span, we've seen the release of Ruby 1.8.4-7 and 1.9.0 and 1.9.1. It was big news in 2007 when Rails' Object#tap method made it into 1.8.7 and 1.9.
We should be seeing more of this functionality pulled out of ActiveSupport and pushed into the Ruby Standard Library.
The whole manipulating code as date just always seems like such a rich target for exploitation like that ruby yaml bug from a while ago [0]. It seems like a features that would be great if your code never needs data from anywhere else but as soon as you gave data coming in from other sources it would be a bit of a nightmare.
> This comes up _constantly_ during ruby version updates and when updating central libraries that many others depend on (like activesupport).
I understand this was pretty common in the early days of Ruby, around 1.8.7, 1.9.3, 2.0, etc, along with Rails 2.x and earlier. I maintain a number of Rails apps, both at work and personal, and I've never had to do this or heard of anyone else doing it post roughly Rails 4.x and Ruby 2.2+.
It's crazy to me that this is even controversial. The fact that I have no idea where code is coming from in a rails codebase is by far the most aggravating thing about the whole ecosystem.
I just can’t bring myself to get worked up about it - I’ve done a lot of Rails, and I’ve done a lot of pure Ruby. You quite quickly learn which bits come from ActiveSupport when you step outside Rails because… it doesn’t work. It’s not going to trip you up in 8 month’s time after shipping your code, you’re just going to get an exception when you first try to run it, and then either implement it the pure way or add a dependency on ActiveSupport.
Perhaps they are downvoting because of your own ignorance? The aforementioned code does depend on ActiveSupport (or similar library), but has absolutely nothing to do with Rails.
I totally agree with this. This situation where a library has a de facto monopoly on monkey patching is just weird an unfair.
It reminds me a bit of MS's good old EEE strategy. People get comfortable with ActiveSupport to a degree where they start disliking to not have it's small benefits. But the consequence of this behaviour, that most are oblivious to, is that it to a large degree puts Rails in control of the language.
ActiveSupport feels like a leftover from the old days of prototype and jQuery. You search for a solution and half the answers on SO will assume that you are using it (and many of the answer authors don't even know it)
I'm sure it's not going to happen, but I think Rails should stop using ActiveSupport internally. It would allow devs to decide for themselves if they want to pollute the standard library, and also open the door for competition.
While the syntactic sugar of "1.day.ago" is hard to match, I don't think an alternative have to be that bad "ActiveTime.days_ago(1)"
What's wrong with 2.weeks.from_now ? I get that it hurts your sensibilities (SOLID etc), truth is it's fine. I've seen a good share of Rails projects and never had a problem with this yet. We tend to have a knee-jerk reaction to certain things, and sometimes for good reason, but ActiveSupport is used in millions of Rails projects and nothing horrible happens.
Being a developer that works with Rails daily, the first thing that jumped out at me was the code on the screen in the landing page image.
Rails hasn't used named_scope in a long time :)
I also found this bit to be just wrong
"I'm not even joking when I say this, but I think some of the resources out there make it intentionally hard for non-technical people to start learning. Maybe they want to keep this stuff a secret."
I don't believe for a second this exists. It's actually kind of offensive.
> but the best-known Rails sample code is all vulnerable.
Rails is moving so fast now that most sample code is very outdated. Take authentication for example, there's at least 5 different plugins, all favoured as the best way to authenticate in rails at one time or another. Totally hopeless for a newbie to dig out which is the solution to go with, or at least it's a few days trial and error, trying out tutorials here and there. I've done a few rails projects on and off and each time I come back there's tons of new stuff, which is really great, but I would personally like to have more batteries included or "blessed" official plugins because I don't spend all my time in rails land, and it's hard to keep track of all the new goodies.
I'm sorry if you thought this was 'drama,' just trying to make sure that someone doesn't think that this is officially supported by the Rails team or that I'm speaking for anyone. Frankly, I've been running around at Ruby conferences saying "If you want old versions of Rails supported, you should be paying someone to do it," and I think Rails LTS is great, in a personal capacity.
Ah that's it. I'm going through mhartl's Ruby on Rails Tutorial and he has us specify a Rails version to maintain consistency btw the tutorial and our code.
Not sure this is what you're getting at. I agree with the author though, this aspect of Rails bothered me quite a bit. Knowing that working on a Rails project meant I could magically generate ranges from dates because of ActiveSupport was unsettling - it made me wonder what else was non-native behaviour and waiting to trip me.
reply