Ruby and Elixir do have surface syntax in common, and Rails and Phoenix are clearly from the same conceptual direction. They're more similar than, say, Rails and Spring Boot.
This is not surprising: the Elixir folks were fairly high-visibility in the Ruby community before they did Elixir and Phoenix.
I'll give you surface syntax in common, other than that not much. I think a Rails dev would have a much easier time picking up Django or Laravel than Phoenix. How hard is the switch from Rails to Django? Probably trivial. But Ruby to Elixir is a mind shift.
Ruby to Elixir is a mind shift. Rails to Phoenix...I don't think so.
But most Rails programmers write Rails, not Ruby, and it's important to differentiate them. Ruby is a big playground. Rails is...not, by design. (This is why I do not like Rails, personally--if I am choosing to write code in Ruby, it's because I expect to need to get weird with it.)
Rails->Phoenix omits a lot of the stuff that makes Elixir cool, both in itself and in OTP, but that's not a bad thing and I do think the transfer isn't too onerous for somebody coming purely from Rails.
I'm really not. I've built tools and systems around Rails for a long time. Most Rails programmers I've worked with live in the controller and the view. Absolutely there are those who do not--and they're often building libraries and tooling for those who do. IME, at the hireable junior/mid levels, Rails driving is pretty tightly coupled to the framework--this is often a positive, to be clear, and not a dunk on anybody. This is the baseline way to get a web application out the door.
Roughly equivalent interfaces exist in Phoenix, and the mapping isn't quite 1:1 but it's close enough that the adjustment is an adjustment, I think, and not a re-learning.
I partly agree with what you're saying but still - you're exaggerating. Doing Rails without a decent knowledge in Ruby is exactly what you said - it's being a junior. You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry. That's what being a junior is like in any language.
I don't think we can compare languages based solely on the experience of juniors. I'm not saying it's irrelevant, it is, but it's only a part of what writing software is. In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction.
But I do agree that Rails is a kind of dialect of Ruby and that you can get pretty far with Rails without being great in Ruby (you still need to be decent though, no way of getting around that).
> Most Rails programmers I've worked with live in the controller and the view
Where is the business logic at? They also write services or something similar or stick it in the Model. Whatever isn't ActiveRecord will be pure Ruby - Rails has no opinions there.
> You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry.
Absolutely, and I would submit that this is most developers' experience up until a senior-ish role. Not title, you can have juniors doing this, but the pyramid of tool-users versus tool-makers.
> In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction.
Again agreed--but jeez, there are just so many fewer tool-makers at most places I've found myself. (This worked out great for me early in my career because there were tons of vacuums to start doing that work even in my first year out of college--building systems that other people could rely on to go faster, because nobody else was doing it!) Thinking about it, this impression perhaps sticks more because of the businesses I consulted for, which is perhaps where my perspective comes from--hiring uncritically 'til you're in a pit where you're paying the medium bucks to get somebody to come dig you out.
> Where is the business logic at? They also write services or something similar or stick it in the Model.
Found the guy who hasn't seen too many 10KLOC controllers in his time out there. ;)
You may be right that I am grim about this, but at the same time, reading your description makes me go "I haven't seen too many places that actually do-it-right". The truth's probably somewhere in the middle, and outliers exist on both sides. But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of. They make a lot of money, too. (Fortunately for me, they brought me in for devops stuff, not "please save our megamonolith".)
> But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of.
I don't get why this is still happening. It's kinda common wisdom now to not let your controllers get fat. I"m not saying that fat models are great but as a community we kinda agree that most business logic stuff is easier tested on the model/service and should be placed there.
CTO's/team leaders have to be real sloppy to let teams build code as you describe At the same time - being a consultant, don't you more often than not see codebases in bad state? I mean those are the ones that usually need consulting. So maybe you have an overly negative view on how Rails projects usually look.
> Rails->Phoenix omits a lot of the stuff that makes Elixir cool, both in itself and in OTP, but that's not a bad thing and I do think the transfer isn't too onerous for somebody coming purely from Rails.
I'm not following you here. Could you please explain your position a bit more?
The reason I'm confused by your commentary is that Phoenix makes extensive use of OTP and since it is just Elixir + macros, there is nothing at all limiting you from employing every Elixir (and Erlang, for that matter) feature you want to in your Phoenix apps.
Sorry - omits is the wrong word, because of course Phoenix uses that stuff. More that in my experience, for the kind of "in the framework" developer that I've run into in the Rails space, the mapping to using Phoenix is very simple and doesn't demand of the end user the conscious use of processes, genservers, etc. -- it can, and from POV often seems to be used as, plug-and-chug. This totally isn't a criticism either, I want to stress; it's the mark of a good framework, that you don't necessarily have to care about that stuff to ship a thing.
At my current company, we use Phoenix and we use a lot of its bells and whistles. But we also have a lot of people who understand OTP--definitely way more than I do. I also see people ship Phoenix apps without getting deep into that when their needs are relatively small.
> Rails->Phoenix omits a lot of the stuff that makes Elixir cool, both in itself and in OTP
How do you think Phoenix could better take advantage of Elixir and OTP? IMO, it already is doing plenty to take advantage of what's cool about OTP, through channels and especially LiveView. I suppose Phoenix apps could use Mnesia instead of relational databases. But would the benefits actually outweigh the costs?
I have extensive experience with Elixir/Phoenix, Ruby on Rails, Laravel, and Django and I have to say I disagree. Rails and Phoenix are both opinionated in similar ways, both have similar generators, both have excellent/similar tooling, and many of the same ideas exist in both (e.g., Channels and Action Cable). I view Elixir/Phoenix as a natural evolution of Ruby/Rails.
This is not surprising: the Elixir folks were fairly high-visibility in the Ruby community before they did Elixir and Phoenix.