I have two friends who both profession engineers that, like me, have been writing Rails code for the last 5+ years and are both quite proficient and passionate about Rails. Recently both started looking at and playing with http://www.phoenixframework.org/ - have you all seen this? Its claims are quite interesting to me with regard to performance - especially as I begin to use rails as more of just a backend system/api for clients.
There are always tradeoffs with any system / framework, and certainly the biggest one I see right now is that Phoenix lacks maturity and ecosystem of Rails. The gems that are available and community support (thanks @justin!) for Rails is amazing - but like Phoenix, Rails had to start somewhere.
So, if you check out Phoenix, I’d love to hear your thoughts, concerns, and/or dreams about it. I have yet to do any serious tire kicking there, but since the name keeps coming up, I thought I’d ask a group of other passionate rubists their thoughts. Thanks all!
I’ve gone through the guide/docs and built a little sample app, but it’s hard to see any benefit over Rails right now. Like you said, Rails is extremely mature and has a large ecosystem.
On a side note, semi-related, Elixir is pretty rad. I’m using it for small little microservices in tandem with a Rails project, though at my scale the performance is probably negligible.
I haven’t tried Phoenix yet. I keep hearing about it. For me, I still love Rails and I still think we can’t compare it with Rails because Rails is already 10+ years old. I feel it’s good way is playing with it in sample projects or side projects, so at least we could learn different programming paradigm and their strength in concurrency models.
I definitely agree with @samnang that exposing yourself to a lot of languages, assuming you also make an effort to follow that language’s conventions, is really beneficial. I was just reading an article the other day:
I can also place a safe bet on the programmer’s coding background based on certain patterns within the code that give subtle clues as to the coder’s previous programming experiences
Going from Java to Ruby, for example, was very eye-opening for me as it illustrated the large difference between using static typing with interfaces versus dynamic typing and skipping the interface part. Java forces you to think about and account for every possible way the program could error, while in Ruby you’re discouraged from doing that.
Same kind of thing goes for the more functional approach encouraged in JavaScript (although there seems to be tension here, such as whether to use pure functions or ES2015 class syntax for React components).
The more you expose yourself to other languages and paradigms, I believe, the more you prevent the “smell” of another language seeping into your code. The problem is, I need a good reason to be making an application and doing it the way I am. Finding a good enough justification to get you excited about exploring the new language (or framework, or paradigm), I think, is the real trick.