I have loosely followed Hanami for years but never used it or heard of it used in a large codebase.

I still don't quite understand what it does all that differently from Rails? There are plenty of comments that are along the lines of > "Hanami brings is an intentional and well-reasoned architecture that supports building maintainable applications. It has taste" (posted below)

But concretely what does that mean? Their docs call out ways to avoid common rails anti-patterns and I agree with most of their opinions but you don't _have_ to write bad code in rails just because a lot of others have.

Having seen Rails deprecations at multiple large well known tech cos I appreciate the sentiment of an "architecture that grows with you" but I would say the driver behind those migrations wasn't so much the framework as the extreme flexibility of the code and what that produces with thousands of developers over 10+ years.

I don't see how any architecture of Hanami prevents that.

many years ago when Hanami was just getting popular I remember doing benchmarks against Rails when it comes to SQL and was unpleasantly surprised when Rails' ActiveRecord ended up being much faster, despite "speed" being advertised as one of the advantages :-(

Hanami is quite nice. I haven’t had the opportunity to use it in anger but I have had a crush on it for a while now.

I really do hope ROM-rb, the not-orm Hanami uses, gets some development love as a consequence of this more formal merger. It’s a rad tool with enough rough edges that I had to switch away from it when launching a product a few years ago.

I'm happy someone's challenging the Rails almost-monoculture in the Ruby ecosystem, but Hanami doesn't seem to bring much to the table. Is there anything in this release that Rails hasn't had for years?

It'd be nice to see some benchmarks to compare the before vs after on the perf gains in the Faster by default heading.

Love the work though; having beautifully crafted options like Hanami around is a joy.