Comment by nona
First time I hear about this, I really like your guard approach. It's just quite plain ruby.
I'd be interested in hearing your opinions on other runtime approaches like contracts.ruby, literal.fun and LowType of course.
First time I hear about this, I really like your guard approach. It's just quite plain ruby.
I'd be interested in hearing your opinions on other runtime approaches like contracts.ruby, literal.fun and LowType of course.
Appreciate it.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
[1]: https://x.com/hakunin/status/1960016559750914097