what annoys me to no end with sorbet is that it subtly pushes to worse looking code, even if to ignore all the verbosity and annotations.
let's say there's a generic data transformation in a method which could be extracted to a private helper method. Sorbet didn't have any issue figuring types of the result while those lines were in the parent method. But when those three lines are extracted, sorbet now requires you to write a generic signature for that method, otherwise type checking is not working anymore. Generic signatures are even more verbose and hard to write than for methods with specific types.
So, a kneejerk reaction would be just not extract those, because it becomes too much work, and readability is not improved anymore, because signature for three lines of code is taking five lines. And that's until someone "clever" will add a rule to rubocop limiting all methods to a specific amount of lines indiscriminately, so I'd spend additional work time imagining that person being punched in a face.
In theory something like that could be solved by marking helper methods as inlined, basically promising that you're not going to use them in subclasses or whatever and allowing the same inference to work inside. But "sorbet is feature complete".
Sorbet is not feature complete, we are working on it every day!
I hear you on the verbosity of generic type declarations. It's something that I pushed hard for us to improve in the early phases of the project, but I was outvoted by other members of my team. But... at this point those members have all left the team and in the meantime we've heart actual users complain about the verbosity (not our own hypothetical "what if" complaints in the design phase) so I'm optimistic we'll be able to reduce generic type verbosity in the future. For example, a while back I did a prototype/experiment to drastically drop the verbosity of generic type annotations[1]. It's definitely on our radar.
Happy to chat more either on Sorbet's issue tracker or Slack group.
That's actually reassuring to hear, thank you. I'll take a look on recent changes in sorbet, I don't even remember where I've seen that "feature complete" remark, maybe I'm just imagined it.
I'd love and use sorbet if it'd be truly an optional typing, I'd happily supply signatures to public interfaces of my classes, but only to them, as a documentation and a somewhat verifiable helper to LSP. Basically, what RBS should be doing. In my experience I rarely if ever make type-like errors in the code I produce, so sorbet just added a lot of chore and forced to dumb down my code significantly, just to be ingestable by sorbet. And worse of all, it added some false sense of security, because absense of sorbet errors didn't mean absense of type mismatches in many cases. But maybe some of those concerns are gone already.
let's say there's a generic data transformation in a method which could be extracted to a private helper method. Sorbet didn't have any issue figuring types of the result while those lines were in the parent method. But when those three lines are extracted, sorbet now requires you to write a generic signature for that method, otherwise type checking is not working anymore. Generic signatures are even more verbose and hard to write than for methods with specific types.
So, a kneejerk reaction would be just not extract those, because it becomes too much work, and readability is not improved anymore, because signature for three lines of code is taking five lines. And that's until someone "clever" will add a rule to rubocop limiting all methods to a specific amount of lines indiscriminately, so I'd spend additional work time imagining that person being punched in a face.
In theory something like that could be solved by marking helper methods as inlined, basically promising that you're not going to use them in subclasses or whatever and allowing the same inference to work inside. But "sorbet is feature complete".