Hacker News new | comments | ask | show | jobs | submit login
Rails 5.0.0.beta1: Action Cable, API Mode, Rails Command (rubyonrails.org)
395 points by aaronbrethorst on Dec 21, 2015 | hide | past | web | favorite | 132 comments

An interesting tweet by Sam Saffron:

"@dhh this is just a bit too much https://github.com/rails/rails/blob/master/rails.gemspec#L28 … now every Rails install requires redis, eventmacine, celluloid and faye"


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.

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.

> 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 :(

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.

What are the alternatives?

- actively developed framework -> upgrade fun

- not actively developed framework -> security issues, trouble hiring devs, missing features, et cetera

- no framework, (also known as roll your own) -> much harder for new team to come up to speed on the code base

I contend that the first is the best of the bad choices.

I agree, if you're not capable of ongoing maintenance then you are doomed with all custom software. However I expect a PHP or Java framework to generally require less maintenance.

web2py is quite good. Still runs stuff from many years ago, almost no security issues, does a lot out of the box. Bit of a job to make it work with websockets I'll give you.

Seriously? Cause I had this small 'hand in' kind of project in my hands and saw it as a good opportunity to teach myself Rails. My daily job involves .NET development but that's not very exciting and learning something new was probably the most motivating thing when I accepted the offer. So your comment makes me feel kind of worried about my decision to go with Rails.

If you end up more than a version behind in Rails and your project is sizable, you're in for a special version of hell. Especially if you develop on Mac OS X, the dependency issues with things like libxml2 are especially painful.

See my reply to bryanlarsen... If there is no plan for skilled maintenance down the line then I always refer clients to hosted services like wordpress.com or squarespace. I used to do a lot of custom sites a decade ago with a mix of raw PHP, Drupal, Wordpress and Rails. Honestly it's all turned into a maintenance nightmare for people who didn't have "a guy" to call (I couldn't be this guy anymore after I joined my current startup). If you were determined to go down the custom route then I don't necessarily think Rails was wrong, but just that your client needs to understand up front that this will run for some amount of time and then inevitably need maintenance.

Yeah I'm in a similar situation as in I can be 'the guy' for now but eventually they'll need to find another developer to maintain the app. But what could have been a decent alternative for a webapp + db setup? I don't think wordpress is suitable for that kind of project.

Wordpress I consider to be the worst of the worst because A) it's a constant target of attacks and B) the hosted version at wordpress.com is much less headache (if you don't need heavy customizations).

The good news is that Rails is now mature, so the upgrade path tends to be easier than it was in the early days.

What? This is the least understandable gripe. Every time I launch a new version of ANYTHING you listed above, it comes in the form of a brand new server that swaps into the load balancer. Broken Ops isn't someone else's fault.

Before you can throw another server into the load balancer pool, you still have to get everything to compile & run on it - and on your development machine, if they aren't running the same OS.

I am not talking about `bundle update` on a production server :)

I cannot agree more with you. For me, Rails is a way to get things done fast. If you can follow all rails goodies, there aren't any other framework comparable. The way things just works is the main point for me.

But of course it doesn't fit everyone needs.

Yep, I'm in full agreement. I had to use ASP.NET MVC 5 for a project last month, and it was incredible how... coarse it was. I felt like I took five steps backward and found myself struggling with the most basic things.

For instance, there is no Devise equivalent. No modular authentication package that you can just plug in and configure in 15 mins. Horrible.

No modular authentication package that you can just plug in and configure in 15 mins.



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.

Phoenix also has little configuration - without being bloated. With Phoenix you do not have to make that trade-off.

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.

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...) and in Rails (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. :)

Great, I have set a reminder to investigate bloat in Phoenix on December 21, 2025, and hold you accountable per this message :P

Seriously, I'm not worried about Phoenix, but then I don't mind the bloat in Rails, since it is modular (as is Phoenix). I would be sad though if Phoenix went explicitly away from Rails in the direction of Nodejs (composing apps with lots of smaller independent libraries, requiring more configuration) because "Rails is bloated, bloat is bad".

And to grandparent `laut, thanks for provoking this discussion! :)

> the high performance mostly comes from the Elixir-based architecture, not from less bloat.

Well, Erlang architecture, but yeah. With Erlang you basically obviate the need for Redis, Eventmachine, Celluloid and that whole web socket handling stack because all of that is built in to Erlang/OTP.

Agreed totally in this instance. I was moreso responding to the overall "Rails is bloated" argument.

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

[1b] https://github.com/rails/actioncable/pull/29

[2] https://github.com/ngauthier/tubesock

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

If you were running rails inside of Torquebox you could make use of the Infinispan Data Grid (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.

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.

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.

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

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.

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.

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.

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).

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.

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.

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) ?

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

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.

I'm much more excited about LFE personally. (http://lfe.io/)

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!

DHH did suggest it would become a runtime check, vs a gem dependency last week.

But it seems to have made it into the beta as a gem dependency.


Knowing how responsive the community usually is this will be optional in no time. I think the team prioritized a launch by the deadline they set over issues like this.

While you may disagree with DHH's reasons, you don't have to install or use ActionCable in Rails 5.

Here's a few ways to avoid it: https://gist.github.com/nateberkopec/1184c81a92c10d84d779

You still get redis as a dependency if you `--skip-action-cable`. Seems... odd.

Not to mention, I don't really see all the fuss about EventMachine. I worked with it a few years ago, and it had some very subtle bugs that caused me hours upon hours of headache; it would deadlock under more stressful workloads, or it would simply ignore some packets (even though the proxy server I wrote for debugging it received them just fine and forwarded them).

I just hope that they resolved some of them. And Rails has always been a dependency soup, so I am not too surprised to see stuff piled onto the ever-growing list (I have nothing against Rails, I even use it, I'm just not too happy about the bloatyness).

I would have rather seen Celluloid::IO being used personally but even that has it's quirks.

Now we've got a dependency on both EM and Celluloid. Yay.

I don't think there's even been a point in Rails history where you've been forced to install something. I think those are all ActionCable dependencies, which I'm pretty sure you can deactivate (not every app requires the capability it offers).

The only way to deactivate it is from your app's Gemfile (remove gem "rails" and add all the active/action gems individually). For new apps there's a flag "--skip-action-cable". In the future probably the faye/redis will probably be made adapter based (similar to ActiveRecord and ActiveJob) and exctracted in a gem. So if you want actioncable you'll have to add a "actioncable-faye-adapter" gem to your Gemfile.

Minor note -- it doesn't appear like it requires faye, but rather faye-websocket, which is just a particularly amazing websocket wrapper that sprung out of the faye project.

Just a small correction to this tweet, it doesn't use faye but faye-websocket which is just a websocket client/server which represents a tiny part of the Faye messaging system.

You just need to comment the line in the Gemfile and you are done, no more dependencies. What is the big deal really.

That isn't the case for ActionCable, which will become a dependency of the 'rails' gem [1]. You'll have to unbundle the rails gem in your Gemfile, then require the frameworks you want one-by-one in application.rb

[1]: https://github.com/rails/rails/blob/master/rails.gemspec#L28

You can just add each Rails framework to your Gemfile and be done. `require "rails/all"` catches load errors, so you don't need to require the frameworks manually in application.rb.


Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s

> Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s

AFAIK nodejs is already an optionial rails dependency for the asset pipeline.

It is through ExecJS[1] which allows different Javascript backends.

[1]: https://github.com/rails/execjs

While I prefer Django to Rails, I'm glad to see both teams taking support for real-time applications seriously.

Some will note that Node has had real-time for years, but with all due respect to the Node ecosystem, nothing in it (edit: I'm referring to server-side frameworks; I love Ember-CLI) is as nice for developer happiness and productivity as Django and Rails. The best practices that have taken years to be baked into these frameworks make it more difficult to bring in new functionality, but I feel more confident that when new features are implemented, they will be done right.

As a designer that started programming in rails, that now uses front-end frameworks like Angular to build prototypes, I absolutely agree with you. JavaScript MVC experience vs. Rails/Django is night and day. I know it's not an apples to apples comparison, but JavaScript, npm, grunt, etc. etc. are all a real drag imo.

I have a feeling there are a lot of people looking at this from a similar angle.

I feel that we are in a very transitional time for web development right now. This is a field with a pretty high rate of change in general, but every now and then, things change dramatically even by web programming standards, and we go through a period of technological uncertainty. The last time I remember feeling this way was the rise of object relational mappers, dependency injection, model view controller frameworks, and various tag libraries on the front end[1] in javaland. I remember from a previous HN discussion that there is a web counter measuring the number of days since the last javascript framework was released. I remember feeling the same way about struts, struts2, spring MVC, tiles, tapestry, JPA, hibernate, ibatis, spring DI, pico, guice, and so forth…

Interestingly, much of this didn't so much get resolved as swept aside - Ruby and Rails, Django, and a few other technologies "appeared" [1, again] at this moment. I do remember feeling extremely grateful for ruby and rails, because I had started to hate programming. It wasn't the Java verbosity that I objected- I rather enjoyed programming with servlets/jsp and jdbc + the java web cookbook, and I never minded data structures and algorithms in Java - it was the churn and incredible amount of complexity just to do simple things that made me unhappy. Rails got some bloat here and there, expand and consolidate, but I feel that it did accomplish its main goal, at least for me, which was that I felt happy and productive programming again.

Now, with the disruption of SPAs, we are clearly back in framework churn, and I'm not loving the model of writing the back end in rails-api and using a javascript front end. I may warm up to this as my knowledge of javascript increases (and I certainly never minded going outside rails and writing sql, so I can't really say I object to more than one language). I've done a bit of ember, and it seems heavy to me, I have to duplicate so much routing, model, persistence, data tier work (I'm a noob, I may be doing it wrong, fully possible). I don't like looking at javascript as much as I like looking at ruby. I also do remember feeling a bit frustrated with Rails in the beginning, before I understood it well enough to do an end-run around conventions, so like I said, I may really warm up to javascript frameworks. But I really like Ruby, and I'm very satisfied with Rails (and if not rails, sinatra or something like that would be fine too).

Like I said earlier, I studied a lot of java-based MVC/DI/ORM approaches and ended up going with something that I hadn't even considered (Rails). I do think that in these highly transitional periods, this tends to happen - that you are surprised by the solution that ends up working for you. At this point, it's getting so speculative that I'm not highly confident in predicting things, but I wouldn't be too surprised if the "isometric" transpiled languages (like ruby and opal) end up changing things dramatically (ie., just as I didn't end up "picking" a java-based MVC/DI/ORM approach, I may not end up picking a javascript framework, I may end up surprised by a new and different approach).

[1] I understand these weren't really "new" ideas, many of them (like a lot of CS) go back to the 1970s, but they hit the scene in that they became an issue in day to day development for ordinarliy up-to-date but not cutting edge web developers, the people who just wanted to get things done.

  >  I've done a bit of ember, and it seems heavy to me, 
One thing about Ember: it's specifically for "ambitious" applications. The idea is that you're going to be building something which needs all those things, so it's better to have them in the framework, where best practices can be shared across projects. Once you've built out those features yourself, you've built a custom framework anyway.

An interesting point about frameworks, generally: they have a constant overhead. So for smaller projects, the framework dominates the application, but as the application grows, the application will dominate the framework.

We're using Rails (in 'API-mode') with Ember. It's a great combination in my view. Thrilled to see Rails 5 providing even better support for this combination.

@steveklabnik Thanks for spearheading Rails-api! :)

Re: Ember being heavy; yes, it is a bit heavy but that has huge payoffs as your application grows.

Any time. It's been a few years, but it's finally in. Frankly, I had very little to do with it becoming eventually included, I believe that was Dan Gebhardt's work.

I should probably give some context for that statement. When I first learned Rails, it actually wasn't easy. People will probably be surprised to hear me say this, but Rails felt heavy! Seriously, compared to jdbc, servlets, and jsp, it felt heavy. I'd guess that people who were programming in PHP or perl/CGI probably felt it was "heavy" at first too. Of course, my code base was getting "heavy" too, since it was disorganized and mixed a lot that shouldn't be mixed. But if I wanted to do something, I didn't have to figure out the rails or spring way of doing it. I could go to the java web cookbook, or just write it up however I pleased. It feels a little weird calling jdbc "low level", but at the level of the task I was trying to perform (getting stuff into a database, programming logic on data, putting stuff back into a database, displaying stuff to a user), servlets and jdbc are actually kind of low level. You can do pretty much whatever you want, quick and dirty request-response, or build out your own MVC, ORM, and DI framework.

Now, on the other hand, compared to Struts or Spring MVC, Hibernate, and Spring DI, Rails felt lightweight. But if you compare someone else's MVC framework, like Rails, to a database connection and a programming language that can write out a server response, it's going to feel a little heavy, and you're going to feel a bit lost at first, no matter how good it is.

It took me a while to get used to Rails even though I consider Rails to have a friendly learning curve. So I do want to be clear that I don't necessarily consider Ember to be "heavy" in the context of what Ember seeks to accomplish.

To me, the real issue here is that if I'm going the rails-api route, I will have to use something non-ruby on the client. And then the question becomes why not just use javascript on the server, too, with node.js? Honestly, my initial study and experimenting with node and express have been positive, but I don't like the idea of giving up on ruby, or that all these wonderful server-side languages are obsolete now because for the moment, javascript rules the browser. Nothing wrong with node.js, at all, for those who like it but I have trouble believing that all web development, server side as well as client side, slowly migrates over to javascript, and that python and ruby become legacy languages because, well, why use anything other than javascript?

At this point, I'm just repeating myself, but I'll restate my very tenuously held belief that isomorphic, transpiled languages will play a big role in the resurgence of non-javascript languages for full stack development.

I can empathize :)

  >  And then the question becomes why not just use javascript
  >  on the server, too, with node.js? 
I feel this from time to time. There are good things about it, but bad too. I mean, different languages have different strengths, and front and back end seem different, so it would make sense that a language designed for each case is going to maybe be stronger than a language that tries to straddle both.

It was really refreshing to read this response. Somehow it turned into "I prefer framework X over Rails because...." and Rails is lame because [fill in the reason here]. I've never even heard of Phoenix before this thread.

I guess Rails is stodgy and old. Technology changes very frequently sometimes too frequently. Less than 2 years ago everyone was getting on the Angular bandwagon. Now the conversation I've been having with employers is "Yeah we've decided that React is going in a better direction so we're replacing it with React."

Think about all that wasted code and time learning how to use the new framework so you can get what out of it? A few more miliseconds performance? Better more visually pleasing syntax? Learning the new hot thing? Does anyone ever think about the Return on Investment (ROI) relationship between learning something new, how hard it will be to learn that new technology and then figure out what you are gaining from using this new thing? Once you spend all that time trying to scale the steep learning curve for Angular or Ember or whatever new tech comes down the pike do you ever wonder "what did we gain by learning this new technology? was it worth the trouble learning it? What benefit did it provide once you know how to use it?"

I guess Rails is getting long in the tooth, but for the most part it does what I need it to do. It's predictable, it's readable, it's organized, and best of all I'm just competent enough to use it. I've hit the wall trying to learn it and overcome most of the pitfalls and aggravations while using it. It's just blowing my mind how eager many programmers are always pursuing the next technology. I'm all for change but only if the change is worth the aggravation. I don't know if Rails 5 is a big improvement but really it's good enough for most of what I need it for.

I love Rails. And in 2014 I wanted to build a very specific type of realtime app with Rails. I used Faye-websocket and Redis and got everything working with Puma.... and it fell flat on its face.

I learned enough Elixir and Phoenix to be dangerous and built the same thing there in about 2 days with much, much better performance. I've been working on it since.

I don't see myself moving away from Rails for most things I write because it's just more mature and suits my style of coding. I disagree with the way the developers of Ecto (the database adapter for Phoenix) are approaching things, so if I have a web to database app, it's Rails all the way. (Their decisions aren't bad. I just don't like them and that's my problem, not theirs.)

But if I have to do anything that deals with the realtime web, I can't think of anything better than Phoenix. I'll get over my issues with the DB layer and get stuff done because Phoenix channels are awesomel

This is a long winded way of saying "you should really look into Phoenix." :)

I have a Rails app running in production now where I used Faye for the websocket component. Faye is running in an isolated process (the nodejs version actually), and the Rails app POSTs to it through a Sidekiq worker.

Interestingly enough, that's not too dissimilar to the ActionCable model despite using slightly different techs.

Long story short, I had no issues with this set up and it's been running for around a year. I'm not at roflcopter scale, but it churns out about 100k events per month through Rails->Sidekiq->Faye without breaking a sweat.

That sounds really complicated to me. Lots of moving parts to maintain. What is Sidekiq doing for you?

It's simple to me because Rails doesn't know or care about the websocket server, it just understands that it needs to POST data to an end point with certain data. I can have 1 or 100 Rails instances posting to the single Faye server.

The Faye server doesn't know or care about Rails. It just needs to do its job of broadcasting the event to subscribers.

Sidekiq is there for me to easily monitor the events processed, and in theory the Rails app may not be in the same private network as the Faye server, so I decided to make the POST requests happen in Sidekiq. It seems like a good spot for that, since it's a "send it and move on with life".

The Faye server pretty much runs itself, it's been going for months and months without maintenance. Sidekiq gets updated once in a while because I'm using it for other things too and sometimes the app code for it changes, not a big deal tho.

I haven't even had the chance to learn Node and Meteor. The list of stuff I want to learn grows by the week. So many things to learn. Too many things!

Phoenix will have to wait.

> I don't like looking at javascript as much as I like looking at ruby.

If I could choose, I would take Ruby or Python over plain JS. But CoffeeScript makes the best parts of JS shine (an object is a hash/map) while making it far more beautiful by disposing of semicolons and unnecessary braces and parentheses. Indentation and arrow functions really make it a beautiful language. If you haven't already, you owe it to yourself to try Ember with CoffeeScript (and Emblem and indented Sass).

I don't want to start a rails vs Django conversation, but why do you prefer Django over rails? I'm a rails dev and am just curious where Django is at with things.

A little bit of background: I learned Django first. Then I learned Rails via Code School, and flirted with building my app with Rails instead of Django. I saw the asset pipeline specifically as a Rails advantage over Django (I write Emblem, indented Sass, and CoffeeScript whenever I can avoid HTML/Handlebars, CSS, and JS). Also, building JSON APIs with Rails has better out-of-the-box support than it does in Django.

I always felt Rails' model layer is clunky compared to Django's. What is the definitive representation of my model? The validations in SomeModel < ActiveRecord::Base or what's automatically generated in schema.rb when I run migrations via Rake? In Django everything, including migrations (in simple cases), is derived from the classes in models.py. But I thought it would be worth it to persevere, due to the above-mentioned advantages.

Then I realized I could (and should) compile assets via Ember-CLI, and Django Rest Framework is just a pip install away. So the two main advantages of Rails disappeared, and switching back to Django became, for me, a no-brainer.

Edit: I also prefer Django's less magical approach. This may seem ironic given my love of Ember, but Ember's magic is easier for me to understand than that of Rails.

Personal opinion, obviously, but I also find Rails to be way too magical sometimes.

I am also a Rails dev, but one feature I think Django really got right that is head and shoulders above Rails are Form Objects (https://docs.djangoproject.com/en/1.9/topics/forms/). Rails' attr_accessible stuff and even strong_parameters really pales in comparison.

I do rendering on the client-side, so do not use Django's Forms. But there are ModelForms which integrate seamlessly with your model because it is the definitive representation of a real-world object.

Similarly, Django Rest Framework has ModelSerializers and ModelViewSets which give you a lot of free functionality out-of-the-box precisely because Django's Model layer was designed with DRY in mind.

The new Attributes API is interesting. https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab...

Basically it's a type system for models with the ability of defining new types. I wonder if it can be used also for plain Ruby objects but given the existence of tableless ActiveRecord gems, why not? https://github.com/softace/activerecord-tableless/

That's pretty cool. Basically including the best parts of ActiveAttr into ActiveRecord. :)

Maybe someday we won't have to write migrations anymore. Rails could maybe just diff the attributes and types given, and figure out the schema itself.

Oh yes, I always though it would make more sense to setup columns in the model itself, without migrations. Also, no more need for the annotate gem.

I see your point but the implementation must be very well designed.

There are migrations that can take hours to complete in production. Examples: adding an index to a very large table or adding an element to an enum (I remember a customer of mine had this problem on a MySQL db a couple of years ago.) A DSL that makes clear you are modifying the db is a safeguard against those surprises. Just adding something like indexed: true to an attribute declaration would be dangerous. Furthermore rake migrate:up/down are more convenient than reverting a change to a model by checking out an older version. I believe that it's not impossible to do it, but it must be designed very carefully.

Maybe because of those reasons Phoenix, the Rails like web framework for Elixir, has migrations even if models declare the attributes of the tables in the database.

That's what original datamapper did. There are several problems with this approach, and basically you need to have a migration mechanism anyway.

Didn't know about ActiveRecord-tableless thanks!

Glad to have an easier way to incorporate AR benefits without including one by one

DHH made a Action Cable demo where he builds a chat-application: https://www.youtube.com/watch?v=n0WUjGkDFS0

How DHH manages between Ruby, Basecamp, Family and Racecars I don't know.

Don't forget Twitter! He's pretty active there too. :)

+1 for an AMA about this.

He actually held an AMA with Business of Software the other day - http://businessofsoftware.org/2015/11/should-you-rewrite-you...

Full disclosure: I help produce the events - but you did ask.

[edit: it's only touched upon about his lifestyle - it's far more about his recent talk about rewriting software from scratch]

One suggestion for future recordings: please mute all people, except the one talking - the touchpad clicks and constant noises in the background are making it really difficult to listen to what's being said... I gave up after a couple of minutes.

Feedback much appreciated - I'll make sure that's followed up and implemented. Thank you :)

No kids? :)

He has a son named Colt, apparently:


I love the "One Rails command to rule them all" streamlined bin/rails command. Wondered always why there are different commands. Thanks guys!

I figure its because its quite annoying to pass arguments to rake tasks. So all the commands the required arguments lived in the rails command, the rest in rake.

I like the concept to use a single web socket with multiplexing/demultiplexing mode. It's very simple concept but rails yet give to its developers the 'right way', to set under control the number of connection of web sockets. Now each connection will use the same web sockets and every connections on the web page pass by it. This means that each service send message like: (service_A: requests)->(multiplexing) -> Web Socket -> (demultiplexing) -> Server

They pretty much just stole the best parts of Phoenix Channels and phoenix.js right?

And check out the guide for upgrading Rails...


That page covers a number of upgrade scenarios, the section for upgrading from 4.2 to 5.0 only has three entries[1], one of which is optional.

[1] http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

Great, both Action Cable and the api-capabilities are really useful. Great to see that Rails is keeping itself up to date.

Any new dependencies, besides NodeJS? .Net portable runtime? Swift? Rust for safety?

I'm told[1] that Node isn't a new dependency...

[1] https://news.ycombinator.com/item?id=10770732

Rails doesn't even depend on Node.js exclusively. Rails depends on some JavaScript runtime so that it can minify JavaScript. You may choose to install Rhino, or some V8-based gem, or whatever.

What will the upgrade path from 4.2x be like to 5x? Do you have to re-write your apps or is it upgradable?

My company's main app (~50k LOC acording to rake stats) has been upgraded continuously from 1.2 up to 4.2. The most painful upgrade was 2.3 to 3.0, followed closely by 3.0 to 3.1 (which was incidentally painful because of a performance regression affecting ruby 1.8, so we had to simultaneously do the 1.9 upgrade at the same time which was the most painful ruby upgrade of recent memory). Since then the upgrades have been easier.

From what I've seen 5.0 should be on par with the 4.x upgrades, which is to say, not bad. YMMV of course.

That's pretty impressive - we've basically stalled at 2.3 because of the Ruby 1.8 upgrade making it near impossible to bump everything we'd need to at this point.

My understanding is this also happened to GitHub and they stayed on 2.3 for years, even maintaining their own fork to handle security issues once official support lapsed. I also understand they eventually realized this wasn't viable long term and made the massive effort to get over the hump.

FWIW, the memory and instrumentation improvements in Ruby 2.x alone are worth the massive effort to upgrade. Good luck!

If you want to read up on how Github transitioned, this post is useful: http://shayfrendt.com/posts/upgrading-github-to-rails-3-with...

Getting stuck on 2.3 isn't desirable.

One of the projects I deal with on a daily basis is a 200k line of code monolith on 2.3. We've got a paid for version of 2.3 from a company that releases security patches for it.

Everything else at the company is microservices now, but this one system still has a few million customers.

Yeah, we're paying for security updates to 2.3 rather than maintaining our own fork, although we do have an increasing stack of backported features. Our approach to getting off 2.3 is to extract core functionality out into smaller API driven applications, with the eventual goal of being able to turn off the monolithic 2.3 based application.

IIRC, there's a service that handles the upgrades for you. found it! https://www.railsasaservice.com/

That is genius. A huge market opportunity for sure.

The question is whether they have the economics right to earn a nice profit; could be tricky, but I guess if you do it day in and day out you get it dialed in pretty well.

Judging by the quote I got from them, yes, they can run very comfortably on that sort of money.

> Do you have to re-write your apps or is it upgradable

Looks like a fairly painless upgrade according to http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

I wonder if Ruby 2.3 will be released on Christmas Day this year (a Ruby tradition).

So does this mean that this pull request isn't accepted? https://github.com/rails/rails/pull/19272

Why release a beta if it's just an alpha? All the features isn't there. Why have this [temp] milestone? https://github.com/rails/rails/milestones/5.0.0%20%5Btemp%5D

Hi, I'm the author of the pull request. The pull request got stuck due to an issue with dynamic injection of local variables into view templates. (Explained more in the Aaron Patterson's RailsConf keynote[1]). We were planning to solve this issue before (potentially) merging the feature.

At the moment, it looks like the issue is solvable, and I have code that seems to solve it but still needs some refinement before I can submit a pull request about it.

I don't know what the Rails core team is planning about the feature, but considering how complex the whole thing is and how much there's still left to do, I'd guess that it won't make it to 5.0.

[1]: https://www.youtube.com/watch?v=B3gYklsN9uc&feature=youtu.be...

I see that it's an issue. But the places you use locals in a template is small. Majority of the templates would still benefit. Like the main layout and so on.


Just looking at the client examples for action cable; is CoffeeScript now the standard way of doing JavaScript in Rails?

Using CoffeeScript for generators has been the default for a long time (Rails 4 for sure, but probably even from Rails 3), but you can use JavaScript as well (to the asset pipeline it makes no difference if the files are .js or .coffee, they get processed and concatenated/minified the same way), or change the default so generators generate JS files.

I like (and currently use) CoffeeScript. But it seems like ES-Y and Babel is the future, so I think removing CoffeeScript as the default in Rails would be a good idea.

There are a number of perverse incentives going on here:

- Rails needs something opinionated and "new" every so often to remain relevant.

- Workers, consultants, etc., benefit from being familiar with the latest rails, so many projects are upgraded that don't need to be.

- New versions break lots of gems and useful online tutorials, increasing the value of experience relative to aptitude.

So now, across the world, lots of teams will remove perfectly good code and divert lots of attention to upgrading to Rails 5 for no apparent reason or simply that a higher number is viewed as better.

Contrast this with the node ecosystem where libraries tend to be smaller and significant version bumps typically take an hour or so to accommodate at most.

The worst part is that if you engineered an alternative to action cable (for example) into your app, Rails 5 makes your approach seem outdated for no reason.

- If you upgrade a project "just because" then you're doing it wrong. That isn't the fault of the rails team. - New versions don't break that many things that aren't tied directly to how rails works. Most general gems will work just fine, and a lot of tutorials from 3.2 are still more or less usable with minimal googling. Generators work the same, active record's api hasn't changed much, action view works the same way.

And don't get me started on the mess that a node dependency graph can become.

While upgrading "just because" should be avoided (and indeed, DHH stated as much in a keynote at one of the RailsConfs), that's exactly the approach the Ruby community/ecosystem have adopted as a whole. Most Rails plugins don't maintain compatibility with multiple versions. And if you use something that overlaps with Rails's dependency graph, you're going to have to deal with that in one way or another.

In Ruby and Rails, you basically have to keep updating regardless of the changelog simply to amortize your costs. If you fall too far behind then when you invariably do need to upgrade a dependency, you're going to have to pay all that cost in one swoop and the complexity of that amps up considerably.

I missed the keynote, but according to the OP the release of Rails 5 means "4.1.x and below will essentially be unsupported".

My advice is always to upgrade 3-6 months after a major or minor release. After 3 months so that other people have exhaustively documented their troubles and resolved incompatibilities in the libraries they maintain. And before 6 so that Google results for common issues are still fresh.

So I think putting it in terms of "just because" is not really very helpful. In a sense my upgrading in the 3-6 month interval is "just because", but doing it this way keeps the overall maintenance burden to a minimum, since I do have to upgrade sooner or later in order to receive security updates.

Obviously everyone has different situations. But if all you need are security updates, the Rails team has historically been very good about providing patches even for unsupported releases. If they don't, porting is often fairly trivial anyway. I often see ronin [1] implementations of exploits very soon after a CVE so you can even test against your own app.

Unfortunately, my point was more that you can't just not upgrade Rails. Eventually everything else you use will require newer Rails and upgrading at that point becomes extraordinarily difficult. E.g., ActiveRecord plugins often just monkeypatch the internals, which are naturally free to change from release to release. However, most gem authors don't want to test against multiple versions, so the latest becomes the only supported one and you have to upgrade "just because."

[1] -- https://github.com/ronin-ruby/ronin/

That's all totally fair. I really wish people weren't so quick to monkey patch things, especially when it comes activerecord.

"Eventually everything else you use will require newer 'x'", I think this is a problem even with non-frameworks. Imagine any core to your functionality lib getting far out of date. Dependency graphs are hard to manage over time.

Agreed. It just seems far more pronounced in the Ruby ecosystem. My experience with Python and Java is that both communities are okay with maintaining multiple versions of a library. And when you commit to that, you adopt practices like separate namespaces between major versions, which can make upgrading substantially easier. With a bit of trickery, you could even load two different versions of the same lib as long as their namespaces don't conflict. Ruby gems, on the whole, hardly ever employ namespacing so that option isn't even available.

I don't see it so much as a technical limitation of Ruby, but simply the way the community has evolved. With other ecosystems, the emphasis is often on stability by sticking what's known to work. Abstractly they have the same dependency graph problems, but in practice their problems and solutions are quite different.

While I agree that you're probably going to be upgrading in part to amortize your costs, it's not like you're getting no value out of it. The upgrade from 4.1 to 4.2 had significant speed and stability gains in active record. And recent versions of a lot of popular gems are both faster and more secure.

Don't get me wrong, there are reasons to upgrade. But all other things being equal, you may very well not need the newer features. Rails has an astoundingly good track record with backporting security fixes, going so far as to provide monkeypatches for those that can't upgrade their gems for one reason or another.

Upgrading Rails can force upgrades on a lot of other things, however. And new bugs get introduced all the time. Performance regressions happen. Etc. There should be a more compelling reason to upgrade than the version number changed, given the additional risk you take. Unfortunately, that's often not the case.

Applications are open for YC Summer 2019

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