I would imagine one reason for this is because the real complexity of a project has nothing todo with the programming. It has to do with evolving the business. Were on our 3rd re-write of our business, but the codebase still has legacy systems from the first two drafts. No language can save you from that.

I love it when people make a mess because they didn't really understand the problem initially, then rewrite it in something else and give all credit to the new technology they happened to be using.

When you rewrite a project it's always going to be a lot better, because you have a much better understanding of the problem being solved having done that once already.

Indeed, on anything serious I write it at least twice. Of course, using Clojure makes this easy since there is usually not a lot of code to rewrite. But after you get into something, you know details about what is needed that you simply cannot adequately predict beforehand in a lot of circumstances.

True, but only with small projects. Once initial creators of rather complex project leave then the mess begins. No language will save you from changing requirements, egos or best practices. Will your rewrite of inherited 200KLOC "is always going to be a lot better"?

My thoughts exactly.

There are many ways to use Clojure, the laziest one of course being the least maintainable. No language can subsitute engineering principles, years of experience, empathy etc.

I wrote a few hints of what I consider maintainable here -> https://blog.vemv.net/maintainable-clojure-beyond-aesthetics...

>Rails project has less functions, and with a far more predictable structure.

This is probably true if your building a very very generic small webapp. In which case, maybe use rails if it's the stack your good at.

However, as the complexity of the system grows, the less will easily fit in mvc. When that happens, pushing all the complexity into mvc will make it harder to understand, not easier.

You can do anything you want with rails. You’re not coupled to mvc. At the end of the day it’s a rack app and it’s ruby. Go wild.

You are coupled to mvc, that's the upside to a framework.

That is not true at all. You have Rails at your disposal but if you want to break free of that and use simple ruby classes and handle request/response on your own -- you are very much free to do that.

Perfect example is running Sinatra inside of Rails: https://jacobbednarz.com/posts/sinatra-in-rails

Again: ultimately you have a Rack (ruby, https://rack.github.io) webserver interface that has a Rails app mounted inside of it.

"Rails" is just some code that is running. You can choose to defeat certain parts of it, mount other stuff on the Rack server, turn rails off entirely and just use Activerecord, etc...

I do it all the time.

Sure, I wasn't defending Rails as a generally better solution.

The quoted statement tends to be true regardless!