4 ms·

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 suppo

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
    Shopify has very strict rules to prevent that and they have been working to address that problem for YEARS. They have actually worked on Packwerk (which they use) which enforces the usage of constants when crossing boundaries, rather than any form of interface or duck typing. The load time of a single test is a recurring problem in the Rails world though, so ActiveSupport adds up. Monekypatching doesn't lead to crash (it can, but that's not the point), it leads to: - Less extendable code - Less learning - Less maintainable code Even if the damage is small, given how competitive is the world, why taking the chance for no benefit?
    - joelbluminator 5y ago
      > Even if the damage is small, given how competitive is the world, why taking the chance for no benefit? Well that's the crux of it here, you see it as damage/no benefit while others in the Rails world disagree. It's a difference of opinions that won't be resolved tonight by arguing on Hacker News. I did like your comment about naming consistency in Ruby though, learned something new.

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
  Shopify has very strict rules to prevent that and they have been working to address that problem for YEARS. They have actually worked on Packwerk (which they use) which enforces the usage of constants when crossing boundaries, rather than any form of interface or duck typing. The load time of a single test is a recurring problem in the Rails world though, so ActiveSupport adds up. Monekypatching doesn't lead to crash (it can, but that's not the point), it leads to: - Less extendable code - Less learning - Less maintainable code Even if the damage is small, given how competitive is the world, why taking the chance for no benefit?
  - joelbluminator 5y ago
    > Even if the damage is small, given how competitive is the world, why taking the chance for no benefit? Well that's the crux of it here, you see it as damage/no benefit while others in the Rails world disagree. It's a difference of opinions that won't be resolved tonight by arguing on Hacker News. I did like your comment about naming consistency in Ruby though, learned something new.