[dolni]

Framework-style libraries (i.e. Hanami) pulling in other framework-style libraries (i.e. dry-rb) which themselves pull in other framework-style libraries (i.e. Zeitwerk) is asking for a whole lot of trouble.

If your app uses Hanami and Zeitwerk, for example, breaking changes in Zeitwerk may REQUIRE you to update Zeitwerk before you can upgrade Hanami. Or, if dry-rb hasn't adopted the new version of Zeitwerk, you may be stuck on an old version of Zeitwerk, unable to update it. Depending on the nature of the breaking changes, working through this stuff could be a lot of work for a mature app.

Maybe the maintainers are nice and release patch versions for older major releases. I don't know. What I do know is that either way, there is likely to be a lot of maintenance burden somewhere unless these libraries have high stability guarantees.

I don't understand the Rubyist obsession with having a whole bunch of magic stuff just "happen" in your code. Magic is fine if the scope is narrow and well-defined. Ruby magic is often _entire app magic_, which means that it is hard to approach (because you need to understand how it works in many contexts). If that magic ever changes, there are a lot more places where it can break stuff.

[solnic]

You're right in principle but not in this case. Zeitwerk is not a regular dependency, it's stable and the risk it will change in an incompatible way is very minimal (reminder - it's used by Rails too). When it comes to dry-rb as deps - dry-rb core team == hanami core team. This means we are on top of the things and we'll ensure that things are evolving together w/o breaking anything.

[larksimian]

This is the sort of cargo-culty FUD criticism people often bring up about Rails. So many programmers would rather reinvent the wheel, badly, than learn how to use existing products and focusing on their USPs.

What would your successor prefer when they take over: Bob's ad-hoc framework built from the ground up where they don't know how anything works, or some app implemented on top of a framework they've used in 10 other jobs?

While I agree that using frameworks like rails/django/hanami/react has an upfront cost, it's so hard to justify doing your own thing if your usecase is fits within what they offer.

[hanamimastery]

Hanami 2.0 is almost completely rewrite in it's core from 1.3, and it took over 3 years. I could not imagine companies relying on owned frameworks - maintaining it, documenting it, educating people to work with them - it's just too expensive.

[digitaltrees]

The ruby community is able to do it by having a rigorous set of defaults. When you look at the ecosystem there is far more inter compatibility than say JavaScript/ npm because there are robust norms.

The obsession with magic is actually more an obsession on developer speed and ease because that is the biggest cost and driver of software. The magic also promotes following well tested patterns.

You seem to be advocating a dependency free path where the developer builds everything from scratch. Totally a valid approach but at the cost of development speed and ease. It also results loss of the collective knowledge of a community.