Of course, because that’s really what matters. If you start to change the defaults, you can If you want to, end up with something that does not even need given framework at all.
You don’t choose given framework to change how half of it does work, because at this point it actually might have been easier to start from scratch or just use some other tool/framework.
The problem I have with Rails is that it has it’s conventions, and does very much magic to make those conventions work. Most of things are very implicit, and if you really want to change those defaults, framework works against you and not for you.
That’s true. But the more complex business logic gets the harder is to write something sane in rails.
And when it comes to FormObjects, Presenters, ServiceObjects i have a problem with them… but the problem is with glorification of those “patterns”, I think it should be rather clear that when you separate concerns you have specialized objects (classes?) that represent specialized needs. After all you don’t want a model that’s responsible for keeping data in memory, and it’s transformation taking care of the data validation, and about how to persist the data between sessions. Right? But that’s what Rails, and most of Rails tutorials teach you, to bloat you classes so they’re responsible for way too many things. Well I could go on an on… **
But What I really want to say is that Rails are tailored to very specific needs of Basecamp, and they are really easy to write something in it, as long as you follow all conventions. But when the app starts to get complex Rails does not try to help you in any way, and often stays in your way. And because Rails are so popular, and they are not trying to teach about concepts like separation of concerns, as a young developer who learned Rails you may have hard time accepting the fact that the Rails Bloated Classes Way is not the only way, and certainly not the best way.
And sorry for ranting, I just dislike Rails very much, I think because it’s magic and being very implicit.
And answering question in topic. Is Elixir / Phoenix ready for production? Lately I started prototyping new functionalities for a Dajngo app in Elixir and then converting it to Django. And to be honest it’s much easier to write fully working prototype in Elixir/Phoenix than write similar functionality in Python/Django, even tho I’ve been working with Python for almost 10 years already.
__
** It’s also nothing personal, when I started coding I didn’t know that separation of concerns, and clear internal APIs are need to keep applications sane. But so far in my career Phoenix is the first “framework” that takes teaching it from start to any level, beside maybe Django and it’s “applications”.