4 ms·

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

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.

Fire-Dragon-DoL 5y ago
There are things that go wrong when using ActiveSupport, but it's so ingrained in people's workflow that they won't notice. The one I consider the most annoying: it substantially increases load time. ActiveSupport is huge and just requiring it increases the load time by 1.x seconds. Given what it provides, that's substantial. The inability to extract a library (or a service) without depending on ActiveSupport is a cost that doesn't exist with the other approaches. Not to underestimate, your _number_ now responds to `weeks`, and duck typing is the only way you have "interfaces" in Ruby. I can easily picture having a "weeks" or days attribute on some entity and a service object expecting that, now there are subtle bugs when passing accidentally the entity's _value_ instead of the entity itself. Yeah, they are "minor" things, but the point is dying of thousands cuts. The last damage is more subtle: devs, even less experienced devs, will feel authorized to monkey patch. In the private codebases I saw (multiple) this is common. It's not a last resort anymore and it ends up becoming a hard problem to debug and resolve. The ability to monkeypatche pushes devs to NOT design their objects in an extensible fashion. This effectively is the highest damaging consequence, but it's incredibly hard to assess.
- joelbluminator 5y ago
  > The inability to extract a library (or a service) without depending on ActiveSupport is a cost that doesn't exist with the other approaches. I'm not sure what you mean; Rails depends on ActiveSupport so if you're a Rails codebase you don't really care, you already depend on it. If you're a gem author it's your own decision if you want to depend on ActiveSupport or not, I'm sure many gems don't depend on it, and others do. > Not to underestimate, your _number_ now responds to `weeks`, and duck typing is the only way you have "interfaces" in Ruby. I can easily picture having a "weeks" or days attribute on some entity and a service object expecting that, now there are subtle bugs when passing accidentally the entity's _value_ instead of the entity itself. Never seen this. Not saying it can't happen (can u give an example though? not 100% sure what you mean) but I've never seen it. > Yeah, they are "minor" things, but the point is dying of thousands cuts. This is a bit of a hyperbole statement wouldn't you agree? > The last damage is more subtle: devs, even less experienced devs, will feel authorized to monkey patch. I think it happens way less than you think; usually in teams of inexperienced people who discover Ruby and metaprogramming for the first time. But the worst monkeypatching bug I've ever seen was actually done in javascript; a guy monkeypatched some jquery method and broke 20000 websites at once (we were a widget startup). Monkeypatching isn't a Ruby thing it's a dynamic languages thing. I don't see Ruby/Rails culture just encouraging people to monkey patch String or Object. The fact dhh and a very experienced team of devs did it, and tested it and perfected it for years, doesn't mean you should do it. This is pretty common knowledge now and I think 99% of Rubyists would agree.
  - Fire-Dragon-DoL 5y ago
    I wish it was true, still, when I look at authentication done with devise, there is extensive monkeypatching done (probably caused by poor design in Devise itself, but still). > This is a bit of a hyperbole statement wouldn't you agree? I'm not sure, I see many small problems that slowly leads to what the Ruby community is now. That being said, if you look at how many things ActiveSupport monkeypatches, "thousands cuts" it's not an understatement: https://github.com/rails/rails/tree/main/activesupport/lib/active_support/core_ext https://github.com/rails/rails/tree/main/activesupport/lib/a...
    - eloisius 5y ago
      I don’t think you’re helping your case by holding out Devise as a problem example. Devise is extremely popular, works very well, can easily be extended to support different authentication modes like OAuth, and has saved countless hours for many people. In fact, I haven’t worked in the Ruby world for several years now, but devise is one piece of software that I frequently miss when using other languages.
      - Fire-Dragon-DoL 5y ago
        Devise is well known to have many problems. It works out of the box, but when deviating from strictly the use case it was designed for, there is no documentation and the shortcoming of the design become apparent. That's where the monkey patching comes in, usually. But to be clear, I'm stating the facts that many software developer see in the Ruby world when you join an organization that's growing tremendously. As usual, if you fit perfectly in the Rails target and the Devise target, you won't encounter problems.
        joelbluminator 5y ago
        I don't see it sorry. I don't think Shopify crashes every monday because thousands of devs monkeypatch Object all the time or because AS adds 20 miliseconds to load time. Neither does Github or countless othet huge companies. I agree that after a certain size types make a lot of sense and Ruby or other dynamic languages becomes less attractive but ActiveSupport? Works well.

Fire-Dragon-DoL 5y ago

There are things that go wrong when using ActiveSupport, but it's so ingrained in people's workflow that they won't notice. The one I consider the most annoying: it substantially increases load time. ActiveSupport is huge and just requiring it increases the load time by 1.x seconds. Given what it provides, that's substantial. The inability to extract a library (or a service) without depending on ActiveSupport is a cost that doesn't exist with the other approaches. Not to underestimate, your _number_ now responds to `weeks`, and duck typing is the only way you have "interfaces" in Ruby. I can easily picture having a "weeks" or days attribute on some entity and a service object expecting that, now there are subtle bugs when passing accidentally the entity's _value_ instead of the entity itself. Yeah, they are "minor" things, but the point is dying of thousands cuts. The last damage is more subtle: devs, even less experienced devs, will feel authorized to monkey patch. In the private codebases I saw (multiple) this is common. It's not a last resort anymore and it ends up becoming a hard problem to debug and resolve. The ability to monkeypatche pushes devs to NOT design their objects in an extensible fashion. This effectively is the highest damaging consequence, but it's incredibly hard to assess.

joelbluminator 5y ago
> The inability to extract a library (or a service) without depending on ActiveSupport is a cost that doesn't exist with the other approaches. I'm not sure what you mean; Rails depends on ActiveSupport so if you're a Rails codebase you don't really care, you already depend on it. If you're a gem author it's your own decision if you want to depend on ActiveSupport or not, I'm sure many gems don't depend on it, and others do. > Not to underestimate, your _number_ now responds to `weeks`, and duck typing is the only way you have "interfaces" in Ruby. I can easily picture having a "weeks" or days attribute on some entity and a service object expecting that, now there are subtle bugs when passing accidentally the entity's _value_ instead of the entity itself. Never seen this. Not saying it can't happen (can u give an example though? not 100% sure what you mean) but I've never seen it. > Yeah, they are "minor" things, but the point is dying of thousands cuts. This is a bit of a hyperbole statement wouldn't you agree? > The last damage is more subtle: devs, even less experienced devs, will feel authorized to monkey patch. I think it happens way less than you think; usually in teams of inexperienced people who discover Ruby and metaprogramming for the first time. But the worst monkeypatching bug I've ever seen was actually done in javascript; a guy monkeypatched some jquery method and broke 20000 websites at once (we were a widget startup). Monkeypatching isn't a Ruby thing it's a dynamic languages thing. I don't see Ruby/Rails culture just encouraging people to monkey patch String or Object. The fact dhh and a very experienced team of devs did it, and tested it and perfected it for years, doesn't mean you should do it. This is pretty common knowledge now and I think 99% of Rubyists would agree.
- Fire-Dragon-DoL 5y ago
  I wish it was true, still, when I look at authentication done with devise, there is extensive monkeypatching done (probably caused by poor design in Devise itself, but still). > This is a bit of a hyperbole statement wouldn't you agree? I'm not sure, I see many small problems that slowly leads to what the Ruby community is now. That being said, if you look at how many things ActiveSupport monkeypatches, "thousands cuts" it's not an understatement: https://github.com/rails/rails/tree/main/activesupport/lib/active_support/core_ext https://github.com/rails/rails/tree/main/activesupport/lib/a...
  - eloisius 5y ago
    I don’t think you’re helping your case by holding out Devise as a problem example. Devise is extremely popular, works very well, can easily be extended to support different authentication modes like OAuth, and has saved countless hours for many people. In fact, I haven’t worked in the Ruby world for several years now, but devise is one piece of software that I frequently miss when using other languages.
    - Fire-Dragon-DoL 5y ago
      Devise is well known to have many problems. It works out of the box, but when deviating from strictly the use case it was designed for, there is no documentation and the shortcoming of the design become apparent. That's where the monkey patching comes in, usually. But to be clear, I'm stating the facts that many software developer see in the Ruby world when you join an organization that's growing tremendously. As usual, if you fit perfectly in the Rails target and the Devise target, you won't encounter problems.
      - joelbluminator 5y ago
        I don't see it sorry. I don't think Shopify crashes every monday because thousands of devs monkeypatch Object all the time or because AS adds 20 miliseconds to load time. Neither does Github or countless othet huge companies. I agree that after a certain size types make a lot of sense and Ruby or other dynamic languages becomes less attractive but ActiveSupport? Works well.