4 ms·

I too have stopped using Rails. To other Rails refugees, I highly recommend the up-and-coming Phoenix Framework for the Elixir language: http://www.phoenixframe

by clessg 10y ago

I too have stopped using Rails. To other Rails refugees, I highly recommend the up-and-coming Phoenix Framework for the Elixir language: http://www.phoenixframework.org/ http://www.phoenixframework.org/. Simple as in simple, fast, productive, beautiful Ruby-like syntax. Favors a functional and immutable workflow over object-oriented and mutable spaghetti code.

jmcgough 10y ago
Spun up my first Phoenix toy project 6 months ago and fell in love. You can really tell that a number of the core contributors are/were rails contributors, it carries over a lot of its strengths and tries to learn from its failings. Could really see Phoenix replacing Rails some day.
- sotojuan 10y ago
  The creator of Elixir is in the Rails core team and helped (wrote?) write Rack. The creator of Phoenix built Rails apps for quite a while before finding Elixir—their experience definitely helps because they take what is good about Rails but know which "pain points" to improve on.
marvel_boy 10y ago
Elixir/Phoenix is the way. Just try it, it's awesome.
danenania 10y ago
How's the community and library ecosystem looking in Elixir/Phoenix? It sounds great in principle. I'd love to move from Rails toward something more functionally-inspired, but I worry that lack of libraries and google results is going to be a net productivity killer over the Rails + evolving into micro-services approach.
- vvanders 10y ago
  Community: Very good, both Jose and Chris are outstanding examples of how you run a community. Can't comment extensively on the library ecosystem but you have access to everything from Erlang via trivial interop.
- brightball 10y ago
  https://github.com/h4cc/awesome-elixir https://github.com/h4cc/awesome-elixir
  - danenania 10y ago
    Thanks! Great list.
ocean3 10y ago
I have not stopped using rails. Its mature and works well. But i love elixir and i think phoenix is the future rails.
pjungwir 10y ago
I've been trying out Phoenix, and it seems like the top contender for a Rails successor. It's not quite as fluent as Rails, but it's close. But I'm curious: since it is so much like Rails, won't it suffer from all the same complaints as in the article? It is still a monolithic, "Phoenix is your app" kind of framework, isn't it? Isn't the Devise-but-for-Phoenix library going to require Ecto? I think of Phoenix as just "Rails but faster." How is it different from Rails in ways the article author would appreciate? (Edit: Btw I happily accept Rails' monolithic nature for all its conveniences, and I don't really identify with this author, but I'm curious to hear your opinion whether Phoenix would be a good fit for him.)
- clessg 10y ago
  I'm a bit short on time, but I'll try. Phoenix apps aren't actually monolithic, but I'll let the creator of Phoenix explain this himself (https://news.ycombinator.com/item?id=11749741 https://news.ycombinator.com/item?id=11749741): > A new phoenix application is not a monolith. The `phoenix.new` generator generates a regular Elixir application for you that sets up a default Endpoint worker in your supervision tree, as well as a web directory to put phoenix related files (routers, controllers, etc). wrt to collective process, we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do exactly what you are wanting. Building a Phoenix application is building an Elixir application, not the other way around. Your phoenix dependency and related workers are just one component to your larger Elixir/OTP infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App" talk, is on the Phoenix core team. We have been pushing these ideas since the beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking a stronger stance on isolation with upcoming changes to guides and phoenix resource generators. I think it's really quite a testament to Phoenix that so many people think it too is monolithic. A client can request a Phoenix application and I can get productive immediately without worrying about creating an unmaintainable, unperformant mess. No wasting 2 days on configuration hell. I can even jump into an existing project and be productive. Another point is that the libraries around Elixir aren't (in my experience) Phoenix-focused or obsessed with magical Phoenix integration. In most cases, things work well together. Just call functions. Monkey-patching, thread-unsafe operations, and uncontrolled shared global state are all non-problems in Phoenix. Decent code architecture and testability aren't usually a problem either because proper separation is enforced. Functional/immutable programming makes a huge difference here too. Ecto 2.0 is really what ActiveRecord should've been. It's incredibly well thought-out. I suspect the author would be really pleased with Ecto. Finally, Phoenix favors simplicity over ease in most cases. Complexity is not hidden in 100 layers of abstraction and callbacks. The author also mentioned DHH's... colorful personality. So I'll take this opportunity to mention how much more welcoming and humble Jose Valim and Chris McCord are.

by clessg 10y ago

jmcgough 10y ago

Spun up my first Phoenix toy project 6 months ago and fell in love. You can really tell that a number of the core contributors are/were rails contributors, it carries over a lot of its strengths and tries to learn from its failings. Could really see Phoenix replacing Rails some day.

sotojuan 10y ago
The creator of Elixir is in the Rails core team and helped (wrote?) write Rack. The creator of Phoenix built Rails apps for quite a while before finding Elixir—their experience definitely helps because they take what is good about Rails but know which "pain points" to improve on.

marvel_boy 10y ago

Elixir/Phoenix is the way. Just try it, it's awesome.

danenania 10y ago

How's the community and library ecosystem looking in Elixir/Phoenix? It sounds great in principle. I'd love to move from Rails toward something more functionally-inspired, but I worry that lack of libraries and google results is going to be a net productivity killer over the Rails + evolving into micro-services approach.

vvanders 10y ago
Community: Very good, both Jose and Chris are outstanding examples of how you run a community. Can't comment extensively on the library ecosystem but you have access to everything from Erlang via trivial interop.
brightball 10y ago
https://github.com/h4cc/awesome-elixir https://github.com/h4cc/awesome-elixir
- danenania 10y ago
  Thanks! Great list.

ocean3 10y ago

I have not stopped using rails. Its mature and works well. But i love elixir and i think phoenix is the future rails.

pjungwir 10y ago

I've been trying out Phoenix, and it seems like the top contender for a Rails successor. It's not quite as fluent as Rails, but it's close. But I'm curious: since it is so much like Rails, won't it suffer from all the same complaints as in the article? It is still a monolithic, "Phoenix is your app" kind of framework, isn't it? Isn't the Devise-but-for-Phoenix library going to require Ecto? I think of Phoenix as just "Rails but faster." How is it different from Rails in ways the article author would appreciate? (Edit: Btw I happily accept Rails' monolithic nature for all its conveniences, and I don't really identify with this author, but I'm curious to hear your opinion whether Phoenix would be a good fit for him.)

clessg 10y ago
I'm a bit short on time, but I'll try. Phoenix apps aren't actually monolithic, but I'll let the creator of Phoenix explain this himself (https://news.ycombinator.com/item?id=11749741 https://news.ycombinator.com/item?id=11749741): > A new phoenix application is not a monolith. The `phoenix.new` generator generates a regular Elixir application for you that sets up a default Endpoint worker in your supervision tree, as well as a web directory to put phoenix related files (routers, controllers, etc). wrt to collective process, we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do exactly what you are wanting. Building a Phoenix application is building an Elixir application, not the other way around. Your phoenix dependency and related workers are just one component to your larger Elixir/OTP infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App" talk, is on the Phoenix core team. We have been pushing these ideas since the beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking a stronger stance on isolation with upcoming changes to guides and phoenix resource generators. I think it's really quite a testament to Phoenix that so many people think it too is monolithic. A client can request a Phoenix application and I can get productive immediately without worrying about creating an unmaintainable, unperformant mess. No wasting 2 days on configuration hell. I can even jump into an existing project and be productive. Another point is that the libraries around Elixir aren't (in my experience) Phoenix-focused or obsessed with magical Phoenix integration. In most cases, things work well together. Just call functions. Monkey-patching, thread-unsafe operations, and uncontrolled shared global state are all non-problems in Phoenix. Decent code architecture and testability aren't usually a problem either because proper separation is enforced. Functional/immutable programming makes a huge difference here too. Ecto 2.0 is really what ActiveRecord should've been. It's incredibly well thought-out. I suspect the author would be really pleased with Ecto. Finally, Phoenix favors simplicity over ease in most cases. Complexity is not hidden in 100 layers of abstraction and callbacks. The author also mentioned DHH's... colorful personality. So I'll take this opportunity to mention how much more welcoming and humble Jose Valim and Chris McCord are.