Hacker News new | past | comments | ask | show | jobs | submit login

My guess is that you'll see people who were hitting the limitations of Go end up moving to Phoenix. For Rails users coming to it there are still too many "library x for Phoenix" questions out there.

Elixir is great but it's still not ruby. Much like Go, it's not something you can fully appreciate until you've seen the limitations of other approaches first hand. There are so many things that Phoenix and Elixir do that solve major long term problems and ruby's biggest selling point is usually the short term.




I've been developing for Rails since around the 1.2 days. For me, ActionCable seems to excite a lot of Rails developers, but it's no Elixir.

2015 is a watershed year for the Elixir ecosystem. It was like this back in the Rails 1.2 days. Back then, people said the same thing about Ruby. "Ruby is great, but it's still not X."

The idea that Rails is very fast for doing quick development is, at this point, a myth. It takes thoughtfulness to write good code, regardless of the language. There's this idea that you can put together a prototype quickly, but in the wild, it ends up being a repository of sloppy code resulting from fuzzy, superficial thinking.

Another situation I have seen is this the "perpetual MVP". That is, sacrificing code quality because you don't know if the product is even something that people want. However, when your MVP has users and it starts getting traction, it's not an MVP anymore. The fragility that comes from sloppy coding comes back to bite you. I think developers confuse Ruby's agility with their own sloppiness.

I think Elixir is interesting not just because it solves those long term problems, but it is also as agile in the short term -- provided that you are not a sloppy coder.


I can't disagree with any of that. The biggest thing around prototyping for Rails at least is how close it comes to aspect oriented program thanks to the ability to pull in libraries that inject themselves across multiple points of your application, like Devise for example.

That and the ability to monkey patch something from a 3rd party library without breaking your upgrade path, having to fork it or needing to adjust the entire inheritance chain. It's not good practice to do too much but knowing you can make using all those gems a lot easier.


This is my main issue with Rails; this feeling that every project that I'm working on is a rolling protptype. It's so, so easy to build out the initial functionality, then it becomes a slog, and I guess that's very much down to how monolithic Rails is


"you'll see people who were hitting the limitations of Go end up moving to Phoenix"

This is oranges and apples. First, you're comparing a language to a framework. Second, use cases for these two barely overlap. I'm a huge fan of Go and I started using Phoenix for web development and I can't really think of a scenario where I'd have to think which one to choose for a particular job.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: