5 ms·

I've yet to be given a single example of how Rails suffers without types, it's just not an issue Hotwire is the polar opposite of spaghetti code

boredtofears 3y ago
Rails does better than the rest of the Ruby ecosystem without types because it has strong conventions, but if you’ve ever adopted a rails app that doesn’t follow these conventions (or follows different ones like in the 3.x days where they were less defined) refactoring things across an entire codebase can be a gargantuan task. Following variable life cycles in Ruby in general is much harder than a typed language. There are tools like pry for this sort of thing, but that’s more work than just having types with good ide integration.
joshspankit 3y ago
As a sibling comment implies, it can be a huge issue if the existing codebase tosses out conventions. It’s underrated since devs mostly do it without thinking about it, but in enough cases you need to double-check the type before running any operation that requires a certain type. Unchecked it will either crash entirely or cause bugs so esoteric that they are very difficult to debug. I don’t think I’d categorize it as “how Rails suffers without types”, more like “stay away from the edges and you’ll be fine”, but it can still bite you hard if someone mis-steps.
- jack_riminton 3y ago
  But I genuinely can't think of an example that is ever likely to arise, can you give me one? Anything I can think of will immediately throw an error or would be covered by the most basic of test suites
  - joshspankit 3y ago
    > immediately throw an error That’s exactly what we don’t want in production code. We want it to work without errors. An example: assign a variable to the output of a library function, then pass the variable in to a different function. Super basic, super common. One instance of that is calling the first function and expecting an array back but getting any one of ‘String’ (edge case that the library maintainer decided is a good idea) or ‘False’ (maintainer decided that’s what happens when something fails during the call). If you call ‘.each’ within the second function without verifying that the variable is iterable first the function will throw. (I’ve even seen a couple rare cases where a custom class responds to ‘.each’ but is not properly iterable). Most Ruby devs will “just” check before they call ‘.each’, or wrap the second call in a rescue block, but that’s exactly the sort of potential for misstep I’m talking about.
    - jack_riminton 3y ago
      Interesting. I wonder if these came about from engineers just trying to be too clever. The thing I really love about rails is the focus on creating nice boring conventional code. I think the current mania for types has arisen largely out of the js SPA crowd creating problems for themselves doing the opposite,

boredtofears 3y ago

Rails does better than the rest of the Ruby ecosystem without types because it has strong conventions, but if you’ve ever adopted a rails app that doesn’t follow these conventions (or follows different ones like in the 3.x days where they were less defined) refactoring things across an entire codebase can be a gargantuan task. Following variable life cycles in Ruby in general is much harder than a typed language. There are tools like pry for this sort of thing, but that’s more work than just having types with good ide integration.

joshspankit 3y ago

As a sibling comment implies, it can be a huge issue if the existing codebase tosses out conventions. It’s underrated since devs mostly do it without thinking about it, but in enough cases you need to double-check the type before running any operation that requires a certain type. Unchecked it will either crash entirely or cause bugs so esoteric that they are very difficult to debug. I don’t think I’d categorize it as “how Rails suffers without types”, more like “stay away from the edges and you’ll be fine”, but it can still bite you hard if someone mis-steps.

jack_riminton 3y ago
But I genuinely can't think of an example that is ever likely to arise, can you give me one? Anything I can think of will immediately throw an error or would be covered by the most basic of test suites
- joshspankit 3y ago
  > immediately throw an error That’s exactly what we don’t want in production code. We want it to work without errors. An example: assign a variable to the output of a library function, then pass the variable in to a different function. Super basic, super common. One instance of that is calling the first function and expecting an array back but getting any one of ‘String’ (edge case that the library maintainer decided is a good idea) or ‘False’ (maintainer decided that’s what happens when something fails during the call). If you call ‘.each’ within the second function without verifying that the variable is iterable first the function will throw. (I’ve even seen a couple rare cases where a custom class responds to ‘.each’ but is not properly iterable). Most Ruby devs will “just” check before they call ‘.each’, or wrap the second call in a rescue block, but that’s exactly the sort of potential for misstep I’m talking about.
  - jack_riminton 3y ago
    Interesting. I wonder if these came about from engineers just trying to be too clever. The thing I really love about rails is the focus on creating nice boring conventional code. I think the current mania for types has arisen largely out of the js SPA crowd creating problems for themselves doing the opposite,