After reading “Rails is yesterday’s software”, I need to reply

I'm sure it helps, but you still have a runtime dependency on Ruby as well as something to unbundle the bundle. Maybe this isn't a big deal, but it's not as easy as a single static binary.

> Winning this war has as much to do with culture and marketing as algorithms and data structures.

This is true enough. I'd go farther and say that winning depends almost entirely on culture and marketing. The annals of computing are littered with the forgotten remains of technically amazing projects that suffered from poor or non-existent marketing execution. Rails is so popular mainly due to marketing tactics that won developer mindshare, rather than due to any technical merit.

The larger question is not a mutually exclusive either-or situation. A good framework should be easy to use for the most common cases initially and well thought out enough that it's easily extensible in the future.

When Rails first came out, I loved it. It made common stuff easy! Sure, it became intractable if you needed to deviate in any way from the planned normal cases, but that was fine for now. I thought it was a great V1 of the Ultimate Web Framework, and in time they'd build it out to have better and more flexible extensibility. I thought it was fine starting point to build upon, and that eventually they'd redo and flesh out the various badly designed subsystems.

As the years went by, I realized that it was not a V1 of that mythical Ultimate Web Framework. Not at all.

Its developers were quite content to feed on the low end of the market that just needed a quick way to shuttle data between a database and web forms. They had no intentions of updating its design to accomodate any other use cases. The few concessions that were made to other use cases were generally bolt-on hacks rather than integrated elements of the framework. They were focusing their time on flying around the world giving talks at conferences, writing books, giving training seminars, and otherwise monetizing their brand.

Actual engineering work on Rails itself slowed to a near-halt, and it was then usually reactive in the sense that Rails had to be dragged forward kicking and screaming. Rails was no longer an innovator, but that was fine because they were making plenty of cash off of what Rails was. Indeed, they now had a strong disincentive to make any radical design changes, since they would have to redo all of their books and course curricula around the new design.

There is no reason in principle why one couldn't build a framework that's both easy to get started with and easy to extend. It's just that nobody's bothered to do it yet.

For me personally, one of the coolest features of Phoenix is that it natively supports concurrency. Communicating with a front-end via websockets is really easy to do with Phoenix, whereas in Rails it's basically unheard of. I know that Rails 5 is going to introduce ActionCable and that it's possible to write event-based apps with EventMachine, but these are ultimately poor solutions compared to what's capable in languages that take concurrency seriously (like Elixir).

No, I realize that. I was thinking more about complaints along those lines in general rather than anything you said specifically. Maybe it's just a case of setting unreasonable expectations as a consequence of how Rails in particular is recommended to newbies.

> That expressiveness can often come at the expense of accessibility/readability, and IMHO that's the case with Scala.

I don't think there's inherently a tradeoff. E.g. in Python you have to write "(lambda x: x + 1)" where in Scala you can write "(_ + 1)"; I think the latter is both more expressive and more readable, because naming "x" isn't adding any clarity for the reader, it's just ceremony that you have to skip over when reading. Similarly Python's verbose, repetitive constructors don't clarify anything (worse, they obscure the rare cases where your constructor does something different from "self.x = x; self.y = y; ...", making it too easy for a reader to be surprised/confused by those cases).

> A lot of the popularity of Go comes from its explicit lack of expressiveness. I barely use the language, but the one thing I remember most from my time learning it is that I could easily understand every Go source file I found. From Hello, World! all the way up to distributed applications/libraries, Go code was long/verbose, but explicit and easy to understand.

I think people overestimate the importance of understanding a line in isolation and underestimate the importance of understanding a whole component or system. A one-screen class where you have to spend a couple of seconds understanding each line feels harder to read than a three-screen class where each line is simple, but (IME) ends up being more maintainable.

> Meanwhile, I've never found Scala code to be very readable. It almost requires that the code be written with the same coding conventions that you're accustomed to using. Even when common conventions are used, we found Scala to be counterproductive in larger teams.

All I can say is that's not my experience.

> Code reviews were significantly less thorough for Scala projects than either Java or Node projects were.

I don't follow. Surely if people find it harder to read they should codereview more carefully (or simply reject on grounds of unreadability)? That's what reviews are for, no?