> What's great about Rails ? Serious question from someone who landed into a mature Rails app and is now decidedly running away from that ecosystem after a year working in it.
Rails provides a mature system to quickly "get the job done" in a way that can be easily maintained and generally "just works". It's especially good if you want to have a small team manage an application. More details below.
> Rails looks like an early take on MVC that was setup around fast project creation and encourages unmaintainable code - concerns are straight out retarded (a design pattern that encourages breaking encapsulation and makes dependencies impossible to trace) and fat models encourage coupling things that don't need to be coupled.
That hasn't been my experience. Used well, Rails code tends to be relatively easy to follow. It's true that concerns can be easily overused. But that's true of many power tools; I use concerns sparingly, and then they work just fine.
> Then there's Ruby which in my opinion goes against Zen of Python which I'm a fan of - aliases all over the place for same thing, pointless name shortening and stuff to sacrifice readability, rails breaking conventions of standard library...
This is an odd argument. I know both Ruby and Python. No, Ruby doesn't follow Python conventions. That's because Ruby is not Python. The shortening can in some places increase readability; YMMV.
Rails does extend the standard library in a few ways, but if you're using Rails, that's already baked in & you never see it otherwise. So again, that seems irrelevant. If you're using Rails... then you're using Rails.
> These days I'd take Python as a more popular language, that I would say is better designed and has far better Windows support.
Python & Ruby are similar in many ways, it's hard to argue one is objectively far "better".
I've heard from others that Rails runs great on Windows 10, just use Windows Subsystem for Linux (WSL). I don't know how well Rails runs on native Windows. I know at one time that was important for many people. But for many people today, "run on native Windows" is irrelevant. The web application that I maintain that uses Rails runs on a Linux system, and while it would probably work on any Unix-like system, there's no interest in getting it to run on native Windows. Why do that? There's absolutely no justification for ever running that application on Windows, it would just cost more & crash more. If I want to run it on Windows for debugging, VirtualBox is great. Windows is disappearing completely from many server-side environments. Even Microsoft's own Azure runs Linux more than Windows: https://www.zdnet.com/article/microsoft-developer-reveals-li...
> NPM/TypeScript and structural static typing is getting really good as well but is not as mature - but code sharing between client and server is a real thing.
In many situations the sharing is so minimal as to be not worth it. I've only found a single function that would make sense on both client & server, and it was trivially implemented twice. That's not, by itself, a reason to force both sides to be the same language.
In many applications, "not as mature" means "don't use it". I don't have time to waste debugging someone else's framework, especially when I'm implementing a relatively straightforward CRUD application. I'll gladly use an immature system if it provides a vital capability unavailable elsewhere, but for simple CRUD applications that's absurd. I loathe fad-based engineering.
> I don't really see where Rails is great compared to alternatives, it feels like legacy at this point. I'm not saying you can't write good maintainable apps in Rails either - I'm just saying other frameworks and languages will make it easier IMO.
I think the main advantages of Rails are that it is:
- mature - a lot of work has been spent to make sure the "special cases" work, and a large amount of functionality is there for immediate use. Like anything it has bugs & missing functions, but in general, if it's a common need it's easily available, easily works, and rarely has bugs.
- integrated - while Rails is implemented as a set of libraries, they're conceived as a whole, so there's no effort to "make the parts work together" - they already work together.
- simplifies & speeds development by making a lot of convention decisions for you, via "convention over configuration". For example, database tables use snake_case with plural names; model class names use CamelCase and are singular. Yes, Rails automatically does the singular/plural conversion! The conventions eliminates arguing & deciding conventions, doing the work to configure it, and makes the code more regular, but it's more painful if you hate their conventions & want to override them all.
Of course, there are many worthy alternatives. Rails isn't the be-all (what is?). But Rails is still a fine choice for many applications today; GitHub and GitLab are both Rails applications. E.g.: https://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to...
The biggest problem with Rails is that Ruby, like Python, is an extremely slow language. In most applications this is irrelevant; the correct way to speed things up is to cache things, and then it really isn't a problem. Rails comes with a very easy-to-use caching system. So folks, like GitLab, have found that they can identify just the hotspot & reimplement just that small part. The same happens with Python, by the way; if you want fast Python, you either call "Python" code that's actually written in C, or rewrite your hotspot Python code into C. There's no such thing as a free lunch.
In particular, Rails has a large set of conventions. If you're willing to accept those conventions, a lot is done automatically for you. If you will continuously fight the conventions, then it's going to be a pain to work with.