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.

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...)

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.

> 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.

Am I to believe that you hold every other language to this same standard? A single maintainer of a reasonably popular project makes one boneheaded decision in a release, and that's enough reason to denounce the entire ecosystem?

> That said, strong types can be a godsend for catching accidental breaks...

Ruby is a strongly typed language.

You probably mean static types, but even that wouldn't have helped here. This was a behavioral change and did not affect any of the (implicit, in Ruby) type signatures of the function. It would not have affected any of the explicit type signatures of the function in other languages. I say this as an enormous proponent of Rust and static typing.

You are tilting at windmills.

I am using the Wikipedia definition of 'strong' vs 'weak' typing.

> Generally, a strongly typed language has stricter typing rules at compile time, which implies that errors and exceptions are more likely to happen during compilation. Most of these rules affect variable assignment, function return values, procedure arguments and function calling. Dynamically typed languages (where type checking happens at run time) can also be strongly typed. Note that in dynamically typed languages, values have types, not variables.

Just out of curiosity, exactly what do you even think weakly typed could mean by your own definition of it?

No need to address the other points, because we're talking about anecdotes and not scientific data. Yes, I'm using a single data point as an example about a feeling I have to justify my opinion.

But it's not really about a single maintainer and project, is it? The thing is that this sort of problem is somewhat common in this environment, which is why people have adopted "rules" they consider common sense about which hoops you're supposed to jump through before minor version updates.

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.

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.

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.

That’s what I’ve gathered. That still seems stupid to me. Why does the Ruby/Rails community do that?

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.

No, this is particularly bad in Ruby. Many languages, esp. compiled do not have the same issues.

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.

Ultimately this is more social than technical.

What language would avoid the problem?

Java and log4j would like a word with you.

The problem with log4j is that they didn't introduce a breaking change, allowing vulnerable functionality the maintainers already considered problematic to stick around.