1. 8
  1. 3

    If you’d asked me five years ago how to safely deploy a change of this size in Ruby, I’d have a very simple answer: you can’t.

    Very often, Ruby code is just not refactored – it’s too much effort with too much risk for too marginal of a benefit.

    I feel like ruby suffers from a combination of being a lot of people’s first language and being adopted by young startups with wild west engineering practices. These new engineers are using ruby when they run into each class of mistake for the first time. Neither the language nor the engineering organization saved them from those mistakes. They grow to resent the language. They find another language that promises to let them do less in a way that will help them avoid their mistakes. That often coincides with a new job in another organization that has more routine engineering practices. They run into fewer of these mistakes. Partly because the language saves them. But also because they are in an organization that encourages them to rely on more dependable practices and they have encountered a lot of these errors already so they instinctively stay away from them. It feels easier to them and confirmation bias sets in.

    It never seems to occur to them that they could also just choose to do less with ruby or that they could have helped their previous organization adopt ruby practices that avoid these same errors. Nothing highlights this for me more than type checking. You can read previous rants about ruby typing from this author (e.g. Zombified) and see how these complaints aren’t really about typing. It’s about the shape of APIs. Type systems don’t prevent you from designing an API where the same function name can expect two different parameter sets and return different types. So if you think the Popen API is error-prone (I probably agree on that point) then you can easily adopt a practice of not using it. That isn’t exactly hard to enforce in CI. You could possibly even use ruby Refinement system to prevent your modules from being able to access it.

    1. 2

      So as usual, consider not writing Ruby, but if you do, use type signatures, and maybe 100% branch coverage too, as annoying as it seems.

      Could someone more into Ruby ecosystem explain why the OP could have written this paragraph about “not writing Ruby”? Is Ruby a dying language?

      1. 5

        strong opinion syndrome

        1. 4

          People thinking only strictly typed languages are worthy are prone to not recommend not strictly typed languages like Ruby. I like Ruby and I have made extensive refactors without Sorbet&co by having confidence in my tests. My colleague who swears by C# and Typescript will talk your ears off “proving” how such a thing is impossible.

          To each their own and let’s stop trying to find the one size fits all magical tool.

          1. 4

            OP was a big ruby community member with many contributions to his name, who fell out with ruby for, first, not solving the language and runtime issues he thought were the most important, then, for solving them in a way he likes. He does go now.

            1. 3

              If you want what this post wants (good types and safety rails) Ruby is a bad choice for those things. Sure there is sorbet and writing a billion tests, but even Crystal would be a better choice if those things are your priority.

              If you want is to play with a highly malleable environment and don’t want smalltalk then Ruby is where it’s at, though.

              1. 2

                I can’t speak about the OP, but Ruby definitely isn’t dying. It might not be growing, but it is keeping a good level and there are new devs coming to Ruby all the time.

                1. 1

                  They are into Go, based on the other posts on the blog.