The One-Person Framework in Practice

Yes, like I said before, Phoenix 1.0 predates the first open-source and Linux-supported .NET release by a year.

https://news.ycombinator.com/item?id=10135825

https://github.com/dotnet/core/blob/main/release-notes%2F1.0...

People aren't just going to jump onto something recently open-sourced by a company that popularized the phrase "embrace, extend, extinguish". For the last decade, they've had to earn people's goodwill, while with a project like Rails, there is no "we used to be closed source but now we're not, use our thing!" to overcome. So in the 20 years since Rails has been released, it has only ever needed to demonstrate its usefulness.

Now that a decade has past, that negative association is starting to wash away a little.

I have heard that for years and I just don't get it. Magic abounds. The test assertions and testing libraries are whole DSLs that require a separate/additional learning process with inconsistent chaining with inconsistent return types. Being able to overwrite anything in the language gives rise to things like unicode whitespace being misinterpreted as an undefined function. You can define methods by combining method names leading to wholly undiscoverable methods because "my_func_that_is_cool" is actually defined over multiple files, combining my_func and that_is_cool; saw this a lot in our chef cookbooks. Ruby requires mountains of tests (thus the DSLs). Knowing ruby and knowing rails and knowing how to test are different things.

I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.

I assert Go leads to org happiness, letting teams work together productively.

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.

Meteor.js offers pretty good iteration speeds and a fairly complete toolbox for the JS world. Fully featured accounts system, RPCs, client/server reactivity, etc.

I'd need the opinion of someone who's worked with other acclaimed technologies (his was PHP) to tell me that Rails is indeed that much better