10 ms·

Why Nobody Should Use Rails

157 points by mwcampbell 13y ago

ballard 13y ago
This article is religion bait. TL;DR: For most things, I would put node at the top for many new web apps because of its surface similarity to frontend. -- After some evaluation in the past, Rails had some ghetto-like speed-bumps: I patched devise to use scrypt because the existing shit besides bcrypt was broken. devise-encryptable is a CWOT, don't bother. Maintainers promise all sorts of future dismissive bullshit but don't care, that's abundantly clear. Security in RoR is a fallacy. As a signal, almost none of the gems were signed, especially Rails. If you don't mind not being able to prove code the author pushed has not been tampered, by all means, run code from the public straight to production. I wrote a gem to make gem signing simple, waxseal, but since signing is optional, it's never going to change unless RubyGems has a major security incident. I just don't have the bandwidth to waste on a community that doesn't get it. -- As to what's coming up in the systems world: Go is more suitable for crunchy backend services typically in the systems domain of Erlang, Java or C(|++). C is portable at the expense of autotools and so much extra boilerplate to do anything. A lot of people that matter know and are comfortable with C, so libs and kernels will use that for sometime in the future. Go or similar would take decades to adopt because there's not yet enough compelling chicken-and-egg evidence to change to a different flavor of Turing-completeness. Go is qualitatively solid. It addresses entire categories of software engineering problems that happen at scale. If you're doing bank software, you're probably stuck with a mostly JVM &| CLR runtime stack.
mshahriarinia 13y ago
See where codeigniter, cakephp, django are all from rails? Just look at http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ You are comparing a language to a CMS?
mwcampbell 13y ago
I submitted this because I thought it might make for some good discussion, but: > This post is my attempt to be fair, objective, and, by consequence, unrelentingly negative about Rails :) To me it seems arrogant to assume that you are being fair and objective when you only point out the negative attributes of something. I'd be more inclined to assume that there are positives I'm overlooking, that might even outweigh the negatives. Especially for something as beloved by developers as Rails. What evidence is there that running a process per core has a significant negative effect on throughput and/or latency in practice? Benchmarks? Data from developers who tried both approaches while holding all else constant? (The latter is probably quite difficult in practice.) Also, JRuby supports real threads without a global interpreter lock. I think I agree with this post about the benefits of static typing, though.
- kevingadd 13y ago
  Objectivity is a separate thing from the topic of the post. He came into it wanting to write an explanation of why he thinks you should never use Rails, and attempted to be objective about it by including data and describing some caveats to his argument (i.e. scenarios where you might be able to get away with it). A post that says 'why you should or shouldn't use rails' is a different post and no more or less implicitly objective. Objectivity does not mean 'covering two sides of an argument'; sometimes one side is less or more supported than the other and sometimes you simply don't have the knowledge to cover both sides fairly.
- hatsix 13y ago
  ... also, the evidence for the performance is the benchmark image in the sidebar.
- el_bhs 13y ago
  (I wrote TFA -- didn't expect it up on HN!) I agree that the post would be more compelling if I wrote a benchmark to demonstrate how much faster an in-memory cache is than an off-process or off-machine cache. From first principles, though, I believe it should be obvious (yes?) that the ~300 nanoseconds it takes to grab a read lock and read from main memory is going to beat the ~1000000 nanoseconds it takes to get a response back from a remote cache over the network. Inasmuch as an application blocks on such cache reads, these sorts of things add up to troublesome latency numbers (and Rails – or at least dallistore – does indeed block on reads like these). JRuby was off the table for the place I used rails due to reliance on some C extensions. And I'm sorry if the argument seemed arrogant: I was being tongue-in-cheek about the "unrelenting negativity" part. My point about objectivity was that I tried not to rely on my opinions as much as demonstrable statements. That said, I didn't take the time to actually demonstrate most of those, and for that, shame on me.
  - mwcampbell 13y ago
    How about the performance difference between an in-process cache and a memcached instance on localhost? Surely anyone who knows what they're doing will run the cache on the same machine as the web server. (I guess that makes a good argument for not using a PaaS that gives you too little control over locality.)
jfb 13y ago
I don't like Rails, and I don't like Ruby, but this wasn't a particularly enlightening piece. He doesn't explain why using something like Django in place of Rails makes sense; he handwaves a bit over Node. There's some statically typed language dogma, and that's it. I'd love to read a good hit piece on Rails, written by someone who spends the time to lay out a strong technical justification for their opinion. This was disappointingly Twitterish.
- ThunderChief 13y ago
  I completely agree. This piece highlights the inherent drawback of all dynamic languages: performance. We've been through the performance argument too many times to count with both Rails and PHP. I don't know what kind of taste I would have if I were to follow this piece as advice. Am I expected to do CGI in straight C? Ridiculous.
- amalag 13y ago
  With this article python==ruby because they are dynamic
  - jfb 13y ago
    He sort of feints towards talking about why Django might be faster, but then doesn't. It's fundamentally an entirely vapid piece.
- ape4 13y ago
  For a midsized to big project static typing is really nice. eg A few years ago I had a perl project that only let you know a function was missing at run time (ie when the user asked for that code).
  - jfb 13y ago
    That sounds ... less than great. I'm a fan of static typing, no question. I'm just not impressed with this article's handwaving.
  - Mithaldu 13y ago
degobah 13y ago
Basically the post just says: 1. Rails is slow 2. Dynamic languages are bad
- deleted 13y ago
  [deleted]
  - lclarkmichalek 13y ago
    Oh god, please don't slight Go, we'll have tptacek in this thread in no time
    - chc 13y ago
      Last I checked, tptacek is actually a big fan of Rails.
    - deleted 13y ago
      [deleted]
      - lclarkmichalek 13y ago
        I agree with your comment, and I shan't try and justify my comment, for it is libellous and unjustified. However, I guess I could have used "failed to describe Go with an adjective that you used in a positive context when discussing another language" over "slight". That said, it doesn't roll off the tongue as well.
- everettForth 13y ago
  It's worse than that. He links to a set of benchmarks to demonstrate that rails is slow without even considering the caching utilities that rails provides. Who bases their sole criterion for a web framework on speed, and then ignores the baked-in caching functionality that a framework provides?
  - bhauer 13y ago
    To be clear, the particular test cited is expressly designed to exercise the framework and its ORM+database connectivity. None of our present test types permit the use of a reverse proxy cache because we are specifically interested in measuring the performance of the frameworks/platforms and not the performance of reverse proxy software; you can find such tests elsewhere. Further, reverse proxies are only suitable for a subset of real-world applications where it is acceptable to cache output for consumption by a wide audience. In other words, Rails wasn't unique in being tested without a preferred reverse proxy. Every single framework on that list was tested without a reverse proxy. A future test type [1] will exercise back-end caching (e.g., memcached in the case of Rails), but we are not planning to ever include reverse proxies (of any form) in the project. [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/374 https://github.com/TechEmpower/FrameworkBenchmarks/issues/37...
gphil 13y ago
I have my fair share of issues with Rails, but I think this is a bit extreme. When I look into other ecosystems, the amount of library support for building modern web applications just doesn't compare. I think it's this aspect of Rails that really helps get from zero to viable product so quickly. That said, the performance issues do start to take a toll after a while. And forget it if you want to do something counter to the way Rails want you to do it. Everything is a trade-off.
aaronbrethorst 13y ago
Why do I care if my simple CRUD app can only use a single CPU core? Because someday I might have millions of users and then I'll have Twitter's old problems? I'd love to have to Twitter's problems. Use the right tool for the job. And claiming that Rails is never the right tool is just silly.
- amalag 13y ago
  I guess in the authors world there are only million user applications. I agree that it is silly.
  - el_bhs 13y ago
    I can't resist (this is the OP): you are missing the point. It's not just throughput, it's high-percentile latency. Latency is critical if you have 1 billion users or 100 users, and it is difficult to bring the high percentiles of the latency distribution down into reasonable territory on Rails since, by default, all operations are essentially serialized.
    - mwcampbell 13y ago
      I guess the problem of high-percentile latency is not widely understood; I'm not sure I understand it myself. Can you explain in more detail? In particular, are you talking about requests that take a while to complete because they have some complex processing, or requests that take a long time to complete because they can't be processed until some other long-running request finishes? The bit about everything being serialized suggests that the main concern is the latter. Does this apply even when using multiple threads under the C Ruby implementation? Why does running multiple web server processes on the same machine not mitigate the problem? BTW, I don't use Rails or Ruby, but I do use Python for web apps at work (currently CPython, GIL and all). I'm curious to find out if this problem of high-percentile latency applies to Python as well.
      - el_bhs 13y ago
        Sure. So, for any black-box service endpoint, the latency for any given request is obviously just the time it takes for that operation to complete. Ideally one measures both end-to-end latency from the client and server-side latency in order to understand the impact of the network and, for high-throughput applications, any kernel buffering that takes place. All of that is obvious, I imagine. By "high-percentile latency", I'm referring to percentiles of a distribution of all latency measurements gathered from a given endpoint over some period of time. If you imagine that distribution as a frequency histogram, the horizontal axis ends up being buckets of latency ranges (e.g., 0-10ms, 10-20ms, 20-30ms, etc), and the bars themselves of course represent the number of samples in each such bucket. What we want to do is determine which bucket contains the 95th percentile (or 99th, or 99.9th) latency value. You can see such a latency distribution on page 10 of this paper which I published while at Google: http://research.google.com/pubs/pub36356.html Anyway, it is a mouthful to explain latency percentiles, but in practice it ends up being an extremely useful measurement. Average latency is just not that important in interactive applications (webapps or otherwise): what you should be measuring is outlier latency. Every service you've ever heard of at google has pagers set to track high-percentile latency over the trailing 1m or 5m or 10m (etc) for user-facing endpoints. Coming back to Rails: latency is of course a concern through the entire stack. The reason Rails is so problematic (in my experience) is that people writing gems never seem to realize when they can and should be doing things in parallel, with the possible exception of carefully crafted SQL queries that get parallelized in the database. The Node.js community is a little better in that they don't block on all function calls by convention like folks do in Rails, but it's really all just a "cultural" thing. I don't know off the top of my head how things generally work in Django... One final thing: GC is a nightmare for high-percentile latency, and any dynamic language has to contend with it. Especially if multiple requests are processed concurrently, which is of course necessary to get reasonable throughput. Hope this helps.
facorreia 13y ago
I'll share my personal opinion and experience. For reasons like this, and I would add, scary security history, I decided against using Rails. I've experimented with Django and lightweight Python frameworks, Node.js and Java 6 EE, among others. What has worked best for me was C# + ASP.NET MVC. The C# language has several features that I find appealing and lead to clean, efficient code (such as dynamic, lambda, LINQ and async, among others). The modern incarnation of ASP.NET running under IIS is quite efficient and productive both in development, profiling & diagnostics, and in production.
- lmm 13y ago
  Have you tried F#? To my eye it takes those features you mention liking, and goes further with them. (Scala guy myself)
  - facorreia 13y ago
    I took a look at F# but for the kind of applications I write, I prefer to follow mainstream, for the bigger ecosystem and less surprises, and C# is powerful enough for me.
    - dragonwriter 13y ago
      Isn't one of the selling points of .NET that any language on the platform has full access to the whole .NET ecosystem?
      - facorreia 13y ago
        I mean ecosystem in a broader sense, including help on Stack Overflow, sample code, etc.
- kevingadd 13y ago
  I've done some web dev with node, python (GAE) and php. I ended up using C# + mono's web server for a recent project and was pleasantly surprised. ASP.net is showing its age but there are some solid libraries, reasonably comprehensive documentation, and some nice new frameworks like MVC out there to use (I didn't even use a framework, just wrote 500 lines of wrapper logic so I could expose some REST services that handled JSON input/output and then built a connection pool for my Redis connections). If you know C# (or another .NET language) well enough, you can lean heavily on the type system and write automated tests for everything else and get all your errors/red tests displayed to you in your IDE. I hit very few runtime errors while building the services. It's also pleasantly surprising how easy ASP.net deploys seem to be: rsync your app folder to the web server; the app.config and bin/ folders inside ensure that all your dependencies and configuration move over to the target machine. Mono's ASP.net server seems to support almost everything Microsoft's does, so I think I only ran into one behavioral difference (and it was documented, albeit a little hard to find). ASP.net also has some of those same code reuse benefits you get with node.js, just in a different direction. Now if you have any native C# applications or libraries for doing interesting things, you can expose them as a web service trivially. JSIL's online sandbox (http://jsil.org/try http://jsil.org/try) is literally just the compiler libraries deployed to a linux box with a 100-line shim over them that does compilation and caching and error reporting.
fleitz 13y ago
Rails is a tradeoff, quick dev time, slow execution. It's not designed for low-profit per request applications. Recent benchmarks suggest about 400 req/sec on a $10 digiocean server suggesting if you max your machine 24/7 that you'd need to make at least 1 cent per million requests, if your profit margin is below this then rails would not be a good solution.
- joevandyk 13y ago
  There's no way you could serve 400 req/s with Rails on a $10 server for any sort of complex web app that requires data lookups and html rendering, partials, etc. Maybe possible if you cache everything, but that can be quite complex.
  - nwienert 13y ago
    Can you back up "complex"? I did extensive work on caching with 2u.fm on Rails and found it exceedingly simple, especially coming from Java or PHP. Plug in the dalli gem, and pass in the updated_at timestamp as part of the key. Edit: Perhaps if you had to re-write an app to support caching you'd run into trouble, but thats outside of the scope of this article. If you build a rails app, you plan for caching from the start.
    - aantix 13y ago
      Russian doll caching makes it even easier, if that's possible.
    - joevandyk 13y ago
      If users are shown different content, you can't cache easily. content_for quits working. etc. Caching in Rails is used to fix the symptom of Ruby/Rails having terrible performance for rendering templates/html/helpers/urls. It's fine if you have a small, simple site. For anything complicated/large, it can become a pain. By "complex", I mean something with hundreds of routes (I have close to a thousand), hundreds of controllers, hundreds of views/partials, etc. But if you have a small site that won't have lots of code, then sure, Rails is going to perform great.
lmm 13y ago
I hate rails and everything it stands for, but it's often the right choice for a business. The choice to develop faster in exchange for a heavier maintenance burden later on (which is what a dynamic language gives you) is often a good one. I don't see the concurrent request handling of node or django outweighing greater library availability and ease of hiring (often the hardest part of any business). True, any great engineer can learn a new language - but it takes time, time you may not have. (To say nothing of the inconvenient fact that many businesses can get by perfectly adequately with mediocre programmers).
mendicant 13y ago
I can agree to a point. But my question is, what if the app doesn't, and isn't ever meant to, support a large number of users? What if even with the concurrency issues, it's fast enough?
- fixxer 13y ago
  For those applications, I roll with Flask... which is still ranked higher than Rails. http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
tjbiddle 13y ago
So because RoR encourages unit tests, it's bad? You should be writing tests for all code - Not just dynamic languages. Compilers catch things like typos and type differences as you said; but there's so much more to test suites than that. Your last 3 points have nothing to do with the post; they're just essentially more information added to other headings. So your main point in the end is "Rails is slow" - I personally haven't dug too much into the performance of rails compared to others - But in general: It will improve - as all things do.
- michas 13y ago
  RoR doesn't "encourage" unit testing, it forces you to write thousands of meaningless unit tests which just make up for the lack of strong type system. Unit tests should test code logic, not parameter types.
  - drewinglis 13y ago
    There are gems like shoulda (https://github.com/thoughtbot/shoulda https://github.com/thoughtbot/shoulda) that make it really easy to do the 'types and typos' kind of unit tests. The marginal time required for any given class is negligible.
  - huntedsnark 13y ago
    Perhaps I've just missed it in the past but where does Rails advocate testing parameter types? There are examples of testing model validations, but you would want to test that in a strongly typed language as well. I don't think I've ever run across a test for something like "this id should be an integer" in Rails, if that's what you mean.
  - aparadja 13y ago
    Has RoR really started forcing you to write unit tests? By the thousands? I've written several RoR apps in the past where I didn't unit test at all. Perhaps I misunderstood you.
  - tjbiddle 13y ago
    Then don't write meaningless types. If you're needing to constantly test parameter types - Then you need to work harder on ensuring your input is the correct type before calling a method. It should subconsciously tell you to put more effort into knowing what you're working with. Unit tests are meant to test behavior - When I do X, I want Y to happen. Rspec is great for this - I did X, I should see A, B, and C get called - and if they return to me this value then my final result should be Z.
jsnk 13y ago
This is nothing but link baiting. At the end of the post he adds the qualifier. >If you already know how to get things done in Rails, you’re in a hurry, you don’t need to maintain what you’re building, and performance is not a concern, it might be a good choice. This is exactly why Rails will remain as the goto framework for many developers.
jtc331 13y ago
I immediately disregard anyone advocating Node.JS as always being a better alternative to Rails
deleted 13y ago
[deleted]
bascule 13y ago
Until Rails 4, the core framework didn’t even support concurrent request handling. Rails has supported multithreaded operation since 2.2: http://guides.rubyonrails.org/2_2_release_notes.html http://guides.rubyonrails.org/2_2_release_notes.html It never gained widespread adoption because it was off by default. Rails 4 turns it on by default on multithreaded web servers like Puma. And even in Rails 4, concurrent request handling is multiplexed on a single CPU core, leaving Rails unable to take advantage of the parallelism of modern architectures. This isn't true on JRuby, where Ruby threads are 1:1 with JVM threads (which are in turn 1:1 with native threads) that execute in parallel on multiple cores. At my employer (Square) we run many of our Rails apps in thread safe mode on top of JRuby, providing parallel request processing across multiple cores on a single JRuby/JVM instance.
- kawsper 13y ago
  How is the state of the thread-safety among gems? I have thought a lot about it, but the danger of having thread-issues in the included gems are a bit daunting to be honest.
  - bascule 13y ago
    Not as great as some other language ecosystems, however many people are using Sidekiq, a multithreaded job queue, successfully (and more generally, the Celluloid concurrency framework Sidekiq is based on)
- VLM 13y ago
  This meme is identical to the trashing mysql gets in 2013 because it doesn't have transactions. I'm sure when rails 50 ships people will still be claiming it can't multithread.
- el_bhs 13y ago
  JRuby is of course incompatible with C extensions to Rails; the place I used Rails had such dependencies, and so JRuby was not an option. I agree that JRuby is otherwise preferable to cRuby, though. I'd be curious to hear how Square has found ruby (independent of rails) to be from a maintenance standpoint.
SiliconAlley 13y ago
This assertion is, categorically and empirically, ridiculous. Yes, the runtime and framework are slow compared to something like go and Revel, but that is not the principal benefit of Rails. Rails' principal benefit is taking care of Maslow's Hierarchy of Needs, or whatever its analogue is for developers. The most recent Rails app I wrote has average render times of 7ms (excluding network latency) on dedicated hardware largely because most views can be rendered with just 3 memcached hits. What's more, implementing the nested caching strategy necessary to achieve this was pretty simple with the out-of-the-box capabilities of Rails 4. If I'm busy worrying about lower-level concerns it doesn't matter if my runtime and framework are blazing fast - I don't have the confidence or time to implement strategies like this, or at least not with nearly as little effort. The proof is in the pudding. Anecdotes to the contrary are welcome.
outworlder 13y ago
The problem is not Rails or Ruby, it's the community. There's this vibe that "Ruby is fast enough", which rubs into Rails. It manifests in many ways, not the least "developer time is more important". Well, it sure is. But one shouldn't have to make such a big tradeoff.
ef4 13y ago
Having spent a lot of time in both Rails and Node, the author's unequivocal endorsement of Node as better than Rails is just silly. Building a non-trivial app on Node requires that you do an awful lot of plumbing. Yes, the performance is very nice. And it's going to be great when the community grows up a bit and things start to Just Work with each other. But that day is not here yet. A lot of the components that people depend on are still really buggy. In the last three days I've had to debug and fix four bugs in other people's npm modules. The community's attention is spread all over the place, because there isn't one dominant way of doing things. People can't even agree on sane interoperable packaging for code that needs to work on both browsers and in node. It's a mess.
- mwcampbell 13y ago
  I don't see an unequivocal endorsement of Node in this rant. He only said that Node is better by his criteria if you really want to use a dynamic language.
- bwy 13y ago
  Plumbing is reduced quite a lot with the many great packages out there. Express?
  - ebiester 13y ago
    Except that nearly all of the cool kids in the community hate Express and nearly all of them believe that chaining micro-utilities together is the wave of the future. (Because, of course, researching 25 utilities takes the same time as researching one.) Express uses a convention that is not harmonious with many of the later best practices that have been emerging.
    - chenglou 13y ago
      Express is going this way too, check out 4.x's roadmap: https://github.com/visionmedia/express/wiki/4.x-roadmap https://github.com/visionmedia/express/wiki/4.x-roadmap Does the community hate Express? You can't really hate that much on it considering that TJ's one of those who's leading the movement: http://component.io http://component.io
anko 13y ago
The article is just wrong. > And it’s no wonder. Until Rails 4, the core framework didn’t even support concurrent request handling. And even in Rails 4, concurrent request handling is multiplexed on a single CPU core, leaving Rails unable to take advantage of the parallelism of modern architectures. Every single rails installation I have seen runs multi-process and takes advantage of multiple cores. And then he goes on to say something similar, but says thats a disadvantage because the processes aren't using shared memory to communicate and have to use memcached. The thing is, the rails model means rolling restarts are a lot easier, and you are lot more flexible with deployment strategies. > However, modern dynamic languages (and their incapacity to do the sort of meaningful pre-runtime verification of basic semantic well-being one expects from a compiler) place a burden on test coverage. Of course it is essential in any language to provide test coverage for core algorithms and other subtle aspects of a software module. However, when trying to “move fast" and get to market quickly, one shouldn’t have to write tests for every souped-up accessor method or trivial transformation. I'm still undecided about this angle. I simply don't find types to be a problem. While I agree fixed types are more performant, not dealing with types makes the code more fun because you're not held back from running it because you forgot a typecast. Tests are essential, but the flipside is that tests are quicker to write in a duck-typed language, too. The post of obviously trolling for clicks - even the title is saying nobody should use rails, and then it gives his times when you should use it at the bottom.
mbesto 13y ago
Twitter stopped growing because it chose to use Rails. Facebook stopped growing because it chose to use PHP. Pinterest stopped growing because it chose to use Django. Tumblr stopped growing because it chose to use PHP. Instagram stopped growing because it chose to use Django. StackOverflow stopped growing because it chose to use .NET. 37Signals stopped growing because it chose to use Rails. Groupon stopped growing because it chose to use Rails. </sarcasm> Can we end this debate already?
- renownedmedia 13y ago
  I don't see Node.js in that list. </troll>
  - vbsteven 13y ago
    Are there any companies of that size out there actually using Node in production?
    - AdrianRossouw 13y ago
      linkedin ?
    - Oculus 13y ago
      Google, I remember reading they use it internally like crazy.
      - edwinnathaniel 13y ago
        aaron's link seemed to disprove this.
    - bpicolo 13y ago
      I believe eBay said they used it for some things?
    - aaronbrethorst 13y ago
      http://venturebeat.com/2012/01/24/node-at-google-mozilla-yahoo/ http://venturebeat.com/2012/01/24/node-at-google-mozilla-yah...
conorh 13y ago
Recently I spent around an hour writing a small image resizing server in Ruby/Rails and Go (a fixed amount of time in each). I have several years of Rails experience and a year of Go experience. The Go server code was significantly more verbose, had far less features and worse error handling given the amount of time I had. I realize it is not the best comparison given that I am more experienced with Rails - I believe though that it would not be that much different even given a few years more Go experience. Yes the speed of Ruby and Rails can be frustrating, but I find it is often not needed, and if it is you can just rethink that piece or do it in a language that is more suited to the task. For development productivity I have yet to find a combination of language/framework that let me write maintainable code in as short a time (having worked over the years with frameworks in C/PHP/.NET/Java etc.).
williamcotton 13y ago
Rails is pretty awesome for building monolithic, CMS systems and other CRUD type apps. It's not awesome for a lot of other things. I don't really get the point of this article and the author seems to be contradicting himself all over the place. Like, how can you possibly talk about the pitfalls of dynamic typing and then a paragraph later tell people to use JavaScript or Python? WTF? Most problems at scale have to do with I/O, which Go isn't going to help you with. Your data stores are gonna be your pain points. And oh boy, talk about a mentality of premature optimization... seriously folks, worry more about making something that someone is gonna want to use than how many requests per second the thing can serve. Right now your product has zero requests per second so you could just fulfill them by hand if you had to.
frankblizzard 13y ago
Next week: Why nobody should rant about things he doesn't know very well, ever.
VLM 13y ago
"Why Nobody Should Use Rails For Anything, Ever" "If you already know how to get things done in Rails, you’re in a hurry, you don’t need to maintain what you’re building, and performance is not a concern, it might be a good choice. Otherwise, never." Take the first line and the last line and it sounds like Rails works perfect in an intra-nettish application as a front end to lots of data in a database. I have a lot of experience with that. It does work really well... for awhile. Needless to say only having a couple hundred theoretical possible users means that worrying about handling 400 reqs/second doesn't come up as an issue very much. His line about rails maintenance is dead on and the source of much internal push to run (not walk) away from rails. Push something out to users on rails 1.1 or whatever from 2007 and it won't run in 2013. A rails app needs constant continuous rewriting just so an apt-get upgrade won't kill it. Can't just deploy and walk away like a perl CGI script. Even if absolutely everything except rails stays the same, you can't just walk away and expect it to keep working. Building something on rails isn't a capital investment where you lean back and productivity/money pours out of it. On the continuum of this, its on the far edge of continuous labor required. More like a million dudes building the pyramids by hand than like one dude building a crane.
rhizome 13y ago
Alternate title: "Why Nobody Should Pay Attention To Ben Sigelman." There's a corollary to Betteridge's Law here someplace.
borlak 13y ago
The main turnoff for me when it comes to Rails is watching other major companies like Twitter completely rewrite their application away from Rails. Growing pains -- the kind of pains we all want to endure some day. If you are planning to grow, why wouldn't you start with something you know has an end game (like PHP or Java)? The often cited slowness of Rails, mixed with companies rewriting their codebases, and the flurry of vulnerabilities in the past year has caused me to take Rails less seriously.
- lazyjones 13y ago
  > The main turnoff for me when it comes to Rails is watching other major companies like Twitter completely rewrite their application away from Rails. I do not like Ruby and have never used Rails, but I feel your conclusion is wrong. Twitter would never have outgrown Rails (at that time they were already wildly successful) if it hadn't been the right (or at least a sufficient) choice for a prototype and initial production framework. An overwhelming majority of web sites will never grow to the point where they need to drop Rails for technical reasons and some of them will still be hugely successful. If you reach the point where Twitter needed to switch, congratulations, you will able to afford it easily.
vectorpush 13y ago
I'm not a Rails fan. I've overseen the development of about a dozen medium sized Ruby web apps in my career and Sinatra gets us up and going much faster. Also, the relative lack of magic compared to Rails makes uptake for new team members 10x quicker. With that stated, this article is pretty weak on substance for such a provocative title. I am tempted to flag it as sensational link-bait but Rails discussion is about as on-topic as it gets for HN so I'll resist. Anyway, the article fails to demonstrate "Why Nobody Should Use Rails". The concurrent requests issue is a valid criticism but that's about the only substantive claim in the article. People should use Rails when it's the right tool for the job. In my experience, Rails shines in situations when there isn't a strong architectural lead managing the project. Rails is very opinionated so it forces disparate developers into a more cohesive application structure where you'd normally end up with a spaghetti-code special. *edit: I was unaware of this but comments suggest Rails has supported concurrency for a long while, it was just off by default.
MrMcDowall 13y ago
It's 2013 and we're still seeing this Medieval theatre.
metaphorm 13y ago
I'm not even sure what a I just read. Did the author really mean to imply that statically typed languages don't require unit testing? Did the author really mean to claim that a low position in a single benchmark is a disqualifier for ever using a piece of technology? These are not reasonable things to say. Its just religious zealotry basically.
neya 13y ago
This is something from one of my previous write-ups for startups, specifically ones using rails: 1) If you KNOW FOR SURE your startup will face a lot of page views, requests etc. before hand (Example - Real estate portals like Airbnb, Trulia, etc), then you should not make the serious mistake of ignoring high performance frameworks beforehand. This could literally be anything, but the alternative I personally recommend is something Scala based [Read section 4 for WHY]. 2) As usual, use Rails (or django/similar) ALWAYS to build your v1 prototype. I say always because you will be incredibly surprised to see how much rails gets stuff done for you. While this is a huge advantage initially, this can also become a nightmare, later. Hence, I suggest you use rails only initially and not forever. (It's too long, please follow the link below) continue reading: https://news.ycombinator.com/item?id=6129107 https://news.ycombinator.com/item?id=6129107
deleted 13y ago
[deleted]
dnr 13y ago
Hi Ben! FWIW, my biggest issue with Rails (and much of what's produced by the Ruby community) is magic: I find the amount of stuff that's implicit, either depending on naming conventions, or automatic inclusion, or overriding default language behavior, or whatever, to be absolutely maddening. And as magic, it's mostly ungreppable and ungoogleable. Trying to figure out what exactly a given line of code does can take way too long. If I was writing an app from scratch as the only developer, I suppose this would be ok, but trying to maintain an existing app, or working as a team, this is a major problem. The (lack of) speed in my local development environment has been pretty annoying as well.
patrickwiseman 13y ago
Time to market and developer productivity matter so much more than capital expenses that it is ridiculous. I could buy another server in the time it takes to pay a developer for a days work. Not to mention, not all the features on a web application need to serve more than 2500 requests per second. The ones that do can be refactored into a web service with higher throughput or designed to be scaled separately from the rest of the features. It doesn't make sense to daisy-tank (to pick daisies with a tank) every single feature to support throughput it doesn't need at the expense of developer time. More over until there are analytics for what your users are using deciding what to optimize is entirely speculation. Bad science. The best way to get those analytics is to be live and the best way to be live is to have a built product. The benchmarks of linux on a physical machine rather than a virtual machine is not representative of performance for (gawd help me) cloud-centric deployments. These benchmarks assume the maximum benefit from compiler optimizations that would not be available on a virtualized machine. I'm not sure what compilers check more than syntactical errors. Those aren't any slower to fix in a dynamic language. I'd recommend checking on Sandi Metz on testing The rest is just language preference. And my preference is ruby. Python is fine with me too. Javascript makes me a sad panda, but it runs in all the browsers and it's a lot better with the magic of coffeescript.
bulte-rs 13y ago
Don't get me wrong: I love working with Rails (it's my Bread and butter basically). But sometimes I fall back to rants like these myself. Though mostly focussed in the whole "there's a gem for that" and "let's create instances because we can but complain about memory usage". Sometimes rankings is just that, a rant :P
deleted 13y ago
[deleted]
rartichoke 13y ago
I actually started to use Rails recently and came from Node and fooled around with Go in a past too. I switched because I found myself to be much more productive with Rails and it's really easy with Rails to do fairly complicated things. The article is jokes because everything he says about performance is irrelevant. You can get a single affordable VPS to kick out about 80 reqs/s with Rails 4 without any difficult caching/craziness on an app that's not super complicated but isn't a basic blog tutorial clone. The same app in Node might perform at 350 reqs/s but who the heck cares? 80 reqs/s is close to 7 MILLION requests a day. How many apps do you have with ~7 million requests a day, and how hard would it be to add a second a server in the mix... wow that's tough. Rails 4 is more than capable of responding with low latency too as long as you cache things responsibly. Fortunately that's brain dead simple with Rails since it handles all of the dirty work for you.
amerika_blog 13y ago
At this point, customers are asking me for active-update static page generation systems. I like the idea of frameworks, but at some point, you might as well write a plug-in for a CMS. I don't see this as a bad thing. If anything, it means more well-maintained code.
jincheker 13y ago
So brave to name a title like this, you have a lot to learn
gauravpandey 13y ago
While we are tearing down the whole article, in some corner of the world, Jeff atwood is neglecting us by having donuts and building discourse (http://www.discourse.org/ http://www.discourse.org/) on rails.
vysakh0 13y ago
> Use anything other than Rails Seriously ? Anything? > Django and Nodejs is better than Rails Why Django is better? The author seems to hook on to the concurrency aspect of nodejs(for what it was made) and compare with Rails. Does the author know there are projects like JRuby, Rubinus, there are multi-threaded servers like puma? One thing is very clear, the author is either writing articles for attention or does not like Rails' popularity. Classic link baiting! He has written 3 blog posts in total, all for the popularity.

157 points by mwcampbell 13y ago

This article is religion bait. TL;DR: For most things, I would put node at the top for many new web apps because of its surface similarity to frontend. -- After some evaluation in the past, Rails had some ghetto-like speed-bumps: I patched devise to use scrypt because the existing shit besides bcrypt was broken. devise-encryptable is a CWOT, don't bother. Maintainers promise all sorts of future dismissive bullshit but don't care, that's abundantly clear. Security in RoR is a fallacy. As a signal, almost none of the gems were signed, especially Rails. If you don't mind not being able to prove code the author pushed has not been tampered, by all means, run code from the public straight to production. I wrote a gem to make gem signing simple, waxseal, but since signing is optional, it's never going to change unless RubyGems has a major security incident. I just don't have the bandwidth to waste on a community that doesn't get it. -- As to what's coming up in the systems world: Go is more suitable for crunchy backend services typically in the systems domain of Erlang, Java or C(|++). C is portable at the expense of autotools and so much extra boilerplate to do anything. A lot of people that matter know and are comfortable with C, so libs and kernels will use that for sometime in the future. Go or similar would take decades to adopt because there's not yet enough compelling chicken-and-egg evidence to change to a different flavor of Turing-completeness. Go is qualitatively solid. It addresses entire categories of software engineering problems that happen at scale. If you're doing bank software, you're probably stuck with a mostly JVM &| CLR runtime stack.

mshahriarinia 13y ago

See where codeigniter, cakephp, django are all from rails? Just look at http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ You are comparing a language to a CMS?

mwcampbell 13y ago

I submitted this because I thought it might make for some good discussion, but: > This post is my attempt to be fair, objective, and, by consequence, unrelentingly negative about Rails :) To me it seems arrogant to assume that you are being fair and objective when you only point out the negative attributes of something. I'd be more inclined to assume that there are positives I'm overlooking, that might even outweigh the negatives. Especially for something as beloved by developers as Rails. What evidence is there that running a process per core has a significant negative effect on throughput and/or latency in practice? Benchmarks? Data from developers who tried both approaches while holding all else constant? (The latter is probably quite difficult in practice.) Also, JRuby supports real threads without a global interpreter lock. I think I agree with this post about the benefits of static typing, though.

kevingadd 13y ago
Objectivity is a separate thing from the topic of the post. He came into it wanting to write an explanation of why he thinks you should never use Rails, and attempted to be objective about it by including data and describing some caveats to his argument (i.e. scenarios where you might be able to get away with it). A post that says 'why you should or shouldn't use rails' is a different post and no more or less implicitly objective. Objectivity does not mean 'covering two sides of an argument'; sometimes one side is less or more supported than the other and sometimes you simply don't have the knowledge to cover both sides fairly.
hatsix 13y ago
... also, the evidence for the performance is the benchmark image in the sidebar.
el_bhs 13y ago
(I wrote TFA -- didn't expect it up on HN!) I agree that the post would be more compelling if I wrote a benchmark to demonstrate how much faster an in-memory cache is than an off-process or off-machine cache. From first principles, though, I believe it should be obvious (yes?) that the ~300 nanoseconds it takes to grab a read lock and read from main memory is going to beat the ~1000000 nanoseconds it takes to get a response back from a remote cache over the network. Inasmuch as an application blocks on such cache reads, these sorts of things add up to troublesome latency numbers (and Rails – or at least dallistore – does indeed block on reads like these). JRuby was off the table for the place I used rails due to reliance on some C extensions. And I'm sorry if the argument seemed arrogant: I was being tongue-in-cheek about the "unrelenting negativity" part. My point about objectivity was that I tried not to rely on my opinions as much as demonstrable statements. That said, I didn't take the time to actually demonstrate most of those, and for that, shame on me.
- mwcampbell 13y ago
  How about the performance difference between an in-process cache and a memcached instance on localhost? Surely anyone who knows what they're doing will run the cache on the same machine as the web server. (I guess that makes a good argument for not using a PaaS that gives you too little control over locality.)

jfb 13y ago

I don't like Rails, and I don't like Ruby, but this wasn't a particularly enlightening piece. He doesn't explain why using something like Django in place of Rails makes sense; he handwaves a bit over Node. There's some statically typed language dogma, and that's it. I'd love to read a good hit piece on Rails, written by someone who spends the time to lay out a strong technical justification for their opinion. This was disappointingly Twitterish.

ThunderChief 13y ago
I completely agree. This piece highlights the inherent drawback of all dynamic languages: performance. We've been through the performance argument too many times to count with both Rails and PHP. I don't know what kind of taste I would have if I were to follow this piece as advice. Am I expected to do CGI in straight C? Ridiculous.
amalag 13y ago
With this article python==ruby because they are dynamic
- jfb 13y ago
  He sort of feints towards talking about why Django might be faster, but then doesn't. It's fundamentally an entirely vapid piece.
ape4 13y ago
For a midsized to big project static typing is really nice. eg A few years ago I had a perl project that only let you know a function was missing at run time (ie when the user asked for that code).
- jfb 13y ago
  That sounds ... less than great. I'm a fan of static typing, no question. I'm just not impressed with this article's handwaving.
- Mithaldu 13y ago

degobah 13y ago

Basically the post just says: 1. Rails is slow 2. Dynamic languages are bad

deleted 13y ago
[deleted]
- lclarkmichalek 13y ago
  Oh god, please don't slight Go, we'll have tptacek in this thread in no time
  - chc 13y ago
    Last I checked, tptacek is actually a big fan of Rails.
  - deleted 13y ago
    [deleted]
    - lclarkmichalek 13y ago
      I agree with your comment, and I shan't try and justify my comment, for it is libellous and unjustified. However, I guess I could have used "failed to describe Go with an adjective that you used in a positive context when discussing another language" over "slight". That said, it doesn't roll off the tongue as well.
everettForth 13y ago
It's worse than that. He links to a set of benchmarks to demonstrate that rails is slow without even considering the caching utilities that rails provides. Who bases their sole criterion for a web framework on speed, and then ignores the baked-in caching functionality that a framework provides?
- bhauer 13y ago
  To be clear, the particular test cited is expressly designed to exercise the framework and its ORM+database connectivity. None of our present test types permit the use of a reverse proxy cache because we are specifically interested in measuring the performance of the frameworks/platforms and not the performance of reverse proxy software; you can find such tests elsewhere. Further, reverse proxies are only suitable for a subset of real-world applications where it is acceptable to cache output for consumption by a wide audience. In other words, Rails wasn't unique in being tested without a preferred reverse proxy. Every single framework on that list was tested without a reverse proxy. A future test type [1] will exercise back-end caching (e.g., memcached in the case of Rails), but we are not planning to ever include reverse proxies (of any form) in the project. [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/374 https://github.com/TechEmpower/FrameworkBenchmarks/issues/37...

gphil 13y ago

I have my fair share of issues with Rails, but I think this is a bit extreme. When I look into other ecosystems, the amount of library support for building modern web applications just doesn't compare. I think it's this aspect of Rails that really helps get from zero to viable product so quickly. That said, the performance issues do start to take a toll after a while. And forget it if you want to do something counter to the way Rails want you to do it. Everything is a trade-off.

aaronbrethorst 13y ago

Why do I care if my simple CRUD app can only use a single CPU core? Because someday I might have millions of users and then I'll have Twitter's old problems? I'd love to have to Twitter's problems. Use the right tool for the job. And claiming that Rails is never the right tool is just silly.

amalag 13y ago
I guess in the authors world there are only million user applications. I agree that it is silly.
- el_bhs 13y ago
  I can't resist (this is the OP): you are missing the point. It's not just throughput, it's high-percentile latency. Latency is critical if you have 1 billion users or 100 users, and it is difficult to bring the high percentiles of the latency distribution down into reasonable territory on Rails since, by default, all operations are essentially serialized.
  - mwcampbell 13y ago
    I guess the problem of high-percentile latency is not widely understood; I'm not sure I understand it myself. Can you explain in more detail? In particular, are you talking about requests that take a while to complete because they have some complex processing, or requests that take a long time to complete because they can't be processed until some other long-running request finishes? The bit about everything being serialized suggests that the main concern is the latter. Does this apply even when using multiple threads under the C Ruby implementation? Why does running multiple web server processes on the same machine not mitigate the problem? BTW, I don't use Rails or Ruby, but I do use Python for web apps at work (currently CPython, GIL and all). I'm curious to find out if this problem of high-percentile latency applies to Python as well.
    - el_bhs 13y ago
      Sure. So, for any black-box service endpoint, the latency for any given request is obviously just the time it takes for that operation to complete. Ideally one measures both end-to-end latency from the client and server-side latency in order to understand the impact of the network and, for high-throughput applications, any kernel buffering that takes place. All of that is obvious, I imagine. By "high-percentile latency", I'm referring to percentiles of a distribution of all latency measurements gathered from a given endpoint over some period of time. If you imagine that distribution as a frequency histogram, the horizontal axis ends up being buckets of latency ranges (e.g., 0-10ms, 10-20ms, 20-30ms, etc), and the bars themselves of course represent the number of samples in each such bucket. What we want to do is determine which bucket contains the 95th percentile (or 99th, or 99.9th) latency value. You can see such a latency distribution on page 10 of this paper which I published while at Google: http://research.google.com/pubs/pub36356.html Anyway, it is a mouthful to explain latency percentiles, but in practice it ends up being an extremely useful measurement. Average latency is just not that important in interactive applications (webapps or otherwise): what you should be measuring is outlier latency. Every service you've ever heard of at google has pagers set to track high-percentile latency over the trailing 1m or 5m or 10m (etc) for user-facing endpoints. Coming back to Rails: latency is of course a concern through the entire stack. The reason Rails is so problematic (in my experience) is that people writing gems never seem to realize when they can and should be doing things in parallel, with the possible exception of carefully crafted SQL queries that get parallelized in the database. The Node.js community is a little better in that they don't block on all function calls by convention like folks do in Rails, but it's really all just a "cultural" thing. I don't know off the top of my head how things generally work in Django... One final thing: GC is a nightmare for high-percentile latency, and any dynamic language has to contend with it. Especially if multiple requests are processed concurrently, which is of course necessary to get reasonable throughput. Hope this helps.

facorreia 13y ago

I'll share my personal opinion and experience. For reasons like this, and I would add, scary security history, I decided against using Rails. I've experimented with Django and lightweight Python frameworks, Node.js and Java 6 EE, among others. What has worked best for me was C# + ASP.NET MVC. The C# language has several features that I find appealing and lead to clean, efficient code (such as dynamic, lambda, LINQ and async, among others). The modern incarnation of ASP.NET running under IIS is quite efficient and productive both in development, profiling & diagnostics, and in production.

lmm 13y ago
Have you tried F#? To my eye it takes those features you mention liking, and goes further with them. (Scala guy myself)
- facorreia 13y ago
  I took a look at F# but for the kind of applications I write, I prefer to follow mainstream, for the bigger ecosystem and less surprises, and C# is powerful enough for me.
  - dragonwriter 13y ago
    Isn't one of the selling points of .NET that any language on the platform has full access to the whole .NET ecosystem?
    - facorreia 13y ago
      I mean ecosystem in a broader sense, including help on Stack Overflow, sample code, etc.
kevingadd 13y ago
I've done some web dev with node, python (GAE) and php. I ended up using C# + mono's web server for a recent project and was pleasantly surprised. ASP.net is showing its age but there are some solid libraries, reasonably comprehensive documentation, and some nice new frameworks like MVC out there to use (I didn't even use a framework, just wrote 500 lines of wrapper logic so I could expose some REST services that handled JSON input/output and then built a connection pool for my Redis connections). If you know C# (or another .NET language) well enough, you can lean heavily on the type system and write automated tests for everything else and get all your errors/red tests displayed to you in your IDE. I hit very few runtime errors while building the services. It's also pleasantly surprising how easy ASP.net deploys seem to be: rsync your app folder to the web server; the app.config and bin/ folders inside ensure that all your dependencies and configuration move over to the target machine. Mono's ASP.net server seems to support almost everything Microsoft's does, so I think I only ran into one behavioral difference (and it was documented, albeit a little hard to find). ASP.net also has some of those same code reuse benefits you get with node.js, just in a different direction. Now if you have any native C# applications or libraries for doing interesting things, you can expose them as a web service trivially. JSIL's online sandbox (http://jsil.org/try http://jsil.org/try) is literally just the compiler libraries deployed to a linux box with a 100-line shim over them that does compilation and caching and error reporting.

fleitz 13y ago

Rails is a tradeoff, quick dev time, slow execution. It's not designed for low-profit per request applications. Recent benchmarks suggest about 400 req/sec on a $10 digiocean server suggesting if you max your machine 24/7 that you'd need to make at least 1 cent per million requests, if your profit margin is below this then rails would not be a good solution.

joevandyk 13y ago
There's no way you could serve 400 req/s with Rails on a $10 server for any sort of complex web app that requires data lookups and html rendering, partials, etc. Maybe possible if you cache everything, but that can be quite complex.
- nwienert 13y ago
  Can you back up "complex"? I did extensive work on caching with 2u.fm on Rails and found it exceedingly simple, especially coming from Java or PHP. Plug in the dalli gem, and pass in the updated_at timestamp as part of the key. Edit: Perhaps if you had to re-write an app to support caching you'd run into trouble, but thats outside of the scope of this article. If you build a rails app, you plan for caching from the start.
  - aantix 13y ago
    Russian doll caching makes it even easier, if that's possible.
  - joevandyk 13y ago
    If users are shown different content, you can't cache easily. content_for quits working. etc. Caching in Rails is used to fix the symptom of Ruby/Rails having terrible performance for rendering templates/html/helpers/urls. It's fine if you have a small, simple site. For anything complicated/large, it can become a pain. By "complex", I mean something with hundreds of routes (I have close to a thousand), hundreds of controllers, hundreds of views/partials, etc. But if you have a small site that won't have lots of code, then sure, Rails is going to perform great.

lmm 13y ago

I hate rails and everything it stands for, but it's often the right choice for a business. The choice to develop faster in exchange for a heavier maintenance burden later on (which is what a dynamic language gives you) is often a good one. I don't see the concurrent request handling of node or django outweighing greater library availability and ease of hiring (often the hardest part of any business). True, any great engineer can learn a new language - but it takes time, time you may not have. (To say nothing of the inconvenient fact that many businesses can get by perfectly adequately with mediocre programmers).

mendicant 13y ago

I can agree to a point. But my question is, what if the app doesn't, and isn't ever meant to, support a large number of users? What if even with the concurrency issues, it's fast enough?

fixxer 13y ago
For those applications, I roll with Flask... which is still ranked higher than Rails. http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/

tjbiddle 13y ago

So because RoR encourages unit tests, it's bad? You should be writing tests for all code - Not just dynamic languages. Compilers catch things like typos and type differences as you said; but there's so much more to test suites than that. Your last 3 points have nothing to do with the post; they're just essentially more information added to other headings. So your main point in the end is "Rails is slow" - I personally haven't dug too much into the performance of rails compared to others - But in general: It will improve - as all things do.

michas 13y ago
RoR doesn't "encourage" unit testing, it forces you to write thousands of meaningless unit tests which just make up for the lack of strong type system. Unit tests should test code logic, not parameter types.
- drewinglis 13y ago
  There are gems like shoulda (https://github.com/thoughtbot/shoulda https://github.com/thoughtbot/shoulda) that make it really easy to do the 'types and typos' kind of unit tests. The marginal time required for any given class is negligible.
- huntedsnark 13y ago
  Perhaps I've just missed it in the past but where does Rails advocate testing parameter types? There are examples of testing model validations, but you would want to test that in a strongly typed language as well. I don't think I've ever run across a test for something like "this id should be an integer" in Rails, if that's what you mean.
- aparadja 13y ago
  Has RoR really started forcing you to write unit tests? By the thousands? I've written several RoR apps in the past where I didn't unit test at all. Perhaps I misunderstood you.
- tjbiddle 13y ago
  Then don't write meaningless types. If you're needing to constantly test parameter types - Then you need to work harder on ensuring your input is the correct type before calling a method. It should subconsciously tell you to put more effort into knowing what you're working with. Unit tests are meant to test behavior - When I do X, I want Y to happen. Rspec is great for this - I did X, I should see A, B, and C get called - and if they return to me this value then my final result should be Z.

jsnk 13y ago

This is nothing but link baiting. At the end of the post he adds the qualifier. >If you already know how to get things done in Rails, you’re in a hurry, you don’t need to maintain what you’re building, and performance is not a concern, it might be a good choice. This is exactly why Rails will remain as the goto framework for many developers.

jtc331 13y ago

I immediately disregard anyone advocating Node.JS as always being a better alternative to Rails

deleted 13y ago

[deleted]

bascule 13y ago

Until Rails 4, the core framework didn’t even support concurrent request handling. Rails has supported multithreaded operation since 2.2: http://guides.rubyonrails.org/2_2_release_notes.html http://guides.rubyonrails.org/2_2_release_notes.html It never gained widespread adoption because it was off by default. Rails 4 turns it on by default on multithreaded web servers like Puma. And even in Rails 4, concurrent request handling is multiplexed on a single CPU core, leaving Rails unable to take advantage of the parallelism of modern architectures. This isn't true on JRuby, where Ruby threads are 1:1 with JVM threads (which are in turn 1:1 with native threads) that execute in parallel on multiple cores. At my employer (Square) we run many of our Rails apps in thread safe mode on top of JRuby, providing parallel request processing across multiple cores on a single JRuby/JVM instance.

kawsper 13y ago
How is the state of the thread-safety among gems? I have thought a lot about it, but the danger of having thread-issues in the included gems are a bit daunting to be honest.
- bascule 13y ago
  Not as great as some other language ecosystems, however many people are using Sidekiq, a multithreaded job queue, successfully (and more generally, the Celluloid concurrency framework Sidekiq is based on)
VLM 13y ago
This meme is identical to the trashing mysql gets in 2013 because it doesn't have transactions. I'm sure when rails 50 ships people will still be claiming it can't multithread.
el_bhs 13y ago
JRuby is of course incompatible with C extensions to Rails; the place I used Rails had such dependencies, and so JRuby was not an option. I agree that JRuby is otherwise preferable to cRuby, though. I'd be curious to hear how Square has found ruby (independent of rails) to be from a maintenance standpoint.

SiliconAlley 13y ago

This assertion is, categorically and empirically, ridiculous. Yes, the runtime and framework are slow compared to something like go and Revel, but that is not the principal benefit of Rails. Rails' principal benefit is taking care of Maslow's Hierarchy of Needs, or whatever its analogue is for developers. The most recent Rails app I wrote has average render times of 7ms (excluding network latency) on dedicated hardware largely because most views can be rendered with just 3 memcached hits. What's more, implementing the nested caching strategy necessary to achieve this was pretty simple with the out-of-the-box capabilities of Rails 4. If I'm busy worrying about lower-level concerns it doesn't matter if my runtime and framework are blazing fast - I don't have the confidence or time to implement strategies like this, or at least not with nearly as little effort. The proof is in the pudding. Anecdotes to the contrary are welcome.

outworlder 13y ago

The problem is not Rails or Ruby, it's the community. There's this vibe that "Ruby is fast enough", which rubs into Rails. It manifests in many ways, not the least "developer time is more important". Well, it sure is. But one shouldn't have to make such a big tradeoff.

ef4 13y ago

Having spent a lot of time in both Rails and Node, the author's unequivocal endorsement of Node as better than Rails is just silly. Building a non-trivial app on Node requires that you do an awful lot of plumbing. Yes, the performance is very nice. And it's going to be great when the community grows up a bit and things start to Just Work with each other. But that day is not here yet. A lot of the components that people depend on are still really buggy. In the last three days I've had to debug and fix four bugs in other people's npm modules. The community's attention is spread all over the place, because there isn't one dominant way of doing things. People can't even agree on sane interoperable packaging for code that needs to work on both browsers and in node. It's a mess.

mwcampbell 13y ago
I don't see an unequivocal endorsement of Node in this rant. He only said that Node is better by his criteria if you really want to use a dynamic language.
bwy 13y ago
Plumbing is reduced quite a lot with the many great packages out there. Express?
- ebiester 13y ago
  Except that nearly all of the cool kids in the community hate Express and nearly all of them believe that chaining micro-utilities together is the wave of the future. (Because, of course, researching 25 utilities takes the same time as researching one.) Express uses a convention that is not harmonious with many of the later best practices that have been emerging.
  - chenglou 13y ago
    Express is going this way too, check out 4.x's roadmap: https://github.com/visionmedia/express/wiki/4.x-roadmap https://github.com/visionmedia/express/wiki/4.x-roadmap Does the community hate Express? You can't really hate that much on it considering that TJ's one of those who's leading the movement: http://component.io http://component.io

anko 13y ago

The article is just wrong. > And it’s no wonder. Until Rails 4, the core framework didn’t even support concurrent request handling. And even in Rails 4, concurrent request handling is multiplexed on a single CPU core, leaving Rails unable to take advantage of the parallelism of modern architectures. Every single rails installation I have seen runs multi-process and takes advantage of multiple cores. And then he goes on to say something similar, but says thats a disadvantage because the processes aren't using shared memory to communicate and have to use memcached. The thing is, the rails model means rolling restarts are a lot easier, and you are lot more flexible with deployment strategies. > However, modern dynamic languages (and their incapacity to do the sort of meaningful pre-runtime verification of basic semantic well-being one expects from a compiler) place a burden on test coverage. Of course it is essential in any language to provide test coverage for core algorithms and other subtle aspects of a software module. However, when trying to “move fast" and get to market quickly, one shouldn’t have to write tests for every souped-up accessor method or trivial transformation. I'm still undecided about this angle. I simply don't find types to be a problem. While I agree fixed types are more performant, not dealing with types makes the code more fun because you're not held back from running it because you forgot a typecast. Tests are essential, but the flipside is that tests are quicker to write in a duck-typed language, too. The post of obviously trolling for clicks - even the title is saying nobody should use rails, and then it gives his times when you should use it at the bottom.

mbesto 13y ago

Twitter stopped growing because it chose to use Rails. Facebook stopped growing because it chose to use PHP. Pinterest stopped growing because it chose to use Django. Tumblr stopped growing because it chose to use PHP. Instagram stopped growing because it chose to use Django. StackOverflow stopped growing because it chose to use .NET. 37Signals stopped growing because it chose to use Rails. Groupon stopped growing because it chose to use Rails. </sarcasm> Can we end this debate already?

renownedmedia 13y ago
I don't see Node.js in that list. </troll>
- vbsteven 13y ago
  Are there any companies of that size out there actually using Node in production?
  - AdrianRossouw 13y ago
    linkedin ?
  - Oculus 13y ago
    Google, I remember reading they use it internally like crazy.
    - edwinnathaniel 13y ago
      aaron's link seemed to disprove this.
  - bpicolo 13y ago
    I believe eBay said they used it for some things?
  - aaronbrethorst 13y ago
    http://venturebeat.com/2012/01/24/node-at-google-mozilla-yahoo/ http://venturebeat.com/2012/01/24/node-at-google-mozilla-yah...

conorh 13y ago

Recently I spent around an hour writing a small image resizing server in Ruby/Rails and Go (a fixed amount of time in each). I have several years of Rails experience and a year of Go experience. The Go server code was significantly more verbose, had far less features and worse error handling given the amount of time I had. I realize it is not the best comparison given that I am more experienced with Rails - I believe though that it would not be that much different even given a few years more Go experience. Yes the speed of Ruby and Rails can be frustrating, but I find it is often not needed, and if it is you can just rethink that piece or do it in a language that is more suited to the task. For development productivity I have yet to find a combination of language/framework that let me write maintainable code in as short a time (having worked over the years with frameworks in C/PHP/.NET/Java etc.).

williamcotton 13y ago

Rails is pretty awesome for building monolithic, CMS systems and other CRUD type apps. It's not awesome for a lot of other things. I don't really get the point of this article and the author seems to be contradicting himself all over the place. Like, how can you possibly talk about the pitfalls of dynamic typing and then a paragraph later tell people to use JavaScript or Python? WTF? Most problems at scale have to do with I/O, which Go isn't going to help you with. Your data stores are gonna be your pain points. And oh boy, talk about a mentality of premature optimization... seriously folks, worry more about making something that someone is gonna want to use than how many requests per second the thing can serve. Right now your product has zero requests per second so you could just fulfill them by hand if you had to.

frankblizzard 13y ago

Next week: Why nobody should rant about things he doesn't know very well, ever.

VLM 13y ago

"Why Nobody Should Use Rails For Anything, Ever" "If you already know how to get things done in Rails, you’re in a hurry, you don’t need to maintain what you’re building, and performance is not a concern, it might be a good choice. Otherwise, never." Take the first line and the last line and it sounds like Rails works perfect in an intra-nettish application as a front end to lots of data in a database. I have a lot of experience with that. It does work really well... for awhile. Needless to say only having a couple hundred theoretical possible users means that worrying about handling 400 reqs/second doesn't come up as an issue very much. His line about rails maintenance is dead on and the source of much internal push to run (not walk) away from rails. Push something out to users on rails 1.1 or whatever from 2007 and it won't run in 2013. A rails app needs constant continuous rewriting just so an apt-get upgrade won't kill it. Can't just deploy and walk away like a perl CGI script. Even if absolutely everything except rails stays the same, you can't just walk away and expect it to keep working. Building something on rails isn't a capital investment where you lean back and productivity/money pours out of it. On the continuum of this, its on the far edge of continuous labor required. More like a million dudes building the pyramids by hand than like one dude building a crane.

rhizome 13y ago

Alternate title: "Why Nobody Should Pay Attention To Ben Sigelman." There's a corollary to Betteridge's Law here someplace.

borlak 13y ago

The main turnoff for me when it comes to Rails is watching other major companies like Twitter completely rewrite their application away from Rails. Growing pains -- the kind of pains we all want to endure some day. If you are planning to grow, why wouldn't you start with something you know has an end game (like PHP or Java)? The often cited slowness of Rails, mixed with companies rewriting their codebases, and the flurry of vulnerabilities in the past year has caused me to take Rails less seriously.

lazyjones 13y ago
> The main turnoff for me when it comes to Rails is watching other major companies like Twitter completely rewrite their application away from Rails. I do not like Ruby and have never used Rails, but I feel your conclusion is wrong. Twitter would never have outgrown Rails (at that time they were already wildly successful) if it hadn't been the right (or at least a sufficient) choice for a prototype and initial production framework. An overwhelming majority of web sites will never grow to the point where they need to drop Rails for technical reasons and some of them will still be hugely successful. If you reach the point where Twitter needed to switch, congratulations, you will able to afford it easily.

vectorpush 13y ago

I'm not a Rails fan. I've overseen the development of about a dozen medium sized Ruby web apps in my career and Sinatra gets us up and going much faster. Also, the relative lack of magic compared to Rails makes uptake for new team members 10x quicker. With that stated, this article is pretty weak on substance for such a provocative title. I am tempted to flag it as sensational link-bait but Rails discussion is about as on-topic as it gets for HN so I'll resist. Anyway, the article fails to demonstrate "Why Nobody Should Use Rails". The concurrent requests issue is a valid criticism but that's about the only substantive claim in the article. People should use Rails when it's the right tool for the job. In my experience, Rails shines in situations when there isn't a strong architectural lead managing the project. Rails is very opinionated so it forces disparate developers into a more cohesive application structure where you'd normally end up with a spaghetti-code special. *edit: I was unaware of this but comments suggest Rails has supported concurrency for a long while, it was just off by default.

MrMcDowall 13y ago

It's 2013 and we're still seeing this Medieval theatre.

metaphorm 13y ago

I'm not even sure what a I just read. Did the author really mean to imply that statically typed languages don't require unit testing? Did the author really mean to claim that a low position in a single benchmark is a disqualifier for ever using a piece of technology? These are not reasonable things to say. Its just religious zealotry basically.

neya 13y ago

This is something from one of my previous write-ups for startups, specifically ones using rails: 1) If you KNOW FOR SURE your startup will face a lot of page views, requests etc. before hand (Example - Real estate portals like Airbnb, Trulia, etc), then you should not make the serious mistake of ignoring high performance frameworks beforehand. This could literally be anything, but the alternative I personally recommend is something Scala based [Read section 4 for WHY]. 2) As usual, use Rails (or django/similar) ALWAYS to build your v1 prototype. I say always because you will be incredibly surprised to see how much rails gets stuff done for you. While this is a huge advantage initially, this can also become a nightmare, later. Hence, I suggest you use rails only initially and not forever. (It's too long, please follow the link below) continue reading: https://news.ycombinator.com/item?id=6129107 https://news.ycombinator.com/item?id=6129107

deleted 13y ago

[deleted]

dnr 13y ago

Hi Ben! FWIW, my biggest issue with Rails (and much of what's produced by the Ruby community) is magic: I find the amount of stuff that's implicit, either depending on naming conventions, or automatic inclusion, or overriding default language behavior, or whatever, to be absolutely maddening. And as magic, it's mostly ungreppable and ungoogleable. Trying to figure out what exactly a given line of code does can take way too long. If I was writing an app from scratch as the only developer, I suppose this would be ok, but trying to maintain an existing app, or working as a team, this is a major problem. The (lack of) speed in my local development environment has been pretty annoying as well.

patrickwiseman 13y ago

Time to market and developer productivity matter so much more than capital expenses that it is ridiculous. I could buy another server in the time it takes to pay a developer for a days work. Not to mention, not all the features on a web application need to serve more than 2500 requests per second. The ones that do can be refactored into a web service with higher throughput or designed to be scaled separately from the rest of the features. It doesn't make sense to daisy-tank (to pick daisies with a tank) every single feature to support throughput it doesn't need at the expense of developer time. More over until there are analytics for what your users are using deciding what to optimize is entirely speculation. Bad science. The best way to get those analytics is to be live and the best way to be live is to have a built product. The benchmarks of linux on a physical machine rather than a virtual machine is not representative of performance for (gawd help me) cloud-centric deployments. These benchmarks assume the maximum benefit from compiler optimizations that would not be available on a virtualized machine. I'm not sure what compilers check more than syntactical errors. Those aren't any slower to fix in a dynamic language. I'd recommend checking on Sandi Metz on testing The rest is just language preference. And my preference is ruby. Python is fine with me too. Javascript makes me a sad panda, but it runs in all the browsers and it's a lot better with the magic of coffeescript.

bulte-rs 13y ago

Don't get me wrong: I love working with Rails (it's my Bread and butter basically). But sometimes I fall back to rants like these myself. Though mostly focussed in the whole "there's a gem for that" and "let's create instances because we can but complain about memory usage". Sometimes rankings is just that, a rant :P

deleted 13y ago

[deleted]

rartichoke 13y ago

I actually started to use Rails recently and came from Node and fooled around with Go in a past too. I switched because I found myself to be much more productive with Rails and it's really easy with Rails to do fairly complicated things. The article is jokes because everything he says about performance is irrelevant. You can get a single affordable VPS to kick out about 80 reqs/s with Rails 4 without any difficult caching/craziness on an app that's not super complicated but isn't a basic blog tutorial clone. The same app in Node might perform at 350 reqs/s but who the heck cares? 80 reqs/s is close to 7 MILLION requests a day. How many apps do you have with ~7 million requests a day, and how hard would it be to add a second a server in the mix... wow that's tough. Rails 4 is more than capable of responding with low latency too as long as you cache things responsibly. Fortunately that's brain dead simple with Rails since it handles all of the dirty work for you.

amerika_blog 13y ago

At this point, customers are asking me for active-update static page generation systems. I like the idea of frameworks, but at some point, you might as well write a plug-in for a CMS. I don't see this as a bad thing. If anything, it means more well-maintained code.

jincheker 13y ago

So brave to name a title like this, you have a lot to learn

gauravpandey 13y ago

While we are tearing down the whole article, in some corner of the world, Jeff atwood is neglecting us by having donuts and building discourse (http://www.discourse.org/ http://www.discourse.org/) on rails.

vysakh0 13y ago

> Use anything other than Rails Seriously ? Anything? > Django and Nodejs is better than Rails Why Django is better? The author seems to hook on to the concurrency aspect of nodejs(for what it was made) and compare with Rails. Does the author know there are projects like JRuby, Rubinus, there are multi-threaded servers like puma? One thing is very clear, the author is either writing articles for attention or does not like Rails' popularity. Classic link baiting! He has written 3 blog posts in total, all for the popularity.