7 ms·

Ultimately this is why I don't like to work in Ruby. You can just never trust any line of code between the gem updates, the unhelpful signatures, the overrelia

Ultimately this is why I don't like to work in Ruby. You can just never trust any line of code between the gem updates, the unhelpful signatures, the overreliance on hashes everywhere, and a million different levels of mix-ins and indirection. Yeah, it's expressive, but how much time are you really saving once you consider all these maintenance headaches?

joelbluminator 5y ago
This is quite rare and also types would have done nothing in this case.
stouset 5y ago
This exact problem could have happened in any language. Literally zero of it has to do with Ruby or the ecosystem.
- gedy 5y ago
  No, this is particularly bad in Ruby. Many languages, esp. compiled do not have the same issues.
  - chucke 5y ago
    Java and log4j would like a word with you.
    - jorams 5y ago
      The problem with log4j is that they didn't introduce a breaking change, allowing vulnerable functionality the maintainers already considered problematic to stick around.
  - dagmx 5y ago
    What language would avoid the problem?
  - Gigachad 5y ago
    That’s often the case but for this particular issue, it could have happened in any language because it’s still returning the exact same type. Its an array of the same record type in both instances.
    - emodendroket 5y ago
      Ultimately this is more social than technical.
- jchw 5y ago
  Certainly it has something to do with the ecosystem, if the most popular MongoDB driver in the ecosystem is making breaking changes in minor versions. That said, strong types can be a godsend for catching accidental breaks, even if it wouldn’t necessarily have helped here. A strongly typed language that has a more disciplined ecosystem is less likely to run into these kinds of issues. It’s one of the tradeoffs you pick when deciding between languages. I decided the tradeoffs didn’t work well for me and left for compiled languages, for now.
  - julik 5y ago
    This is exactly the case where nothing about types, language or opinions about the Ruby community has to do with the problem at hand. This would not be caught by compiling, strong types or anything else - this is a change in behavior which has been arbitrarily done by the maintainers of the dependency. > Certainly it has something to do with the ecosystem, if the most popular MongoDB driver in the ecosystem is making breaking changes in minor versions. How should this be handled? Should a "good" ecosystem vet every single change in every single library that gets updated? Or should there be no libraries and only stdlib instead (wait, I think I know a compiled language which did just that for quite a few years, let me think which one that was again...)
    - jchw 5y ago
      You can feel that it has nothing to do with the ecosystem or its norms, but it happened in the Ruby ecosystem right in a rather important foundational library, and anecdotally it does feel like it’s a problem that recurs over time. That doesn’t mean there’s a good solution. You can’t just upend the defacto attitude of an ecosystem at will. > How should this be handled? Should a "good" ecosystem vet every single change in every single library that gets updated? Or should there be no libraries and only stdlib instead (wait, I think I know a compiled language which did just that for quite a few years, let me think which one that was again...) This isn’t really about Ruby vs all compiled languages, I mean, Brainfuck is a compiled language and that doesn’t mean I was endorsing Brainfuck to replace Ruby. However I would certainly endorse Go to replace Ruby. Rust too, although using Rust to do web development stuff feels like using a nuclear warhead to open a door. Anyway, the reason why types is relevant to this discussion is because types are contracts that are statically enforced and the break that occurred happened due to a contract change. This change illustrates that even if you do have types it doesn’t guarantee you won’t have breaking contract changes. However, eliminating entire classes of accidental or intentional contract breaks is an obvious win/win. If it was as complex and obtuse as C++, nobody would bother. But C++ isn’t the only game in town anymore for fast compiled strongly typed languages.
- deleted 5y ago
  [deleted]
- metafunctor 5y ago
  You're right that the language isn't to blame as such. But if a change like this doesn't cause some kind of uproar in the Ruby community, then the community has a problem.
  - astrowilson 5y ago
    It won’t cause a uproar because Ruby/Rails changes APIs on minor versions all the time. Breaking changes are pushed at a yearly rate and everyone is just expected to cope with them.
    - metafunctor 5y ago
      That’s what I’ve gathered. That still seems stupid to me. Why does the Ruby/Rails community do that?
- astrowilson 5y ago
  It definitely has something to do with Ruby and Rails. Ruby and Rails introduces API changes on minor versions all the time, sometimes even without prior warnings, so people shouldn’t expect related gems to be any different.
- ramchip 5y ago
  In theory yes, but in practice there's a big difference between ecosystems. I maintain apps in Ruby and Elixir, and as far as I can remember, all the Elixir libraries I use respect semver. Whereas with Ruby it's much more mixed.
ljm 5y ago
We're just trading anecdotes at this point but I can't say I've encountered the same problems over the past decade of working with it. That's generally because of limiting dependencies, but also because it's a good idea to peek at the changelog or release notes when bumping the minor or major version. TFA doesn't mention or acknowledge this aspect of the issue, but it did surprise me that they considered a version bump from 7.0.8 to 7.3.3 to be innocent looking. In fact, these 'minor' releases actually appear to be quite significant and the issue in question in TFA was explicitly documented. [0][1] I hate to say it but this was just a case of sloppy work on the startup's part. It took me less than 5 minutes to find that info. [0] https://docs.mongodb.com/mongoid/current/tutorials/mongoid-upgrade/#logical-operations https://docs.mongodb.com/mongoid/current/tutorials/mongoid-u... [1] https://github.com/mongodb/mongoid/releases/tag/v7.1.0 https://github.com/mongodb/mongoid/releases/tag/v7.1.0
- newaccount74 5y ago
  It took you 5 minutes to find the info because you knew what you were looking for. Expecting programmers to audit all of their code before a minor update is ridiculous.
  - ljm 5y ago
    'Auditing all your code' isn't the same as looking up the changes for a certain version on its github release page or a changelog page (if it has one). It's not the responsibility of OSS maintainer to ensure your software still functions after an upgrade if you're not even willing to spend a modicum of effort to hold up your own end of that bargain. This isn't a big ask, it's why there are changelogs and release notes in the first place; they make it so you don't have to audit the code every time the version changes. If you're not willing to do that and want unattended upgrades for all dependencies, then this is where the 'no warranty' aspect of that OSS license comes in.
    - Gigachad 5y ago
      >It's not the responsibility of OSS maintainer The OSS maintainer has no responsibilities at all so you are right. But if anyone was to blame, it's certainly the library. It's outrageous to radically change a function while keeping the name the same. Because of exactly this issue. If they renamed it you would get an exception which is much nicer.

joelbluminator 5y ago

This is quite rare and also types would have done nothing in this case.

stouset 5y ago

This exact problem could have happened in any language. Literally zero of it has to do with Ruby or the ecosystem.

gedy 5y ago
No, this is particularly bad in Ruby. Many languages, esp. compiled do not have the same issues.
- chucke 5y ago
  Java and log4j would like a word with you.
  - jorams 5y ago
    The problem with log4j is that they didn't introduce a breaking change, allowing vulnerable functionality the maintainers already considered problematic to stick around.
- dagmx 5y ago
  What language would avoid the problem?
- Gigachad 5y ago
  That’s often the case but for this particular issue, it could have happened in any language because it’s still returning the exact same type. Its an array of the same record type in both instances.
  - emodendroket 5y ago
    Ultimately this is more social than technical.
jchw 5y ago
Certainly it has something to do with the ecosystem, if the most popular MongoDB driver in the ecosystem is making breaking changes in minor versions. That said, strong types can be a godsend for catching accidental breaks, even if it wouldn’t necessarily have helped here. A strongly typed language that has a more disciplined ecosystem is less likely to run into these kinds of issues. It’s one of the tradeoffs you pick when deciding between languages. I decided the tradeoffs didn’t work well for me and left for compiled languages, for now.
- julik 5y ago
  This is exactly the case where nothing about types, language or opinions about the Ruby community has to do with the problem at hand. This would not be caught by compiling, strong types or anything else - this is a change in behavior which has been arbitrarily done by the maintainers of the dependency. > Certainly it has something to do with the ecosystem, if the most popular MongoDB driver in the ecosystem is making breaking changes in minor versions. How should this be handled? Should a "good" ecosystem vet every single change in every single library that gets updated? Or should there be no libraries and only stdlib instead (wait, I think I know a compiled language which did just that for quite a few years, let me think which one that was again...)
  - jchw 5y ago
    You can feel that it has nothing to do with the ecosystem or its norms, but it happened in the Ruby ecosystem right in a rather important foundational library, and anecdotally it does feel like it’s a problem that recurs over time. That doesn’t mean there’s a good solution. You can’t just upend the defacto attitude of an ecosystem at will. > How should this be handled? Should a "good" ecosystem vet every single change in every single library that gets updated? Or should there be no libraries and only stdlib instead (wait, I think I know a compiled language which did just that for quite a few years, let me think which one that was again...) This isn’t really about Ruby vs all compiled languages, I mean, Brainfuck is a compiled language and that doesn’t mean I was endorsing Brainfuck to replace Ruby. However I would certainly endorse Go to replace Ruby. Rust too, although using Rust to do web development stuff feels like using a nuclear warhead to open a door. Anyway, the reason why types is relevant to this discussion is because types are contracts that are statically enforced and the break that occurred happened due to a contract change. This change illustrates that even if you do have types it doesn’t guarantee you won’t have breaking contract changes. However, eliminating entire classes of accidental or intentional contract breaks is an obvious win/win. If it was as complex and obtuse as C++, nobody would bother. But C++ isn’t the only game in town anymore for fast compiled strongly typed languages.
deleted 5y ago
[deleted]
metafunctor 5y ago
You're right that the language isn't to blame as such. But if a change like this doesn't cause some kind of uproar in the Ruby community, then the community has a problem.
- astrowilson 5y ago
  It won’t cause a uproar because Ruby/Rails changes APIs on minor versions all the time. Breaking changes are pushed at a yearly rate and everyone is just expected to cope with them.
  - metafunctor 5y ago
    That’s what I’ve gathered. That still seems stupid to me. Why does the Ruby/Rails community do that?
astrowilson 5y ago
It definitely has something to do with Ruby and Rails. Ruby and Rails introduces API changes on minor versions all the time, sometimes even without prior warnings, so people shouldn’t expect related gems to be any different.
ramchip 5y ago
In theory yes, but in practice there's a big difference between ecosystems. I maintain apps in Ruby and Elixir, and as far as I can remember, all the Elixir libraries I use respect semver. Whereas with Ruby it's much more mixed.

ljm 5y ago

We're just trading anecdotes at this point but I can't say I've encountered the same problems over the past decade of working with it. That's generally because of limiting dependencies, but also because it's a good idea to peek at the changelog or release notes when bumping the minor or major version. TFA doesn't mention or acknowledge this aspect of the issue, but it did surprise me that they considered a version bump from 7.0.8 to 7.3.3 to be innocent looking. In fact, these 'minor' releases actually appear to be quite significant and the issue in question in TFA was explicitly documented. [0][1] I hate to say it but this was just a case of sloppy work on the startup's part. It took me less than 5 minutes to find that info. [0] https://docs.mongodb.com/mongoid/current/tutorials/mongoid-upgrade/#logical-operations https://docs.mongodb.com/mongoid/current/tutorials/mongoid-u... [1] https://github.com/mongodb/mongoid/releases/tag/v7.1.0 https://github.com/mongodb/mongoid/releases/tag/v7.1.0

newaccount74 5y ago
It took you 5 minutes to find the info because you knew what you were looking for. Expecting programmers to audit all of their code before a minor update is ridiculous.
- ljm 5y ago
  'Auditing all your code' isn't the same as looking up the changes for a certain version on its github release page or a changelog page (if it has one). It's not the responsibility of OSS maintainer to ensure your software still functions after an upgrade if you're not even willing to spend a modicum of effort to hold up your own end of that bargain. This isn't a big ask, it's why there are changelogs and release notes in the first place; they make it so you don't have to audit the code every time the version changes. If you're not willing to do that and want unattended upgrades for all dependencies, then this is where the 'no warranty' aspect of that OSS license comes in.
  - Gigachad 5y ago
    >It's not the responsibility of OSS maintainer The OSS maintainer has no responsibilities at all so you are right. But if anyone was to blame, it's certainly the library. It's outrageous to radically change a function while keeping the name the same. Because of exactly this issue. If they renamed it you would get an exception which is much nicer.