6 ms·

Rails 5 is a bloat too far for my liking as well. ActionCable's dependency on redis is too fat a pill to swallow, especially given that some of the existing Ac

Rails 5 is a bloat too far for my liking as well. ActionCable's dependency on redis is too fat a pill to swallow, especially given that some of the existing ActiveRecord backends have pub/sub capabilities. The result is that I'm learning Elixir/Phoenix and having the same reaction Dave Thomas describes in his new book, that is, finding anew the joy of programming.

mbrain 11y ago
Do you see a future in Elixer/Phoenix? And how do you like it?
- chippy 11y ago
  I often do a word count of languages and technologies in the monthly "Who's hiring" posts here. Elixir/Phoenix gets less mentions than Erlang - often there would be at least one position that says they use Elixir, sometimes none.
  - awinder 11y ago
    Small point: this is how all popular languages once started. Much like the stock market, there's value in being balanced on the forefront of a technology along with a solid footing in an established technology. Having no balance in either direction is the only "risky" career move.
  - davidw 11y ago
    I once ran a language popularity site thing, and I think jobs are something of a trailing indicator. It takes a while for people to hire for whatever hot new thing is out.
- Xixi 11y ago
  Another way to look at it is that Erlang has been there for a long time (longer than both Python and Ruby), and it is not going away soon. Elixir and Phoenix may or may not last, that I don't know, but they are a joy to work with.
- thibaut_barrere 11y ago
  I've beeen learning Elixir in the past few months and I can tell I'm definitely confident it's a good investment. Will use it fairly soon in production, first to implement ETL / streaming / batch processing of data (without Phoenix) then later for APIs (with Phoenix).
- hackercomplex 11y ago
  I'm much more excited about LFE personally. (http://lfe.io/ http://lfe.io/)
- cookiecaper 11y ago
  Now that the JavaScript trend is transitioning from "cool hipster language" to "a language that Wal-Mart uses", room is being made for a new language fad. Elixir/Phoenix seems like it may be a good candidate.
  - hackercomplex 11y ago
    Why not learn to use Erlang instead of trying to make Erlang "feel kind of like Ruby" ? As far as LFE goes.. implementing a LISP-1 on top of erlang seems like a perfectly reasonable thing to do, but why invent some new funky syntax (elixer) ?
    - piotrnowak 11y ago
      If you think Elixir is about syntax or about making Erlang look like Ruby, you should really watch this talk: https://www.youtube.com/watch?v=Lqo9-pQuRKE https://www.youtube.com/watch?v=Lqo9-pQuRKE Syntax is the first thing José Valim discards on the talk, he then goes on to talk about polymorphism, collections, tooling and so on. Also, both Elixir and LFE have two namespaces, so none of them would be equivalent to a LISP-1.
nemild 11y ago
In general, if "bloat" is an issue for you, I'd highly recommend languages/frameworks where the philosophy is more Unix-like. Rails has always been opinionated about less configuration at the risk of more bloat - and this has advantages for certain teams and certain projects. For example, Node/NPM/Express/etc. all have a philosophy the opposite of Rails bloat, but often require more configuration, and solid knowledge of the underlying middleware. The tradeoff between these two approaches is one many engineers need to make (e.g., the more recent Gulp vs WebPack has some similarities to this debate), and this is a common debate that will likely continue for years in the future. Pick whatever works best for your philosophy, your team, and the given project.
- laut 11y ago
  Phoenix also has little configuration - without being bloated. With Phoenix you do not have to make that trade-off.
  - gkop 11y ago
    Apples and oranges - Phoenix is too new to compare with Rails as far as bloat. I am optimistic Phoenix can do a great job of fighting bloat because of the community's learnings from Rails. But at the same time I would not be surprised if in 10 years Phoenix has order of magnitude same amount of bloat as Rails 5. Phoenix's promise (last time I heard José speak) is "productivity of Rails, plus high performance"; the high performance mostly comes from the Elixir-based architecture, not from less bloat. The whole issue of bloat in Rails is overblown because Rails has been quite modular since version 3.
    - josevalim 11y ago
      I would actually be surprised if that happened. :) I don't think Phoenix would be as bloated as Rails in 10 years because the platform we are using is just a better platform for the web and for building distributed systems (which Action Cable with Redis plus client-server effectively is). As an exercise, compare the implementation of channels in Phoenix and Rails. The Phoenix implementation is less lines of code (without counting the dependencies Rails brings in) while being more modular: the PubSub system is pluggable and we support multiple transports between client and server (WebSockets and LongPolling officially, embedded stuff coming soon™). Plus every Phoenix channel is concurrent and isolated. In the screencast, DHH says to avoid work on the channel to avoid blocking, in Phoenix you don't have to worry about it, at all. In this particular scenario, we do much more with much less. The most interesting of all is that not along ago I had similar expectations as you when it comes to certain parts of Phoenix like "Phoenix.HTML". I was concerned that Phoenix.HTML would be more verbose than the Rails counterpart, both in implementation and usage. I was very pleasantly surprised when it was not the case. For example, check how we support different inputs in Phoenix (https://github.com/phoenixframework/phoenix_html/blob/master/lib/phoenix_html/form.ex https://github.com/phoenixframework/phoenix_html/blob/master...) and in Rails (https://github.com/rails/rails/tree/master/actionview/lib/action_view/helpers/tags https://github.com/rails/rails/tree/master/actionview/lib/ac...). In Phoenix, a new input is a simple function, in Rails it is a class with inheritance on its own file. Those are just some examples from the top of my head and while I am still learning as I go, I have gathered enough mileage and evidence to expect things to be much simpler in the long term. :)
nthj 11y ago
I imagine that ActionCable will support a variety [1] of pub-subs sooner than later, similar to how ActiveRecord supports multiple databases. I almost took a stab at working PostgreSQL support in a couple of weeks ago, but Tubesock [2] was just too darn simple to pass up for my very minimal needs. [1a] https://github.com/rails/actioncable/pull/28 https://github.com/rails/actioncable/pull/28 [1b] https://github.com/rails/actioncable/pull/29 https://github.com/rails/actioncable/pull/29 [2] https://github.com/ngauthier/tubesock https://github.com/ngauthier/tubesock
FooBarWidget 11y ago
I'm going to disagree with you there. First, apart from the ActionCable dependencies, Rails is already very modular. Starting from version 3 you can cherry-pick exactly what you want and don't want. For example, I have a couple of Rails apps that don't use the database, so they don't load ActiveRecord. See also nateberkopec's comment on disabling ActionCable. Second, I find Rails to still be the most productive web framework. Removing every last bit of redundancy is nice, but it isn't going to save me that much. Maybe it'll save me a couple tens of MBs of disk space, and a couple of MBs of RAM per process. But if that costs me a few hours of work, it isn't worth it. Disk space costs next to nothing and RAM is cheap. Maybe optimizing that makes sense if you're Facebook, but most people are not. Every time I use Node.js, Sinatra, etc I find myself wasting time around the most basic things, e.g. directory structures, database migrations, logging, etc.
- gurkendoktor 11y ago
  > Removing every last bit of redundancy is nice, but it isn't going to save me that much. Maybe it'll save me a couple tens of MBs of disk space, and a couple of MBs of RAM per process. But if that costs me a few hours of work, it isn't worth it. I don't care about the disk space and RAM at all, but every additional C extension (like EventMachine) means one more dependency that can break when I update a) my OS or compiler, b) Ruby, c) Rubygems, d) Bundler or e) Rails. Most of these updates have to be installed immediately for security reasons. I absolutely love Ruby as a language, but with Rails I feel I spend half my time in the terminal, trying to fix `gem install` incantations just to keep things running :(
  - dasil003 11y ago
    I guess it depends on how active development is on your project. My feeling is Rails is only suitable for actively developed projects, if you are building a small project and then handing off to a client without a budget for maintenance than Rails is worse than probably anything else (except arguably Node) in terms of long-term stability. But if your project is actively developed the gem upgrade dance is not too bad.
xutopia 11y ago
I can't imagine running rails at scale without using Redis to cache views. To me it's a non issue.
- gkop 11y ago
  At the very beginning, Rails made a big deal about aspiring to database agnosticism, and to this day ActiveRecord supports a number of SQL databases out of the box. The backend for ActiveSupport::Cache::Store is similarly interchangeable (memcached, disk, etc.) I can see why adding a Redis dependency makes opinionated programmers grumpy, and I predict ActionCable supports other backends than Redis eventually.
- hackercomplex 11y ago
  If you were running rails inside of Torquebox you could make use of the Infinispan Data Grid (http://infinispan.org/ http://infinispan.org/) to cache your views. It's underlying linear scalability mechanism is far more mature than Redis Cluster, and it's deployment story is quite nice. You won't get all of the data structures that Redis provides of course, but if all you need is a great cache, and you're already on JRuby then this could be a better fit for your loads.
desireco42 11y ago
And I thought I was original and unique for learning and planning to use Elixir (and) Phoenix. With or without Dave Thomas. Microseconds I say, microseconds! :) in development!
desireco42 11y ago
On more serious note, we can always specify which gems we want to use. This will just bring a lot of negative energy into a fairly positive rails community, it will be a little like MongoDB, it has a use case you should not use it for, but everyone keeps bringing it up. I think it will be similar with rails, with all the ignoramuses will bring this up as a case against rails, where in reality it is not any more bloated then it is now, once you start using it, you would probably add way more gems.

mbrain 11y ago

Do you see a future in Elixer/Phoenix? And how do you like it?

chippy 11y ago
I often do a word count of languages and technologies in the monthly "Who's hiring" posts here. Elixir/Phoenix gets less mentions than Erlang - often there would be at least one position that says they use Elixir, sometimes none.
- awinder 11y ago
  Small point: this is how all popular languages once started. Much like the stock market, there's value in being balanced on the forefront of a technology along with a solid footing in an established technology. Having no balance in either direction is the only "risky" career move.
- davidw 11y ago
  I once ran a language popularity site thing, and I think jobs are something of a trailing indicator. It takes a while for people to hire for whatever hot new thing is out.
Xixi 11y ago
Another way to look at it is that Erlang has been there for a long time (longer than both Python and Ruby), and it is not going away soon. Elixir and Phoenix may or may not last, that I don't know, but they are a joy to work with.
thibaut_barrere 11y ago
I've beeen learning Elixir in the past few months and I can tell I'm definitely confident it's a good investment. Will use it fairly soon in production, first to implement ETL / streaming / batch processing of data (without Phoenix) then later for APIs (with Phoenix).
hackercomplex 11y ago
I'm much more excited about LFE personally. (http://lfe.io/ http://lfe.io/)
cookiecaper 11y ago
Now that the JavaScript trend is transitioning from "cool hipster language" to "a language that Wal-Mart uses", room is being made for a new language fad. Elixir/Phoenix seems like it may be a good candidate.
- hackercomplex 11y ago
  Why not learn to use Erlang instead of trying to make Erlang "feel kind of like Ruby" ? As far as LFE goes.. implementing a LISP-1 on top of erlang seems like a perfectly reasonable thing to do, but why invent some new funky syntax (elixer) ?
  - piotrnowak 11y ago
    If you think Elixir is about syntax or about making Erlang look like Ruby, you should really watch this talk: https://www.youtube.com/watch?v=Lqo9-pQuRKE https://www.youtube.com/watch?v=Lqo9-pQuRKE Syntax is the first thing José Valim discards on the talk, he then goes on to talk about polymorphism, collections, tooling and so on. Also, both Elixir and LFE have two namespaces, so none of them would be equivalent to a LISP-1.

nemild 11y ago

In general, if "bloat" is an issue for you, I'd highly recommend languages/frameworks where the philosophy is more Unix-like. Rails has always been opinionated about less configuration at the risk of more bloat - and this has advantages for certain teams and certain projects. For example, Node/NPM/Express/etc. all have a philosophy the opposite of Rails bloat, but often require more configuration, and solid knowledge of the underlying middleware. The tradeoff between these two approaches is one many engineers need to make (e.g., the more recent Gulp vs WebPack has some similarities to this debate), and this is a common debate that will likely continue for years in the future. Pick whatever works best for your philosophy, your team, and the given project.

laut 11y ago
Phoenix also has little configuration - without being bloated. With Phoenix you do not have to make that trade-off.
- gkop 11y ago
  Apples and oranges - Phoenix is too new to compare with Rails as far as bloat. I am optimistic Phoenix can do a great job of fighting bloat because of the community's learnings from Rails. But at the same time I would not be surprised if in 10 years Phoenix has order of magnitude same amount of bloat as Rails 5. Phoenix's promise (last time I heard José speak) is "productivity of Rails, plus high performance"; the high performance mostly comes from the Elixir-based architecture, not from less bloat. The whole issue of bloat in Rails is overblown because Rails has been quite modular since version 3.
  - josevalim 11y ago
    I would actually be surprised if that happened. :) I don't think Phoenix would be as bloated as Rails in 10 years because the platform we are using is just a better platform for the web and for building distributed systems (which Action Cable with Redis plus client-server effectively is). As an exercise, compare the implementation of channels in Phoenix and Rails. The Phoenix implementation is less lines of code (without counting the dependencies Rails brings in) while being more modular: the PubSub system is pluggable and we support multiple transports between client and server (WebSockets and LongPolling officially, embedded stuff coming soon™). Plus every Phoenix channel is concurrent and isolated. In the screencast, DHH says to avoid work on the channel to avoid blocking, in Phoenix you don't have to worry about it, at all. In this particular scenario, we do much more with much less. The most interesting of all is that not along ago I had similar expectations as you when it comes to certain parts of Phoenix like "Phoenix.HTML". I was concerned that Phoenix.HTML would be more verbose than the Rails counterpart, both in implementation and usage. I was very pleasantly surprised when it was not the case. For example, check how we support different inputs in Phoenix (https://github.com/phoenixframework/phoenix_html/blob/master/lib/phoenix_html/form.ex https://github.com/phoenixframework/phoenix_html/blob/master...) and in Rails (https://github.com/rails/rails/tree/master/actionview/lib/action_view/helpers/tags https://github.com/rails/rails/tree/master/actionview/lib/ac...). In Phoenix, a new input is a simple function, in Rails it is a class with inheritance on its own file. Those are just some examples from the top of my head and while I am still learning as I go, I have gathered enough mileage and evidence to expect things to be much simpler in the long term. :)

nthj 11y ago

I imagine that ActionCable will support a variety [1] of pub-subs sooner than later, similar to how ActiveRecord supports multiple databases. I almost took a stab at working PostgreSQL support in a couple of weeks ago, but Tubesock [2] was just too darn simple to pass up for my very minimal needs. [1a] https://github.com/rails/actioncable/pull/28 https://github.com/rails/actioncable/pull/28 [1b] https://github.com/rails/actioncable/pull/29 https://github.com/rails/actioncable/pull/29 [2] https://github.com/ngauthier/tubesock https://github.com/ngauthier/tubesock

FooBarWidget 11y ago

I'm going to disagree with you there. First, apart from the ActionCable dependencies, Rails is already very modular. Starting from version 3 you can cherry-pick exactly what you want and don't want. For example, I have a couple of Rails apps that don't use the database, so they don't load ActiveRecord. See also nateberkopec's comment on disabling ActionCable. Second, I find Rails to still be the most productive web framework. Removing every last bit of redundancy is nice, but it isn't going to save me that much. Maybe it'll save me a couple tens of MBs of disk space, and a couple of MBs of RAM per process. But if that costs me a few hours of work, it isn't worth it. Disk space costs next to nothing and RAM is cheap. Maybe optimizing that makes sense if you're Facebook, but most people are not. Every time I use Node.js, Sinatra, etc I find myself wasting time around the most basic things, e.g. directory structures, database migrations, logging, etc.

gurkendoktor 11y ago
> Removing every last bit of redundancy is nice, but it isn't going to save me that much. Maybe it'll save me a couple tens of MBs of disk space, and a couple of MBs of RAM per process. But if that costs me a few hours of work, it isn't worth it. I don't care about the disk space and RAM at all, but every additional C extension (like EventMachine) means one more dependency that can break when I update a) my OS or compiler, b) Ruby, c) Rubygems, d) Bundler or e) Rails. Most of these updates have to be installed immediately for security reasons. I absolutely love Ruby as a language, but with Rails I feel I spend half my time in the terminal, trying to fix `gem install` incantations just to keep things running :(
- dasil003 11y ago
  I guess it depends on how active development is on your project. My feeling is Rails is only suitable for actively developed projects, if you are building a small project and then handing off to a client without a budget for maintenance than Rails is worse than probably anything else (except arguably Node) in terms of long-term stability. But if your project is actively developed the gem upgrade dance is not too bad.

xutopia 11y ago

I can't imagine running rails at scale without using Redis to cache views. To me it's a non issue.

gkop 11y ago
At the very beginning, Rails made a big deal about aspiring to database agnosticism, and to this day ActiveRecord supports a number of SQL databases out of the box. The backend for ActiveSupport::Cache::Store is similarly interchangeable (memcached, disk, etc.) I can see why adding a Redis dependency makes opinionated programmers grumpy, and I predict ActionCable supports other backends than Redis eventually.
hackercomplex 11y ago
If you were running rails inside of Torquebox you could make use of the Infinispan Data Grid (http://infinispan.org/ http://infinispan.org/) to cache your views. It's underlying linear scalability mechanism is far more mature than Redis Cluster, and it's deployment story is quite nice. You won't get all of the data structures that Redis provides of course, but if all you need is a great cache, and you're already on JRuby then this could be a better fit for your loads.

desireco42 11y ago

And I thought I was original and unique for learning and planning to use Elixir (and) Phoenix. With or without Dave Thomas. Microseconds I say, microseconds! :) in development!

desireco42 11y ago

On more serious note, we can always specify which gems we want to use. This will just bring a lot of negative energy into a fairly positive rails community, it will be a little like MongoDB, it has a use case you should not use it for, but everyone keeps bringing it up. I think it will be similar with rails, with all the ignoramuses will bring this up as a case against rails, where in reality it is not any more bloated then it is now, once you start using it, you would probably add way more gems.