Having immutable objects by default isn’t incredibly commonplace outside of functional languages. It certainly isn’t unique to Ruby and seems out of place in a discussion comparing Ruby to Python. Fortunately, you can defensively freeze any objects you’re passing around to avoid the most common issues with mutable objects.
Immutable strings is a more popular programming language feature and Ruby has a mechanism for opting into that. It’s so commonplace that the complaint usually isn’t that a string can be modified, but rather that every source file includes a magic comment to prevent that. Besides data safety, the VM can optimize frozen strings, so popular linters will flip that setting on for you. String mutability isn’t a practical issue for modern codebases. And, as language design goes, it’s kinda nice not needing to use a parallel set of classes for mutable and immutable string data IMHO.
With that said, the magic comment is a wart and folks are looking at making immutable strings the default. But, there’s a strong desire to avoid breaking the world. The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.
Not only a wart but a massive foot gun, not shared by any other language, as I said. It is incredibly common to create hash tables using strings as keys, and Ruby makes this dangerous by default.
> Having immutable objects by default isn’t incredibly commonplace outside of functional languages
They make it easy to create immutable objects. Python has tuples and immutable data classes. Strings are immutable.
> The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.
In the meantime, this ridiculous foot gun that no other language shares exists. That is a fact, and the fix being hard does not make it any less of a fact.
