If you're doing stuff with OpenAPI (as I've been doing over the last few weeks), it becomes a pressing thing. =( Generated clients usually are pretty awful, you usually have to generate your own (because they don't publish gems when their APIs change, which is why I've written online-generated ones!), and once you've completed the bootstrap process for an HTTP client, it's as fast as any other Ruby thing. Which is not the fastest out there by a long shot--though JRuby helps--but is Fast Enough for most stuff.

I'm also not sure Crystal can implement an active record pattern off of a database? (Though I am not personally the type to go with that, I prefer row mappers.)

See GraniteORM or my crystal-mongo-orm. You just have to specify your fields at compile time and you are good-to-go. It works just like active record.

https://github.com/amberframework/granite-orm https://github.com/sam0x17/crystal-mongo-orm

"You have to specify your fields at compile time" is exactly not like ActiveRecord, though. That's exactly the downside to it for doing ActiveRecord.

At that point, you may (should) just use an object mapper like ROM that has no model-class hooks at all. (Which I actually like. But the Rails world disagrees.)

You effectively do specify your fields before runtime in Rails, though, in the form of your migrations. Furthermore all of the associations (belongs_to, etc), are arguably also specified before runtime since those helpers run when the class is parsed.

I frequently don't use Ruby-based migrations. I use datastores defined elsewhere and use Sequel as a convenient and easy interface for tasks against those datastores.

You're trying to slice too fine. Crystal can't do this. That's OK. Own it, don't try to hide it.

If the problem is stated as you want a dynamic class to create instances where you call dynamic methods, then yes you need Ruby.

However, that is basically a lookup table using string based dispatch to decide what to execute, and such a lookup table can be done in anything.

Crystal "does" have dynamic methods if you are willing to override method_missing.

No, the dispatch is still decided during compilation.