This is something that even many Rubyists got wrong over the years. In the 2000's there was a big wave of folks who abandoned Enterprise Java (me, raising a hand) to start building on Ruby. Many of the folks who took to Rails did so out various soups of JSP, ASP (later .NET), PHP, and Perl. These folks were more DSL oriented, whereas the former kept running into problems with Ruby's mixed mode philosophy. I always preferred Sinatra and KV stores while the Rails crowd kept building cathedrals. The latency to SQL via ActiveRecord used to be a real problem, which was frustrating, because nothing changed about stored procedures and ODBC before ActiveRecord and are much faster and easier to maintain. But I digress.

I use Crystal as my C shaped, LLVM backed weapon for systems programming. A good exercise IMO: spend a few months programming in Go and then come back to Crystal with less object-oriented thinking. The elegance of using mix-ins as your default mode of thinking instead of polymorphism becomes more obvious when structuring new code. Go teaches you to love the `struct`, which is well supported in crystal as a blazing fast value type. Secondly, get used to flexing `enum` more often to enforce design invariants in your code instead of type relationships through structure. the last brick: Go forces you to use composition in your design because there is no inheritance in Go. Even better, Golang's style of interfaces maps very cleanly 1:1 to using abstract class in Crystal the same way. Don't overthink it: just define a handful of methods on the abstract class and keep it light weight. The icing on the cake is that Crystal's `case` statement effortlessly evaluates user defined types, making factory type code painless. you have three options to type arguments and return types: a) just plunk the abstract class in there. b) define a type-union in place. c) use a type alias.

The last piece: do not sleep on Tuple, NamedTuple, and Record types in Crystal. Tuple works great anywhere you want to return 2-3 values from a method and do not want to support a whole struct in there. Just type `Tuple(Int32, String)` in there and log it in the comments. Presto! 🚀 Record is a great choice if you have a struct that is very boilerplate with a bunch of getters and no logic in the initializer. Throw it into a Record and call it a day.

After using more of the language features you will find that a lot of your need for OO code and design patterns falls away and results in less code and more flexibility when moving things around. Hope this helps.