Hacker News new | ask | show | jobs
by sethammons 409 days ago
In each of the dynamic frameworks I have worked in, besides lacking types, the biggest problem is domain separation.

In 4 out of six large, dynamic code bases I have worked in, everything becomes spaghetti. This joins with that which n+1s with yadda yadda. You end up with dependencies that prevent billing options because you can't separate the billing structure from the user model from the product table. Queries start joining and joining and you get monstrosities of queries. The beefy postgres db gets bogged down at less than 2k rps. Everything gets slower. Then the org spends millions and millions on domain separation and breaking teams away from another. Builds get slower. Competing styles of decomposition litter the codebase. Changes take days to release. It takes Herculean effort and heroics to fix a dynamic code bases that grows, eating at growth when it should be compounding.

"But it let us get here, where we can afford to do those changes." Maybe. It is the road less taken's point - you can sell yourself that the dynamic code bases allowed for the success. But that doesn't say the alternative wouldn't work.

</insomnia thoughts>

2 comments

Ugh, the billing thing hits hard. Just know that having types doesn't prevent this issue. The current codebase I'm working on has a tightly coupled billing model with the incoming requests. Someone thought it was a great idea to mix http status codes with billable events in the same table.
This rings true, but I also saw a lot of situations where just as spaghetti was being tangled, the few folks who resisted it were overruled, again and again.

This is hardly the property of languages or frameworks - just orgs being orgs and incentives being incentives. I don't see why a codebase in a compiled lang would not have queries that "start joining and joining and you get monstrosities of queries" if the business logic demands that queriage to be queriaged?.. Maybe you could make a case to the business that the speed of rework has to be reduced "because static lang and we do things properly here" - but the same can be done with dynamic langs, just with a bit of rigor.