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

There was a time when I used to advocate my fellow folks here at HN (and possibly even reddit) to go for a framework built on faster languages like GoLang or Scala or even using platforms like Node.js and avoid slower ones like Rails. Now, it's time for me to apologize to the community for giving you wrong advice [1]. Turns out I could never have been more wrong.

I wish I could write a long post describing each of the WHY's, but I'll be more succinct, this time:

1)If you can throw money at something at something and scale, then you're as good as gold. Rails allows you to do this. Oh, and supportive statements from Pinterest guys on the same topic - [2].

2) The speed of a language has nothing to do with the success of your business. NOTHING. You can go with the world's slowest language and still be successful. Best example of this is Basecamp itself.

As a matter of fact, even many of the popular sites (heck, even popular porn sites) still run on PHP (PHP was one of the slowest from the frameworks speed comparison conducted by Techempower - [3]).

3) The actual thing you want to be able to do is quickly iterate on your product and constantly have it evolve. This is only possible if you have a complete framework that doesn't force you to re-invent the wheel. For example, when I wrote a framework by myself in GoLang, Scala, I found myself focusing too much on basic stuff like authentication, instead of focusing on the features that are needed for the actual product.

4) (P.S this is my personal opinion) I've tried all major frameworks out there and I've come back to Rails again. Why? Because its philosophy resonates with me (yes, now it does). For me, the three most important elements for a successful product are - Speed, Reliability, Consistency. Rails provides me with all these three. (And please try Puma, it's pretty impressive!).

As for me, the ability to seamlessly integrate SASS, Compass and HAML (which help me divide my product development time multiple folds) makes Rails a clear winner for me. And now Active Job, Deliver Later, Adequate Record, Web Console now make Rails much more complete than ever. (Thank you DHH!)

In the last 6 months, I've written 4 complete products for 4 different people (one of them, being mine) that is well tested and works perfectly as intended. Compare this to something like last year where I spent 2-3 months writing just a single software product (for myself) while I was trying to use GoLang (<- or insert another faster language here) (because I also had to take care of all the other things like Authentication, etc). The point is, ultimately you want to run a successful business. And if you're worried if the slowness of your language will hinder it's growth, then nope. That will not happen. I hope this helps someone.


[1] https://news.ycombinator.com/threads?id=neya&next=6993616

[2] http://highscalability.com/blog/2013/4/15/scaling-pinterest-...

[3] http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

My biggest frustration with Rails at the moment is maintenance of my Rails apps.

Rails versions come out quickly, and old versions stop being supported. And it's become a non-trivial part of my time running the treadmill of keeping all my Rails apps up to date, along with compatible dependencies.

I realize this kind of goes with the program. Rails all-volunteer development manages to produce a reasonably powerful and non-buggy product that for the most part is constantly getting better; the cost of this is quick evolution and a maintenance burden for users.

I don't think I'd like the tradeoff better choosing a less mature/powerful/robust framework, but it is increasingly frustrating.

(The fact that some of the things Rails adds seem unfortunate to me (turbolinks, spring), can add to my frustration too).

I feel you on the treadmill pain!

  (The fact that some of the things Rails adds seem
  unfortunate to me (turbolinks, spring), can add to my
  frustration too).
For those reading this, just wanted to add that the Rails team puts a lot of effort into making things fairly modular. For example, disabling "turbolinks" is as easy as removing one single line from your .gemfile (the config file in which your gems are listed)

And remove `//= require turbolinks` from your application.js. And remove `"data-turbolinks-track" => true` from your stylesheet_link_tags and javascript_include_tags.

Or rails new hello-world --skip-javascript

But maybe you don't want to skip all javascript.

But rails devs heard our pain, and next version of Rails will let you skip turbolinks specifically too (not sure exactly which version it's slated for, and now I can't find the Github issue where I learned about it).

The modularity is nice... although the tradeoff is, ironically, code complexity to support that modularity.

Regardless, every new feature is additional code complexity in Rails, additional dependencies that may break with that feature and need to be upgraded (or that may require that features since it's now default, even though you need to turn it off), and treadmill time upgrading your apps or engines to work with the feature _or_ to disable it.

A friend of mine focuses on just this: Keeping Rails apps up to date and maintaining existing projects:



Does he enjoy that work? It sounds miserable to me.

Sounds like teams might pay a lot to have someone else do it :)

It's definitely a double-edged sword, but I don't think Rails could have staid relevant without being one of the most aggressive frameworks in terms of breaking backwards compatibility.

The way I see it is that Rails is usually the wrong choice for a one-off project that a client expects you to deliver and be able to run indefinitely with no maintenance, but it's a great choice for a prototype or something that will see continual maintenance and enhancement.

My biggest frustration is just the general slowness of Ruby once you get to a non-trivial app size.

I don't really see on Rails being wrong for a one-off project. It should keep running just fine as long as you don't update anything. The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something? It usually isn't too important anyways, as long as the app isn't externally accessible.

> The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something?

Right, the key issue is: Can I apply a security-only patch, fairly confident that it won't introduce any regressions or break anything else in my app?

With Rails, the answer is hardly ever 'yes'. If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released -- you've got to upgrade to a new version to get a security patch, with all the treadmill time that entails. If there is a security patch release, it is often bundled with other changes that come with risk of regression (and often deliver on that risk).

I agree it's a "double edged sword"/trade-off to Rails quickly evolving nature. But the pain is very real for many of us.

I would definitely hesitate to deliver a Rails app to a customer that did not have sufficient in-house technical expertise to maintain it. I would not have nearly the same hesitation with a PHP app or an html/javascript-static-only app, even though all of them can need security patching (although the html/js only one probably only has security holes that effect the client!).

>although the html/js only one probably only has security holes that effect the client!

If it touches a server and a database then it has a broad attack surface, at least Rails covers a lot of the basics for SQL injection, XSS, and url manipulation.

And, you can patch a Rails app yourself in a lot of cases or go grab a gem that implements the fix for your legacy version. With Github still living on Rails 2, theres a lot of unofficial support out there.

Sure, you can do lots of things to try to maintain your old Rails apps, but none of them are easy and reliable, especially for those who aren't Rails experts (but may be developers).

Clearly, finding unofficial patches on github and applying is entering the realm of "this thing sure is painful to maintain", isn't it? Especially if you have multiple apps (at different legacy Rails versions) to maintain, and/or you are an enterprise that hired a contractor to deliver an app but has no in-house Rails expertise.

Yes, yes, then you might say "Well, then don't do that, keep your apps up to date, don't take on Rails apps without in-house expertise." Exactly, right. So we agree.

Holding Rails to a minor version is quite easy (just specify it in your Gemfile) and updating patch levels shouldn't break any of your code. And security updates are still being released for Rails 3 where applicable, although 4.1 and 4.0 have already come out since then.

Updating patch levels _has_ broken my code, several times, over the past ~18 months. Sometimes it's acknolwedged as a regression and another patch is released fixing whatever went wrong; there has been at least one time that did not happen (I could find it if you really don't believe me).

Yes, bugs happen, in-retrospect-wrong decisions happen. This is life. And this is part of what makes maintaining a handful of Rails apps developed under different Rails versions a pretty labor intensive thing, even with no new features.

Rails maintenance policy is summarized in the OP we are discussing. Rails 4.2.0 is now in beta. Once it is released, support policy is no more security fixes for 4.0. Rails 4.0.x was the latest Rails release until April 8 2014 when Rails 4.1.0 was released. So if you developed an app against the latest Rails minor version in March 2014, within 6 months your app is on a version that doesn't even get security updates, and needs to be upgraded. Yes, it's probably not that hard to upgrade it in this case.

And, yes, when you have a handful or more of legacy apps, and upgrades happen every ~6 months, you spend a non-trivial amount of time on the treadmill. This is my only point. I am not a Rails hater. I use Rails daily. I know of nothing better. There are all sorts of reasons that lead to maintaning Rails apps being such a time-suck, and none of them are that Rails devs are mean or moronic. But it is astonishing to me that Rails inspires a level of 'fanboy'itude that has people insisting that in fact it's not hard at all to maintain legacy Rails apps. Have you done it? With more than one app at a time? With more than 5 apps at a time?

I second this. I recently did a port from Ruby 1.8.7 to 2.1.2 for a large Rails app (approx. ~350kloc between test and app) and in the process I was forced to update lots of dependencies. In a few places so called "minor" patches had big effects. It became clear to me that when your app gets to a significant size juggling the interactions of constantly moving versions of your Gems, Ruby, and Rails causes things to become complicated quickly.

If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released

Rails 3.2 is over two and a half years old.

What forms of software development don't involve maintenance and upgrades?

It's a matter of degree. I have PHP apps which have run for years with minimal hands on them. All they need is an upgrade to PHP, which sometimes doesn't require touching the app source code at all, or sometimes requires relatively minimal (compared to my rails experience) updates to the source.

(I still do not choose to write my apps in PHP. Also these PHP apps did not use a Rails-like framework. If I were to do a big app in PHP again, I'd want a Rails-like framework. And indeed I wonder how much that would increase my maintenance costs.)

I guess they all do to an extent although I've been mucking about with web2py partly because of their "We have not broken backward compatibility since version 1.0 in 2007, and we pledge not to break it in the future" stuff.

I understand your points and mostly agree with them, but there are valid situational counter-arguments for them too:

1) Except when you don't have the money. Not everyone trying to build a business goes the funded startup route...

2) Except when it does. There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.

3) Yes, you want to quickly iterate. Sometimes this means using readily implemented libraries for the non-core parts of your businesses. Sometimes it means avoiding readily implemented libraries that do not fit your requirements and/or overcomplicate what you are trying to do. Sometimes it means avoiding the cognitive overhead of all that cruft a framework has and you don't need. Sometimes it means using a typed language and letting a compiler do the most basic testing for you...

4) To me, this is a classical exploration/exploitation tradeoff. You will be less productive using anything new. New language, new framework, new ideas drag your productivity right now. But they may increase it in the long term, even if you end up going back to whatever you were using before. Find some budget to explore and make the most out of what you learned, but don't overspend on it.

And herein lies the issue. As engineers we long to solve 'special' problems, and fool ourselves into thinking we need to do something novel and hard when something simple will do.

We fool ourselves into thinking we NEED a faster language, and Hindley-Milner type checking, and everything else under the sun.

It's actually really hard to discover, whether you're fooling yourself or not here.

We're building our startup on Ruby/Rails with a clojure component for the speed sensitive stuff (which is actually a CPU bound number crunching affair). So far we're been very happy with the tradeoff. We tried building stuff in node, but the ecosystem is just so damn immature.

One of the nicest things about the Ruby community, that I haven't seen in any other language, is the cultural emphasis on good documentation. Java libs have very complete docs, that take forever and a day to read when you just want to use one damn feature, node.js projects have very pragmatic, but very incomplete docs, (same with clojure), and really, that's the case with most languages. Ruby on the other hand, seems to have instilled in its community that docs count, and its wonderful.

Rails testing and tooling is just ahead of the pack, and in the specific case of node, dealing with the irritation of async (inscrutable stacktraces, even when 'long' stacktraces are enabled, inconsistent uses of promises across libs, etc.), is a huge drag on productivity. If I needed a small highly concurrent component I'd consider it, but for general business logic Rails just kills it.

Re: Hindley-Milner, this one is really really tough and I am not convinced either way yet. The problem is that it's so easy to whip something up in Ruby and then write a slick rspec suite that ostensibly shows that it does what its supposed to. At the time you launch this there is no value in strict type safety because it's easily testable and self-evident that it works.

The value of type safety comes in tiny increments over time. Week after week, month after month, year after year. If your project survives 10 years I am quite confident that the effort of implementing in a strictly typed language would have paid for itself by the number of bugs prevented and the number of wiring tests that didn't have to be written/maintained. Of course if it's just a solo project and you keep the code under control it's possible this is not true, but with developer and code churn I'd say this is practically impossible. The more important question is will this code base even need to live for 10 years in the first place?

Completely agree. There's a continuum of, to simplify - dynamic typing -> static weak typing (C, C++, Java) -> static strong typing (Hindley-Milner, Haskell, etc).

Hard to go back to dynamic or static weak after grokking the power of static strong, as you describe. Algrebra Driven Development > Test Driven Development.

Totally agree! FWIW, I'm betting on Hindley-Milner in the long run. The thing is, is it as important as something like library availability, good docs, etc.? Often times the answer is no.

Hindley-Milner + library availability + good docs => F#

If I could upvote you twice, I would. The number of times I've had to argue with developers over how unique their situation is and why they've had to go and re-invent the wheel for situation X is disconcerting.

I think it's a pride issue and a difficult one to manage correctly if you want to keep active/engaged developers who believe they're tackling difficult/unique issues.

I personally think Rails is great but, frequently, it is not a sentiment that is shared amongst the people I regularly work with and they see it as too elementary (for some bizarre reason).

If Rails were a for-profit with marketing dollars I would suggest that there is a perception issue with the framework among developers, but I don't know how you handle that in the OSS world.

There can actually be business value in novelty for novelty's sake. For a startup there are two markets: those of customers and those of employees.

The market for new hires is critical to success too, and using the latest and greatest tools can really help there. This is also a reason for Google X, Facebook buying Oculus, etc.

To answer your criticism to the original criticism: 1) Rails is not really THAT expensive, especially when you're just trying to build a small business website. The people who complain are actually the ones who are exactly working on those "funded startup" you mentioned. 2) There are tons of huge apps out there that run on rails just fine. You hear about stuff like Twitter switching to other language because rails is "too slow", but Twitter is like the rarest exceptional case you'll ever find. I mean, do you know of any other web app where realtime is as important as Twitter AND is at such a huge scale? Most websites don't. 3) It's actually more like "Most of the times you use readily implemented libraries and in rare cases you need to use your own". You can't iterate fast when you have the mindset of trying to fix everything. You need to pick the most important problem you're trying to solve and do whatever it takes to reach product market fit as quickly as possible. I have played around with node, express, etc. to build webapps and was at first very intrigued. I did that for a while, and then got frustrated with the lack of convention i can just mindlessly follow as well as all the convenient tools rails provide. So I came back and couldn't be happier.

> There are (a small percentage of) businesses where speed does matter and caching everything is not an option. Think exchanges, ticket sales, real-time analytics off the top of my head.

True. But even in those cases, there are likely parts of the system where speed of execution is less important than speed of iteration. So you could (if it made sense for you) use a Ruby app for the user-facing app, backed by a service written in something else.

Point being, just because you need a critical processing bit to be written in screaming-fast C doesn't mean you need to write your own HTTP router in C.

While I totally agree with your main points, I suspect that a large part of the difference in productivity you describe is a result of your familiarity with Rails and its ecosystem. If you've done many projects in it, have established workflows you're comfortable with and know the framework inside and out, of course you are going to be more productive compared to using a less familiar technology.

Precisely. I respect Neya's point of view, but I interpret it as not specifically about Rails or other specific frameworks, but rather as a cautionary tale warning against needless branching out and exploration of other languages and frameworks. In other words, his experience seems to be a data point suggesting that you stick with what you know unless you have a strong need to diversify.

That said, one impetus of our TechEmpower framework benchmarks project was to encourage people to diversify their experience and consider performance as one metric in evaluating the broad spectrum of options. I personally feel that doing so is valuable for a variety of reasons, several of which others in this thread have pointed out.

We refer to a second dimension of "developer efficiency" that we can't measure as objectively as performance. We've had scores of conversations about proxies for developer efficiency, but haven't moved forward in earnest on any yet. That said, my strong belief is that developer efficiency is not inversely proportional to performance any more. Perhaps it was at some point in the past, but I don't feel that's the case now. I personally am just as productive, and in some cases moreso, in a modern language and framework, as I am in legacy frameworks and languages.

If it were possible to accurately and impartially measure developer efficiency and then scatter-plot developer efficiency and performance with a slope line, then yes, there may be a declining efficiency slope as performance increases. But I suspect there would be data points representing both high-efficiency + high-performance and low-efficiency + low-performance options.

It's important, but difficult, to isolate learning curve from long-term developer efficiency. But Neya is a useful counter-point to my argument, and if I might put words in his mouth, he is saying: don't trivialize the lost productivity due to the learning curve; it can be significant.

Yeah, the same logic could be used to argue for using Java or PHP frameworks.

Plus, SASS/Compass/HAML integration isn't strictly part of a framework, it's the build pipeline.

Can you point to what you think is an example of a good open source web application written in Go? I'm curious to see what non-trivial web applications in Go look like. I've tried Go for web applications a couple times, but I ended up feeling the same way you do about it. I've really liked it for backend things, however.

> Can you point to what you think is an example of a good open source web application written in Go?

* https://sourcegraph.com/blog/google-io-2014-building-sourceg...

* https://github.com/drone/drone/

* https://github.com/jordan-wright/gophish

All are reasonably sized; Sourcegraph and Drone especially so.

We made https://github.com/sourcegraph/thesrc as an example large open-source web app in Go because we also wished we had examples like this when we were starting.

> The actual thing you want to be able to do is quickly iterate on your product and constantly have it evolve.

This also helps you "fail fast". If you have a 1-year runway, it's much better to be able to build 3-4 apps for market validation than build one performant one that nobody wants.

If one succeeds and performance is a problem, you now have good reason to optimize, possibly even to switch languages.

> The speed of a language has nothing to do with the success of your business. NOTHING. You can go with the world's slowest language and still be successful. Best example of this is Basecamp itself.

The fact that an example of something exists doesn't validate that something. "Shooting people has nothing to do with whether they die or not. I once shot a guy and he lived."

You are mainly talking about web development. Golang is young and we dealt with the same problems at earlier versions of ruby and rails. But, outside web development, in most of my needs, golang was a better choise than ruby. Saved some servers running golang instead of ruby and had cut significantly the month cost of my startup.

> If you need to deliver faster (and in most of the cases BETTER), go with the language and tools you know more!

A little related: http://pablocantero.com/blog/2014/04/20/i-coded-a-backbone-a...

So what if you are giving bad advice again? In six months are you going to come back here and say 'Oh sorry I said you should use Ruby. What I REALLY REALLY REALLY meant was that you should be doing all of your coding in Perl'. Nuts to you man.

You are definitely wrong about item 2. The speed of the language may not be the only deciding factor but it should be one of the deciding factors. Saying it has NOTHING to do with success is short-sighted and shows that you are giving bad advice again.

i fail to understand why you would want to rebuild everything when using scala, we use it successfully with spring. Or rather just use grails and at least have the jvm. Rails is slow, yes it scales well, but other things scale as well (or better) and will cost you less to run.

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