Embed Crystal code directly in Ruby

> ruby seems to embrace the monkeypatch

How recent were your experiences with this? In recent years I've seen monkeypatching treated as more of an antipattern. If you are on a project where people are doing that without very good reasons, that says more about the team than the language.

I think that’s a misconception of people who don’t understand the underlying language/framework (yet).

How much magic is really going on, especially compared to for example JPA/Hiberbate, or any of the aspect orient projects?

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.

Conceptually, isn’t that what a JIT compiler does?

Crystalruby ia really interesting though. This has got me wondering:

1. How this compares to Sorbet Compiler in terms of performance?

2. If you could use Sorbet or RBS type annotations to drive crystalruby?

3. How would YJIT perform if it was fed with type annotations?

4. Could crystalruby type signatures be used by Sorbet-lsp, ruby-lsp, etc in to improve developer experience?

I really wish we had a single standard for inline types in ruby. I wish that was an inline RBS type annotation but I guess I’d take anything that works.

> You won't ever see fast compilation times with it, and here's why:

> > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1]

There are fast type inference implementations. For example, the OCaml compiler is pretty fast

No reason Crystal couldn't improve this part of compile time in future