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) 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) 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.
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).
(The fact that some of the things Rails adds seem
unfortunate to me (turbolinks, spring), can add to my
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.
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.
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.
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.
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.
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?
Rails 3.2 is over two and a half years old.
(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.)
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.
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.
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?
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.
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.
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.
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.
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.
Plus, SASS/Compass/HAML integration isn't strictly part of a framework, it's the build pipeline.
All are reasonably sized; Sourcegraph and Drone especially so.
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 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."
A little related: http://pablocantero.com/blog/2014/04/20/i-coded-a-backbone-a...