> b. The lack of an ability to seal objects, classes, and modules from further modification is a problem. "freeze" has been there from the very start". You can

> b. The lack of an ability to seal objects, classes, and modules from further modification is a problem. "freeze" has been there from the very start". You can freeze objects, or individual classes and modules (because, hey, they're objects) just fine. I'm all for freezing more stuff, and the migration towards freezing string literals was good, and you can freeze very aggressively in your own code, including system classes. > c. Ruby 3 should've broken compatibility by adding gradual typing. If they had, it would've split the community. Some of us would've forked it. Any degree of gradual typing in Ruby will need to be extremely cautiously approached and/or mostly optional, as it strikes at the heart of what makes Ruby what it is. There are places it would work and be fine, and there are places where it would massively hamper productivity. > For type-safer things that look like Ruby, Crystal is an almost viable, interesting alternative. Crystal has a fraction of the community and too many pointless differences to Ruby for many of us to consider. > The world mostly uses js and python. One can either be a hipster with obscure tools or get things done with the lowest TCO/highest ROI. Funny. My career has spanned multiple "the world mostly uses $language" phases, and it's never affected my TCO/ROI whether what I've happened to use matches the current $language. What has mattered is picking a language the right libraries are available for and that I'm comfortable in. Sometimes I only get one of those, and sometimes that means picking a different language the Ruby, but writing composable tools means it's quite rare, and each time makes it rarer.