I'll have to dig deeper into it to put together some sorbet.run code and identify which issues are the most serious. I'll share with the community group whenever I have things worth posting.
That said, in general, I often end up rewriting things a different way if something doesn't work, and the vast majority of the time that is good enough for me. But it takes time to find the one solution that doesn't create unacceptable bloat or complexity, and even then it is not as simple as I think it could be if there was another layer of polish to the Sorbet ergonomics (don't get me wrong, it's already in a good spot considering where Ruby was before that). Though someone actually complained to my boss that I spend too much time getting things working with Sorbet instead of "just shipping it", even though one of my main areas of responsibility is with architecture.
This is where having redundant features (multiple ways to accomplish the same thing) could be of some benefit, but I'll have to think about it some more with specifics. And I understand from looking through the repository that it's not an easy task to add features at all, so I'm thankful enough for what it is there as it has made my job much easier overall.
The main thing I struggle with regarding generics is the scenario where you must have separate type_template and type_member for class methods vs instance methods, and there are many use cases where these values are equal. But there is no way to tell sorbet that they are equal, requiring casts which makes the code less readable and often frustrating to write.
I also think that on a broader level, based on my searches, that the ruby community criticizes the idea of Sorbet for the reasons I mentioned in my previous comment. Adding more polish to the ergonomics, even when difficult or seemingly unreasonable, could do more for the branding of the project, which would lead to more community adoption, which would lead to better "just-works" type support with many common ruby libraries that are currently untyped. That could be a massive improvement to the status quo IMO. But it's hard to say because it could also end up not really moving the needle...
Appreciate all the work you've done! C++ isn't my strong point but someday I hope to find time to do a deep dive on the internals of the project.
> The main thing I struggle with regarding generics is the scenario where you must have separate type_template and type_member for class methods vs instance methods, and there are many use cases where these values are equal.
Makes sense, this is a big one for us too. For example, we'd like to do a better job of typing the T::Enum `serialize` and `deserialize` methods, but that's blocked on having a better mechanism for type_members that are equivalent to type_templates. I have done some prototypes to build this feature (you can find them in my draft PRs) but none of the solutions I arrived at were particularly satisfying. It's on our list to fix for sure.
> Adding more polish to the ergonomics [...] would lead to better "just-works" type support
People mean a lot of different things by this—I'd love to hear more about what kinds of ergonomic improvements would help. For example, some people say ergonomics to mean only tooling improvements, while others mean something else (e.g. type system improvements).
