One upside is clearly that it helps attract raw talent more easily with a hot/trendy stack, and to me, it's a more exciting adventure overall (more risky though).
Talent that comes in because a stack is hot/trendy are there by virtue that they lack the experience to know it's nothing knew. They haven't seen other hot/trendy stacks fail yet.
Meaning they probably also lack experience to make decisions that avoid turning greenfields into a muddy hell. No thanks.
it depends what you mean, but i probably disagree - popular frameworks have more stack overflow answers, better docs, more bug fixes, and bigger ecosystems in general
i do not use rails but it probably is the cheapest alternative (from an engineering perspective) right now given the number of available engineers + ecosystem
Worthwhile PHP developers are not cheap either. Unless you mean WordPress developers. (no, they're not PHP developers, they're WordPress developers. They only know WordPress)
This thread inspired me. I am giving up JavaScript completely and am writing a browser in Fortran that only allows Fortran servers and Fortran in the browser. I mean, everything else is new and trendy. Fortran or gtfo newbies!
That's kind of like saying it's absurd to switch to a new social network because it is popular... as with social networks, languages/platforms are more useful when more people use and contribute to them.
Good libraries cover a multitude of language feature sins.
The point that Ruby is memory intensive vs other things like Nodejs and thus you are shooting yourself in the foot using it applies only to a very small subset of businesses, like Scribd, who require absolutely massive scale in order to be profitable. If your unit economics are different (and many are, substantially), Ruby is really not going to be the bottleneck in your scaling.
From what I understand one of the main value propositions of Node in regards to async is that async is the default in the entire ecosystem. In fact, I vaguely recall Node's creator explain that he chose javascript precisely because it didn't already have an existing server-side ecosystem, so it could be async everywhere from the start.
So the new framework of choice now seems to be Node according to his graphs. I'm building in Node as we speak and I'm not loving the Promise pattern to solve callback hell. Will I get over it? Have others?
There was a pretty elegant post on how Python's coroutines can replace callback hell with almost-synchronous-looking async code on HN the other day: https://news.ycombinator.com/item?id=10220712
Wonder if something similar will catch on in the node ecosystem?
Have you tried bluebird? It solved all my issues with async workflow in NodeJS, crazy-fast performance coupled with a very nice lodash-like API that makes working with data a breeze.
i'm using it and it's nice as you said. i'm not a node expert yet, this is my first large project. i'm sure i'll get more fluent as i go along but this programming style was an unanticipated twist in the road.
You might get over it! I feel I have, and now see callbacks as suggestions of where to break my code apart. For example, callbacks nested more more than a two deep are usually a remonder that I'm really trying to describe a series of steps with a common error and success handler, and the library "async" has a method called waterfall that does exactly this. Naming those steps keeps them simple, exposes commmonalities, and often leads to reuse.
That said, the thrust of this article is that you should make your technical decisions based on the absolute most trending thing at the moment, and I think that's bogus. Plain old syncronous programming has its place.
> you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now.
I advocate the exact opposite view: use what enables your team to be most productive right now. The popularity of frameworks may change three years down the line, and good engineers will be fine with that.
Because you have to maintain the app against known vulnerabilities. And in even a single year previous version of out app had multiple gems with vulnerabilities having to do a major version upgrade and I had to scrap the whole thing because older gems with fixes where unavailable or didn't build on modern rail/os
The whole ecosystem is frankly a mess, you need to stay bleeding edge all the time to have a chance to long term maintenance and suffer any capricious api update each of your dependency might have because staying on old release and relying on backports is not worth it.
I'm not paid to clean other people libraries. If the idea of open source is that, then no thanks. Core business is not maintenance and costs like those do kill startups.
Yeah, I'm not sure what kind of new company is willing so sacrifice productivity up front on a bet that future developers might not be excited about their codebase.
"Yeah, we're going to be another 2 months to launch because we're betting developers in 2018 prefer Go."
I'll be pretty surprised if you're still in business in three years.
Why? "Fine lady" implies that he and she work together, which probably fits the "ecosystem" of programming languages and programmers better. Unlike a mainly static inanimate asset like a car.
You edited it to say that. Before it said something about a "hot blonde that was too expensive to touch". And I'm not PC at all and I didn't downvote you, but it's still good advice.
Former PHP developer gone Node.js. I agree. PHP has come a long way and doing very well. PHP powers the 2nd biggest website on the internet. Not too shabby.
I can definitely accept that Rails is now somewhat old hat.
And agreed that the Rails 2 to 3 jump was (and still is for many codebases) a tricky and difficult path.
However, I'd argue that doing your 'startup' in [Rails/COBOL/PHP/Logo/Java] is probably a decent idea if you have good engineers who can build something stable relatively quickly. Technology is _rarely_ the problem in any given startup.
If scalability and speed is a problem, congratulations, you're a success.
Rails is still good at giving you the tools to build decent CRUD-ish apps pretty fast and deployment is thankfully a solved problem.
Rails is not the new hotness, but it's still great at getting prototypes out the door and can scale you a long way. I think I'm cool with that.
> our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time
Also rewriting your front-end four times doesn't seem that productive.
> If scalability and speed is a problem, congratulations, you're a success.
I can not emphasize this enough. A lot of solutions are absolutely good enough for a startup's needs. You obviously don't want something completely throw away, but too much concern over tools & performance is kind of like a premature optimization for your whole business.
Right. Just finding something that you can build on (and get started yesterday) with the team you have. Of course, it doesn't hurt to pick from one of the top 10 languages so that, if you do succeed, you have a talent pool to pull from.
But this is definitely a case of the perfect being the enemy of the good.
I know static vs. dynamic typing was not covered in the article, but all things equal, it should be easier to onboard new devs into a statically typed codebase.
New devs do not have a cache of the codebase in their mind, therefore their mental compiler (because that's what you're utilizing any time you code in a dynamic language) is more prone to make mistakes than devs who know what parts of the codebase to "compile" when they make modifications.
Some may argue that tests can theoretically cover all these bases. I would counter that in practice, tests almost never come close to serving as a poor man's compiler.
And of course, not even a dev who is experienced with the codebase could replace a true compiler, but I'd assume that this is deliberate trade-off, if there were competent technical decision-makers involved
I worked on a reasonably large Python codebase once, and it was definitely more frustrating than a statically typed language. I'd see that function takes an argument named "session". Great, what can I do with that? So I'd have to do `print dir(session)`, run it, and figure out how to hit that function, and then look up the documentation for that class. It's so much easier when the function actually tells you what it is expecting.
I'd also have plenty of times that I referenced a variable and forgot to create the assignment. In a static language I'd get a compile error, but in Python I'd get everything all set up to test and then get a run-time error indicating I did something stupid. Never ceased to frustrate me.
Erlang really helps you understand these, because it's dynamically typed, but the dialyzer will produce errors as a form of static optional typing.
I wrote some code a few days ago that looked like it worked. A few days later I ran the dialyzer, and it pointed out a certain code path could never be reached, because there was a comparison of an atom to an integer.
I would never have recognised that bug otherwise, because even my unit test just called that function with an integer, instead of the atom it was being called with.
Dynamic typing runs deep in what PHP/Ruby/Python offer - build it and get it running fast. Not thinking about complex types is a good thing in small projects.
But at a codebase of a certain size, static typing really helps minimise subtle bugs.
I run into this constantly. Static typing is great. If it compiles, I've already avoided half the runtime problems that typically plague big Python code bases.
> Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.
Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this. Meanwhile NodeJS/JavaScript is adopted by _many_ companies: IBM, SAP, Google, Joyent, Microsoft, etc. Ruby had some momentum before but none of the big guys extend their support as far as NodeJS/JavaScript.
Having said that, I'd probably use Java for a new company , why not?
Some people say "bulb" I'd say "matured"
Some people say "verbose" I'd say "explicit than implicit" (or code is written once to be read multiple times)
Some people say "bloated framework" I'd say "stable and backward compatible without sacrificing speed and flexibility" or "does not have to reinvent my memory mental model" (compare to different JS API programming style).
Some think Maven "sucks/bloated" but I'd think nothing can touch it for the most part...(plus Maven's idea is copied everywhere else..)
To each of his/her own I suppose.
PS: I use JavaScript 100% to build 2 enterprise products as my day job
When people say Java is "verbose," they usually mean it is relatively hard to read, so I don't see what you mean by "code is written once to be read multiple times." The problem with Java's verbosity is that the code is typically full of noise and redundancy.
> > Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.
> Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this.
While no major corporate sponsors may be the case for Ruby, its not for Python:
I don't know what those sponsors do but I don't see any advancement in the Python world to be honest.
None of these companies decided one day to write the Spring Framework for Python (or the Rails). We got Django that seems stuck in 2005-2009... (no offense to Django devs).
Python runtime hasn't changed much...
Meanwhile in NodeJS land:
- GoDaddy decided to re-write stuff using NodeJS
- eBay adopting NodeJS in increasing pace
- Progress (.com), legacy software company acquired modulus.io (NodeJS shop)
- IBM z Systems supports NodeJS
- Go to Microsoft Learning, you'll find lots of JavaScript tutorials (NodeJS or WinJS or Angular)
These companies promote NodeJS up-front. When Microsoft decided to hire people behind IronRuby and IronPython, I thought they decided to adopt those languages but that didn't last long before they cut them loose...
> Go to Microsoft Learning, you'll find lots of JavaScript tutorials (NodeJS or WinJS or Angular)
And also quite a bit of Python, including general language courses, Django, Python/Flask/SQL, Python w/MongoDB, etc.
> When Microsoft decided to hire people behind IronRuby and IronPython, I thought they decided to adopt those languages but that didn't last long before they cut them loose...
Microsoft is still a significant backer of Python, not just a PSF sponsor, but also directly employing Python core devs, and doing a lot of direct support for Python. [0]
IronPython and IronRuby weren't Microsoft adopting the Ruby and Python languaegs, they were efforts to alternatives to the core implementations of those languages tied to the .NET platform.
If, in 5 years, we're all using node.js, I will leave the industry. JavaScript is an abominable language, I hate that we're stuck with it on the frontend, and I will leave any shop that tries to make it my primary job.
Python has quite a bit of backing, including by every company you listed as backing JavaScript. Admittedly, it's for different reasons, but the support is there. Ruby, well, yeah, that's a totally volunteer job.
You should use whatever people you're working with know and are comfortable with.
Looking at trends is almost useless, from your example Nodejs can't be above Java for Jobs searching.
"if you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. " really? I'm not expert but the tech is a tool to create a product not the way around.
The most compelling reason not to use Ruby for a new company or product in an existing company is that the talent of the average Ruby programmer has dropped drastically in recent years. Face it, Ruby is hitting that adoption stride where it's attracting/has attracted a lot of people who don't care about the quality of code they write. JavaScript isn't any better and is probably even worse in this regard.
As much as we hate to admit it, a significant part about what attracts us to a language is the quality of people who use it. While Ruby has nicer things about it than Java did in 2004, the people adopting Ruby in the early to mid 2000s didn't just dislike Java, they liked the like-minded individuals who seek out tools to make their lives better.
> The most compelling reason not to use Ruby for a new company or product in an existing company is that the talent of the average Ruby programmer has dropped drastically in recent years.
That's a pretty good reason if your selection method is substantially equivalent to choosing "X programmers" (for whatever X is your technology base) at random.
A lot of companies basically hire in that way when their hiring means are through recruiters/job ads. Very few companies have the time/diligence or live in an area with enough of a developer pool to be finnicky about who they hire. Obviously there are ways (remote) to offset this but none of this addresses the fact of my initial statement.
If your going with a don't "be finnicky about who [to] hire" hiring strategy, your company will have way bigger issues than programming framework choice, so it won't really matter.
"a significant part about what attracts us to a language is the quality of people who use it." <= where did this theory even come from? I learned to program because I wanted to build stuff. I couldn't care less about "quality" of other people who's using a language, I only care about how productive it makes me.
OK then let me add "Rails" to that sentence if this makes you feel better. I learned to program Rails because I wanted to build stuff. I couldn't care less about "quality" of other people who's using it
Rails was and is the most productive web development framework and that's why I use it. I don't even know who's in rails community.
In principle yes, but in practice there's a significant signal-to-noise ratio. This is why I abandoned PHP in favor of ruby—it's not that you can't build great things in PHP, it's just that you couldn't learn as much from the community without wading through tons of crap.
Does anybody know which framework they were both inspired by at the time? I'd guess that the concept of MVC has been around for a long time but what kicked off the popularity in 2005?
CakePHP was released before both of them, in 2005 too.
Rails at least, was heavily inspired by the book Patterns of Enterprise Application Architecture from 2003. That - in turn - drew a lot from the Java world, that was the lingua franca at the time.
I don't know the pre-1.0 history for Django, but I started with rails 0.7, and 0.8 was [released](https://rubygems.org/gems/rails/versions) October 2004, with much of the core architecture in place.
Also, they have (or had, at the time) completely different philosophies: while Rails was highly tied to "convention over configuration", Django went the other way after the "magic removal" branch and it became fully "configuration over convention".
When I had to chose one over the other, I ended up using Django simply because diagnosing issues was simpler. Rails required a pretty substantial amount of a-priory knowledge to get things started (think, naming a file or method a certain way for it to magically be available somewhere else.) Django was more straightforward and allowed you to write code that, while not 100% django-esque, would work. I remember doing a lot of refactoring whenever I'd figure out a new framework idiom that I had missed earlier, but hey... I had working code before I needed to learn the idiom.
Rails was around before December 2005; that was just the release date for version 1.0. I know I had a personal site running on pre-1.0 Rails in early 2005.
But your general point stands, Rails and Django grew up together and cribbed from each other liberally. The biggest example would perhaps be the merging of Merb into Rails 3, where Merb was a competing Ruby framework that had a much more Django-like vibe. These fanboy arguments don't hold much weight these days. They each do their own thing, they each borrow the best from each other, and everyone benefits.
Reddit guys took the advice of this article to heart but fairly quickly had to rewrite the code in python.
The thing is your secret weapon should not be too secret. Languages and platforms are useless without a community around them. In fact clojure's community seems to be a pretty vibrant one.
> Serious developers, particularly ones with CS degrees, look down on bootcamp programs as “programming light”. I’ve noticed a disturbing trend of experienced developers not wanting to work with rails now that it’s been “polluted” by this reputation.
In my book, this "jackass filter" is a feature, not a bug.
---
WRT performance, the actual performance in benchmarks of the language is, for the most part, thoroughly irrelevant in most web applications. You're going to be spending most of your time waiting on I/O and network calls. Making real-world applications fast consists mostly of in-memory caching, not blocking on I/O, and doing things in parallel. That Node was designed primarily around nonblocking I/O has far more bearing on real-world performance than any JS vs. Ruby benchmark.
I don't love Ruby, but Rails removes a dozen time-consuming decisions from the space between "starting an app" and "shipping an app" and leaves you building on a stack that is in use by a relatively large number of developers, which means that somebody has probably run into framework bugs before you did. And I've yet to see anything mount a serious challenge. Which is a shame, b/c I don't love Ruby, I don't love Rails, but that it's mature enough that most of the design WTFs have disappeared by now makes it hard to choose something else.
The author cites a graph of declining Google searches for "Ruby on Rails" relative to "Node.js" and then follows up with the statement:
You can see how rails is losing mindshare to newer frameworks.
I don't really think this proves anything. People who are already familiar with something aren't going to perform a vanilla Google search for it. For example, if I'm looking for a car, I'm not likely to perform a search for "automobile" but after overhearing somebody mention something called a Model S I might search for that.
A quick anecdote- I first learned about RoR circa 2008 from a colleague and performed a Google search for "Ruby on Rails" to find out what he was talking about. Fast forward three years and I was writing several web applications in it and don't recall ever performing that search again.
A far better metric I believe would be to perform an analysis of Stack Overflow questions by language and see whether it coincides with the chart the author cites.
Just devils advocate here but I highly doubt you never performed a search for rails again. I am very proficient in NodeJS, but I'm searching daily with the term for helping fix a bug I have. I am having an issue with es6 classes, I don't search "classes" or "programming classes" I search "es6 classes node.js" Boom, Node.JS now has a search term in trends.
When developing Rails applications, I rarely, if ever, include 'Rails' in my search terms, but rather drill down to the applicable component library: ActiveRecord, ActionController, Haml, Rack, etc.
This is a good idea, because it also avoids all those transportation or mining related results you often get with general "rails" or "ruby" searches.
I'm not entirely joking. I do the same thing you do (using ActiveRecord), but the way I got there was 1) searching "rails", 2) throwing in a term like ActiveRecord to avoid unrelated results, and final 3) realizing that "rails" was no longer necessary for the search.
Yup. I also find that the Rails documentation is good enough that I can usually find what I need in the Rails guides and API docs- or failing that, the source code.
1 - This decisions seems based more on the fact that Rails isn't as trendy as it used to be
2 - Some of these benchmarks for performance are pitting interpreted languages against compiled languages which will explain some of the performance difference
3 - Saying that Rails is static makes me think that the author would prefer a NodeJS like situation where every release might contain backwards-incompatible changes
4 - You don't future proof your application by trying to predict what will be popular in the future, you future proof by investing in stable technology and ensuring you have the talent pool to maintain it
PHP is not so static, has remained backwards compatible for many years, and people still bitch about it every chance they get. It's just something developers do.
I guess every profession has their own version of this (someone flipping burgers probably has their special way of cooking it just so on every side). In the end, regardless of the way you do it, it gets the job done.
I think the technical aspects discussed in the article are there not to debate the relative merits of technologies but to support the main line of reasoning which is social in nature. It boils down to:
1. Use the platform which is gaining mindshare because some years down the road you will be hiring engineers and you will want to look hip not obsolete.
2. Use the platform with solid corporate backing so that someone will support it and help it mature.
Seems very reasonable to me. Smaller companies need some strong selling points to compete with the larger firms on the hiring market and hip technology can be one of them. But the hip technology needs to actually work so better have someone with lots of resources backing it.
If a company itself is "hip", it doesn't need to worry about "looking hip" to developers. If I was starting a company, I would focus on the productivity NOW rather than worrying about how hip it will make me look in 3 years. And from my experience Rails is THE most productive framework on the market at the moment. I really tried to like node and have built several apps with it but I didn't even feel half as productive as using rails
Article's author seems very favorable of Node: which would be lower on my list the Rails as a server-side language.
I believe Rails is still a great option in case you want to use an existing team and where strong performance is not a requirement. Learning Rails is currently a very minor bump in the road, since (1) the language is easy to pick up, and (2) the framework is well documented (every possible question is on stack-ex it seems).
For now I'd look in the direction of Go, Erlang/Elixir, Clojure and Haskell as the new contenders for doing web development. They all have their own strong points, and I personally resonate most with Haskell (strong typed, manageable maintenance curve a.k.a. happy refactoring, fast enough).
So why not Node? It's because of JS. The language is the biggest "API" you will ever write against. Moving away from it is called either a rewrite or a port. So making a choice for a language should be made carefully. And design choices when making a language should be made carefully. In case of JS the design was clearly haphazardly done: and this will leak into any code written on top of it.
The author seems to be comparing Node mindshare to Rails, but his Node framework of choice is Sails. It seems to me most production Node web apps are using Express or to a lesser extent Koa and Meteor. Is there some huge secret contingent of production Sails apps I don't know about?
Most people who come to Node from other languages are running monolithic apps and are looking to replace those apps with the same MVC structure, just in their new language. Sails is one of those frameworks. Express and Koa on the otherhand are not so much setup for that. You have to do a lot of work to get Express and Koa to be a monolithic app.
I sometimes wonder about this very question from month to month and I always end up seeing Rails as a winner.
I believe the success behind rails and ruby ecosystems is due to the rails "monopoly" - it got so many things right along the way, from embracing REST, to migrations, generators, TDD, to the asset pipeline, turbolinks, supporting PG's hstore and jsonb and so on...
And even if you decide not to build the frontend part of you application with Rails, it is still a powerful tool for building an API. After a few experiments trying to embrace a more domain oriented approach (largely thanks to Bob Martin's talk 'Architecture, the lost years'), I am both productive and comfortable writing complex business logic in plain ruby and attaching it to Rails.
And finally there is testing. When I need to move from RSpec's powerful BDD capabilities to py.test (our ML algorithms are written in Python) I see how much more productive (and confident) I am writing Ruby code.
The article indicates that the next big thing in server-side development is Javascript, but hasn't it been for the last 5 years?
First express, then the whole MVC moved over to javascript with backbone, angular, ember and meteor - but you still needed a server side API so at least the models and controllers were written twice (I still see the marshalling data in JSON as a "V"), and then came Angular V2 and before you even got the chance to play with it, you were using a "useless" framework. And then came React (which, btw is just the V, despite being (wrongly) promoted as an Angular alternative), but it doesn't quite specify how to connect with the data itself so then there is Flux, and JSX and Babel, Typescript, ES6. And, let's not forget the tooling behind everything javascript: node, iojs, requirejs, webpack, npm, bower (why are some packages available on both places btw?), grunt, gulp. And the cherry on the cake: no more REST, the next big thing is GraphQL.
I exaggerated on purpose, but as a software engineer who is not strictly focused on web development I appreciate being blindly guided by the decisions made by the Rails community.
It feels there is so much more serious/strong "competitors" for the next server-side Language/Framework duo now, than there was 8 years ago (Go, Javascript, Java8, Python 3, Haskell, Clojure, etc) - and from what I am able to keep up with, if I had to move, I'd go to Elixir/Phoenix, exactly because it seems to be fixing ruby's major issues while keeping rails' excellent choices.
But this moment hasn't arrived yet. What I'm looking for, before betting on the next big thing, is success, and as a @andycroll said: "If scalability and speed is a problem, congratulations, you're a success."
> A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead.
Node.js isn't a framework. What about comparing apples with apples?
Anyway, I think that the main change that's going on right now is that lots of web apps have a higher and higher percentage of the code written for the front end (web and mobile) rather than the back end.
Rails still has much higher productivity and tooling for back-end development than the Node.js frameworks I've seen for now, but that could become irrelevant for many startups in the medium term, just because a lot of the added value for them will come from the front end rather than the back end.
Evidently, "framework" suffers from semantic overload here. The article itself says that "Node.js suffers from fragmentation with a half dozen frameworks competing".
Er, I'm far, far from a JS expert let alone V8, but I thought V8 does the compilation to machine code and Node serves as the process containing the thread the program is running on, making Node the runtime, and V8 the engine.
That and nodejs.org calls it a runtime built on V8 :P
I'm learning Rails right now and this isn't the first time I heard how slow RoR can be. Hell, there's a whole site answering the "Can rails scale?" question (http://canrailsscale.com/).
A lot of what Rails does, and even the little things, like naming conventions in ActiveRecord, intuitively make sense to me. If RoR ever does expire because another language/framework displaces it (maybe Elixir/Phoenix?) or because of poor/no support from a big company, I wouldn't look at it as a waste of time. Overall, I'm seeing a tried-and-true method of creating web applications and I'm enjoying it so far.
RoR can still get you where you need to go and fast, which is what you need when starting out. And if you ever find yourself in the same situation as Twitter, then you can make the switch...or better yet, improve on Ruby and give back to the Ruby community.
Rails eliminates a lot of choice and this is a huge deal. Hooking up db and setting rake tasks migrations for sinatra project might feel novel the first time you do it, but not really after that.
Rails can feel somewhat bloated, but it has a lot of functionality out of the box done transparently: generators, ORM and migrations, xss protection, templating, assets compilation, testing, configuration and naming conventions.
It's been a huge shock to me to see that a more modern framework on a more modern platform, express.js on node.js, has such a tiny subset of features we had in rails like 8 years ago. Granted, it's more like sinatra rather than rails, but nonetheless disappointing — what do all these people find in express that they couldn't have before.
Rails, Sinatra, Express developer here - each tool has different characteristics that make it better for some things and worse for others.
If I wanted something with a high throughput of simple requests (like a chat server) or realtime responses using websockets, I'd typically go with a Node.JS inspired framework like Express.
But as this thread states, developer productivity can't be overstated, if the shipped code does what is needed.
"If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now. If you’re Facebook, you can get away with using anything and people will still want to work for you, but most companies are not Facebook."
Ugh, I so disagree with that statement and this whole post. The company culture should be one that promotes using any technology, as long as it solves the problem. You should be hiring engineers who are comfortable picking up any language/framework, not fanboys who can only develop in X or Y.
As a start-up, you should be trying to iterate as fast as you can, not future-proofing your application. Chances are, your application will get a complete re-write once you've got enough engineers, or you're just a badass from the get-go and the code is solid all around regardless of what language or framework you used.
I can't stress this enough, but like it or not Rails (and Django) are some of the most feature complete frameworks out there. Particularly because of the ecosystem they've created and the community that supports them.
As far as remarks about Ruby or language X being slow. It really doesn't matter. The primary cause for slow applications is poor architecture and shitty code, not the speed of the language. People building one massive piece of shit monolithic application because they didn't bother to learn about microservices. Not to mention the amount of engineers who haven't gotten a clue about how to scale an application. With some proper HTTP caching and nginx to help you bypass the entire application layer, you can speed up your application by orders of magnitude.
The comment about Django being a Rails clone... wow, just wow. Although they share the Active Record design pattern for the ORM, they are vastly different.
This post makes my blood boil, because it's about language flame wars and fanboys.
I'm curious, how would microservices architecture make the application faster? In my experience monoliths are faster (but they are indeed a pain to maintain) - instead of making the rpc request with all the overhead it implies, you can just pass objects in memory directly!
A well-optimized monolith is going to be faster, but a less monolithic codebase makes certain bad decisions much more painful. If you know you have to make an RPC call of some sort to access a given resource, you're going to be more careful in how you access it; if you don't, you're going to have unusably slow and brittle software much faster than you would in a monolith.
So you end up being forced to optimize earlier, and the process of optimizing a single small component is generally simpler (you can profile just that process, for instance).
That said, there's nothing keeping you from gaining many of the same benefits from a well-disciplined, modular monolith, and I think there's a pretty high risk of a fast-moving and over-stressed team (like a lot of startups) being put under more stress by the time and complexity costs of microservices, and thus making much worse decisions than they would on a monolith.
When things are "a pain to maintain," code gets worse and worse over time. Performance then suffers because no one understands what's going on. In other words, I believe that in the long run, complexity is a far bigger performance risk than technical overhead like how long it takes to make a web request. It's much easier to optimize away those kinds of problems away than to make an awful codebase understandable.
In practice, I see service architecture as a way of making people think harder about how different parts relate to each other.
They don't. They just force less disciplined devs to incur less technical debt by making interfaces inviolable.
Personally, it would take a lot for me to switch a part of my monolith to a microservice and lose the speed of having everything done in the same process and the guarantees that having a single relational database offers. Having to reconcile data that got off sync because it was in two different data stores is not fun for anyone, and, to me, it's not worth it just to force yourself to not call any private methods on the other service. I just expose a public ABI and say "to interact with this part of the application, you may only call these functions here".
You can use the same data store with different services.
If you have a web application that handles most of the traffic on your site, and you have some management task/process that hogs resources in the same application, you're affecting your end users by running those processes on the same service.
The idea of microservices is to separate components so one does not affect the other, and you can scale individual components easily.
Define "application". You can easily have the task be a part of the same codebase and run on a different process or even server. For example, my Django maintenance commands run on a different server, and so do tasks, but they're still part of the same monolithic codebase.
Microservices allow you to scale individual components of your system and reduce technical debt by isolating them.
Say you have services X, Y, and Z. Service Z handles a lot of traffic and is becoming a bottleneck to the whole system. You spin up 2-3 more instances, throw a load balancer in front of them, and increase throughput, all without ever touching the rest of the system. Pretty seamless!
In addition, monolithic systems tend to be a pain in the ass for release cycles.
Microservices allow you to very easily bring components up and down and do zero down time deploys by using a load balancer.
Using our previous example, consider doing a release 2.0 for service Y. You spin up an additional instance of service Y with version 2.0 and the old instance is running version 1.0.
You take the old instance out of the load balancer and stick the new one in. With the flip of a switch, your end user ends up using version 2.0 of service Y, without ever having to bring the system down.
Now obviously microservices aren't the right design decision for every application. But as your system grows and uses different components, it's usually best to separate them out as individual services so that you can scale horizontally using load balancers.
It will be interesting to see if [Crystal](http://crystal-lang.org/) ever gets a port of Rails. Crystal currently has some serious limitations that I think would make it all but impossible to port (e.g. lambda support is weak), but perhaps those issues will be remedied. And if so, Crystal on Rails would be 4x to 20x faster than on Ruby.
On the other hand, I think [Phoenix](http://www.phoenixframework.org/) could be the next big web thing. Not b/c it is super fast (although still faster than Rails) but b/c it is super stable and easily distributed.
The big advantage of Node.js (and thus Sails) is, of course, that the front end and back end can be written in the same language (ie. less to learn), but that might change in a few years with [WebAssembly](https://medium.com/javascript-scene/what-is-webassembly-the-...).
Ruby is a super-readable language with a powerful syntax, and Rails (3+) used in Rails-like ways gives the user a similar amount of power over db and web delivery. Just because clarity of thought cannot be measured it doesn't mean the tools that enable it are worthless, or worth less.
A "faster" language only gives a linear improvement in performance. It's only worth it if a 5-10x increase in hardware cost crosses the line between profit and failure. If it doesn't, I'll choose the tools that get the job done with half the team size and lets them get home early every time.
He's comparing Google Searches of NodeJS (a language) to Google Searches for Rails (a framework). Technically speaking this is a huge flaw. Pragmatically speaking the author doesn't critique the strengths or weaknesses of why Rails would be a weak choice. His opinions are weakly based solely on popularity. Rails and Django are incredible powerful tools given for a very particular job. Node is another beast entirely. It's tooling and strengths are completely different because they both have different use cases.
I chose to use Node/Express at my last startup and Ruby on Rails at my current one. Both are great platforms with fantastic communities behind them. For example, there is an amazing amount of Stack Overflow answers and folks watching for new questions.
It's important to note that Express, the most popular Node framework, is a clone of Ruby's Sinatra, not of Rails. That's a great back-end when your front-end is iOS or React and you have a relatively simple data model. But it's not as strong a solution if you need to do server-rendered pages (which we need to support IE8).
The bigger issue is that Rails is just a much more mature and full-featured framework than Express or Sails.js (which is designed to be Rails for Node). From migrations to validations to strong parameters to many other areas, Rails just offers a ton of back-end functionality that is not as mature on Node frameworks. The big question is how much back-end business logic needs to be implemented.
I haven't run into any issues with Ruby's server performance. AWS instances are easy to spin up, and any Ruby compute time is almost certainly going to be overwhelmed by network and database access. The performance we're focused on is developer productivity, and I think Ruby retains an advantage there over Javascript (though obviously we use both). If I were trying to support millions of simultaneous web socket connections, I would almost certainly go with Node (or maybe Go), but I remain a huge fan of the Rails platform.
163 comments
[ 1.8 ms ] story [ 121 ms ] threadMeaning they probably also lack experience to make decisions that avoid turning greenfields into a muddy hell. No thanks.
i do not use rails but it probably is the cheapest alternative (from an engineering perspective) right now given the number of available engineers + ecosystem
This thread inspired me. I am giving up JavaScript completely and am writing a browser in Fortran that only allows Fortran servers and Fortran in the browser. I mean, everything else is new and trendy. Fortran or gtfo newbies!
Good libraries cover a multitude of language feature sins.
[0] https://github.com/avleen/bashttpd
Like no other language has async capabilities and implement it 10 times better cought Go, C# (and probably many others that I don't know)...
But by all means correct me if I'm wrong.
Wonder if something similar will catch on in the node ecosystem?
Whether or not this is a good thing or not, I'm undecided.
source: http://www.sitepoint.com/simplifying-asynchronous-coding-es7...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That said, the thrust of this article is that you should make your technical decisions based on the absolute most trending thing at the moment, and I think that's bogus. Plain old syncronous programming has its place.
Node 4.x is awesome (relative to Node 0.12)
I advocate the exact opposite view: use what enables your team to be most productive right now. The popularity of frameworks may change three years down the line, and good engineers will be fine with that.
The whole ecosystem is frankly a mess, you need to stay bleeding edge all the time to have a chance to long term maintenance and suffer any capricious api update each of your dependency might have because staying on old release and relying on backports is not worth it.
I'm not paid to clean other people libraries. If the idea of open source is that, then no thanks. Core business is not maintenance and costs like those do kill startups.
Spoiler: the difference is, the new ones' bugs just aren't widely known yet.
yeah, github is a perfect example or that, right? </irony>
If you want to run on old software that you don't have to upgrade or maintain, you are going to pay for someone else to do it.
If you want your cake and to eat it too, you're unrealistic.
"Yeah, we're going to be another 2 months to launch because we're betting developers in 2018 prefer Go."
I'll be pretty surprised if you're still in business in three years.
It's amazing what it's turned into. That said it's still very painful and the ecosystem has a very long way to go in terms of build tools, etc etc.
I bet there's a lot of money to be made in being able to turn old legacy php codebases into nice well factored systems in the next few years.
And agreed that the Rails 2 to 3 jump was (and still is for many codebases) a tricky and difficult path.
However, I'd argue that doing your 'startup' in [Rails/COBOL/PHP/Logo/Java] is probably a decent idea if you have good engineers who can build something stable relatively quickly. Technology is _rarely_ the problem in any given startup.
If scalability and speed is a problem, congratulations, you're a success.
Rails is still good at giving you the tools to build decent CRUD-ish apps pretty fast and deployment is thankfully a solved problem.
Rails is not the new hotness, but it's still great at getting prototypes out the door and can scale you a long way. I think I'm cool with that.
> our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time
Also rewriting your front-end four times doesn't seem that productive.
I can not emphasize this enough. A lot of solutions are absolutely good enough for a startup's needs. You obviously don't want something completely throw away, but too much concern over tools & performance is kind of like a premature optimization for your whole business.
But this is definitely a case of the perfect being the enemy of the good.
I'm not arguing; just curious.
Some may argue that tests can theoretically cover all these bases. I would counter that in practice, tests almost never come close to serving as a poor man's compiler.
And of course, not even a dev who is experienced with the codebase could replace a true compiler, but I'd assume that this is deliberate trade-off, if there were competent technical decision-makers involved
I'd also have plenty of times that I referenced a variable and forgot to create the assignment. In a static language I'd get a compile error, but in Python I'd get everything all set up to test and then get a run-time error indicating I did something stupid. Never ceased to frustrate me.
I wrote some code a few days ago that looked like it worked. A few days later I ran the dialyzer, and it pointed out a certain code path could never be reached, because there was a comparison of an atom to an integer.
I would never have recognised that bug otherwise, because even my unit test just called that function with an integer, instead of the atom it was being called with.
Dynamic typing runs deep in what PHP/Ruby/Python offer - build it and get it running fast. Not thinking about complex types is a good thing in small projects.
But at a codebase of a certain size, static typing really helps minimise subtle bugs.
So very, very true. You could keep a front-end developer employed for years just rewriting the same application in the latest JS tech.
Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this. Meanwhile NodeJS/JavaScript is adopted by _many_ companies: IBM, SAP, Google, Joyent, Microsoft, etc. Ruby had some momentum before but none of the big guys extend their support as far as NodeJS/JavaScript.
Having said that, I'd probably use Java for a new company , why not?
Some people say "bulb" I'd say "matured"
Some people say "verbose" I'd say "explicit than implicit" (or code is written once to be read multiple times)
Some people say "bloated framework" I'd say "stable and backward compatible without sacrificing speed and flexibility" or "does not have to reinvent my memory mental model" (compare to different JS API programming style).
Some think Maven "sucks/bloated" but I'd think nothing can touch it for the most part...(plus Maven's idea is copied everywhere else..)
To each of his/her own I suppose.
PS: I use JavaScript 100% to build 2 enterprise products as my day job
> Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this.
While no major corporate sponsors may be the case for Ruby, its not for Python:
https://www.python.org/psf/members/#sponsor-members
None of these companies decided one day to write the Spring Framework for Python (or the Rails). We got Django that seems stuck in 2005-2009... (no offense to Django devs).
Python runtime hasn't changed much...
Meanwhile in NodeJS land: - GoDaddy decided to re-write stuff using NodeJS - eBay adopting NodeJS in increasing pace - Progress (.com), legacy software company acquired modulus.io (NodeJS shop) - IBM z Systems supports NodeJS - Go to Microsoft Learning, you'll find lots of JavaScript tutorials (NodeJS or WinJS or Angular)
These companies promote NodeJS up-front. When Microsoft decided to hire people behind IronRuby and IronPython, I thought they decided to adopt those languages but that didn't last long before they cut them loose...
And also quite a bit of Python, including general language courses, Django, Python/Flask/SQL, Python w/MongoDB, etc.
> When Microsoft decided to hire people behind IronRuby and IronPython, I thought they decided to adopt those languages but that didn't last long before they cut them loose...
Microsoft is still a significant backer of Python, not just a PSF sponsor, but also directly employing Python core devs, and doing a lot of direct support for Python. [0]
IronPython and IronRuby weren't Microsoft adopting the Ruby and Python languaegs, they were efforts to alternatives to the core implementations of those languages tied to the .NET platform.
[0] See, e.g., http://pycon.blogspot.com/2015/03/for-microsoft-python-suppo...
That's also an argument against verbose. Verbosity hurts on each re-reading. (As does improper terseness.)
Python has quite a bit of backing, including by every company you listed as backing JavaScript. Admittedly, it's for different reasons, but the support is there. Ruby, well, yeah, that's a totally volunteer job.
Looking at trends is almost useless, from your example Nodejs can't be above Java for Jobs searching.
"if you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. " really? I'm not expert but the tech is a tool to create a product not the way around.
As much as we hate to admit it, a significant part about what attracts us to a language is the quality of people who use it. While Ruby has nicer things about it than Java did in 2004, the people adopting Ruby in the early to mid 2000s didn't just dislike Java, they liked the like-minded individuals who seek out tools to make their lives better.
That's a pretty good reason if your selection method is substantially equivalent to choosing "X programmers" (for whatever X is your technology base) at random.
But, beyond that, I don't see that it matters.
You're conflating "learning to program" with "using a specific programming language."
Rails was and is the most productive web development framework and that's why I use it. I don't even know who's in rails community.
Django was initially released in July 2005 (https://en.wikipedia.org/wiki/Django_(web_framework)).
Rails was initially released in December 2005 (https://en.wikipedia.org/wiki/Ruby_on_Rails).
Just a minor quibble. They basically grew in parallel and implemented similar feature sets, but the timing hardly allows for cloning.
Django does its own thing, and while it has borrowed ideas, it is an entirely different beast.
CakePHP was released before both of them, in 2005 too.
When I had to chose one over the other, I ended up using Django simply because diagnosing issues was simpler. Rails required a pretty substantial amount of a-priory knowledge to get things started (think, naming a file or method a certain way for it to magically be available somewhere else.) Django was more straightforward and allowed you to write code that, while not 100% django-esque, would work. I remember doing a lot of refactoring whenever I'd figure out a new framework idiom that I had missed earlier, but hey... I had working code before I needed to learn the idiom.
But your general point stands, Rails and Django grew up together and cribbed from each other liberally. The biggest example would perhaps be the merging of Merb into Rails 3, where Merb was a competing Ruby framework that had a much more Django-like vibe. These fanboy arguments don't hold much weight these days. They each do their own thing, they each borrow the best from each other, and everyone benefits.
http://www.paulgraham.com/avg.html
I couldn't be happier with Clojure and I don't really know what else I could want.
The thing is your secret weapon should not be too secret. Languages and platforms are useless without a community around them. In fact clojure's community seems to be a pretty vibrant one.
In my book, this "jackass filter" is a feature, not a bug.
---
WRT performance, the actual performance in benchmarks of the language is, for the most part, thoroughly irrelevant in most web applications. You're going to be spending most of your time waiting on I/O and network calls. Making real-world applications fast consists mostly of in-memory caching, not blocking on I/O, and doing things in parallel. That Node was designed primarily around nonblocking I/O has far more bearing on real-world performance than any JS vs. Ruby benchmark.
I don't love Ruby, but Rails removes a dozen time-consuming decisions from the space between "starting an app" and "shipping an app" and leaves you building on a stack that is in use by a relatively large number of developers, which means that somebody has probably run into framework bugs before you did. And I've yet to see anything mount a serious challenge. Which is a shame, b/c I don't love Ruby, I don't love Rails, but that it's mature enough that most of the design WTFs have disappeared by now makes it hard to choose something else.
You can see how rails is losing mindshare to newer frameworks.
I don't really think this proves anything. People who are already familiar with something aren't going to perform a vanilla Google search for it. For example, if I'm looking for a car, I'm not likely to perform a search for "automobile" but after overhearing somebody mention something called a Model S I might search for that.
A quick anecdote- I first learned about RoR circa 2008 from a colleague and performed a Google search for "Ruby on Rails" to find out what he was talking about. Fast forward three years and I was writing several web applications in it and don't recall ever performing that search again.
A far better metric I believe would be to perform an analysis of Stack Overflow questions by language and see whether it coincides with the chart the author cites.
I'm not entirely joking. I do the same thing you do (using ActiveRecord), but the way I got there was 1) searching "rails", 2) throwing in a term like ActiveRecord to avoid unrelated results, and final 3) realizing that "rails" was no longer necessary for the search.
1 - This decisions seems based more on the fact that Rails isn't as trendy as it used to be
2 - Some of these benchmarks for performance are pitting interpreted languages against compiled languages which will explain some of the performance difference
3 - Saying that Rails is static makes me think that the author would prefer a NodeJS like situation where every release might contain backwards-incompatible changes
4 - You don't future proof your application by trying to predict what will be popular in the future, you future proof by investing in stable technology and ensuring you have the talent pool to maintain it
These really popular frameworks are "mostly static" because they have been out for years, battle-tested in production and improved for years.
I guess every profession has their own version of this (someone flipping burgers probably has their special way of cooking it just so on every side). In the end, regardless of the way you do it, it gets the job done.
1. Use the platform which is gaining mindshare because some years down the road you will be hiring engineers and you will want to look hip not obsolete.
2. Use the platform with solid corporate backing so that someone will support it and help it mature.
Seems very reasonable to me. Smaller companies need some strong selling points to compete with the larger firms on the hiring market and hip technology can be one of them. But the hip technology needs to actually work so better have someone with lots of resources backing it.
I believe Rails is still a great option in case you want to use an existing team and where strong performance is not a requirement. Learning Rails is currently a very minor bump in the road, since (1) the language is easy to pick up, and (2) the framework is well documented (every possible question is on stack-ex it seems).
For now I'd look in the direction of Go, Erlang/Elixir, Clojure and Haskell as the new contenders for doing web development. They all have their own strong points, and I personally resonate most with Haskell (strong typed, manageable maintenance curve a.k.a. happy refactoring, fast enough).
So why not Node? It's because of JS. The language is the biggest "API" you will ever write against. Moving away from it is called either a rewrite or a port. So making a choice for a language should be made carefully. And design choices when making a language should be made carefully. In case of JS the design was clearly haphazardly done: and this will leak into any code written on top of it.
I believe the success behind rails and ruby ecosystems is due to the rails "monopoly" - it got so many things right along the way, from embracing REST, to migrations, generators, TDD, to the asset pipeline, turbolinks, supporting PG's hstore and jsonb and so on...
And even if you decide not to build the frontend part of you application with Rails, it is still a powerful tool for building an API. After a few experiments trying to embrace a more domain oriented approach (largely thanks to Bob Martin's talk 'Architecture, the lost years'), I am both productive and comfortable writing complex business logic in plain ruby and attaching it to Rails.
And finally there is testing. When I need to move from RSpec's powerful BDD capabilities to py.test (our ML algorithms are written in Python) I see how much more productive (and confident) I am writing Ruby code.
The article indicates that the next big thing in server-side development is Javascript, but hasn't it been for the last 5 years?
First express, then the whole MVC moved over to javascript with backbone, angular, ember and meteor - but you still needed a server side API so at least the models and controllers were written twice (I still see the marshalling data in JSON as a "V"), and then came Angular V2 and before you even got the chance to play with it, you were using a "useless" framework. And then came React (which, btw is just the V, despite being (wrongly) promoted as an Angular alternative), but it doesn't quite specify how to connect with the data itself so then there is Flux, and JSX and Babel, Typescript, ES6. And, let's not forget the tooling behind everything javascript: node, iojs, requirejs, webpack, npm, bower (why are some packages available on both places btw?), grunt, gulp. And the cherry on the cake: no more REST, the next big thing is GraphQL.
I exaggerated on purpose, but as a software engineer who is not strictly focused on web development I appreciate being blindly guided by the decisions made by the Rails community.
It feels there is so much more serious/strong "competitors" for the next server-side Language/Framework duo now, than there was 8 years ago (Go, Javascript, Java8, Python 3, Haskell, Clojure, etc) - and from what I am able to keep up with, if I had to move, I'd go to Elixir/Phoenix, exactly because it seems to be fixing ruby's major issues while keeping rails' excellent choices.
But this moment hasn't arrived yet. What I'm looking for, before betting on the next big thing, is success, and as a @andycroll said: "If scalability and speed is a problem, congratulations, you're a success."
Node.js isn't a framework. What about comparing apples with apples?
Anyway, I think that the main change that's going on right now is that lots of web apps have a higher and higher percentage of the code written for the front end (web and mobile) rather than the back end.
Rails still has much higher productivity and tooling for back-end development than the Node.js frameworks I've seen for now, but that could become irrelevant for many startups in the medium term, just because a lot of the added value for them will come from the front end rather than the back end.
What would you call it? Because it's not a language either. JavaScript is the language.
That and nodejs.org calls it a runtime built on V8 :P
A lot of what Rails does, and even the little things, like naming conventions in ActiveRecord, intuitively make sense to me. If RoR ever does expire because another language/framework displaces it (maybe Elixir/Phoenix?) or because of poor/no support from a big company, I wouldn't look at it as a waste of time. Overall, I'm seeing a tried-and-true method of creating web applications and I'm enjoying it so far.
RoR can still get you where you need to go and fast, which is what you need when starting out. And if you ever find yourself in the same situation as Twitter, then you can make the switch...or better yet, improve on Ruby and give back to the Ruby community.
Rails can feel somewhat bloated, but it has a lot of functionality out of the box done transparently: generators, ORM and migrations, xss protection, templating, assets compilation, testing, configuration and naming conventions.
It's been a huge shock to me to see that a more modern framework on a more modern platform, express.js on node.js, has such a tiny subset of features we had in rails like 8 years ago. Granted, it's more like sinatra rather than rails, but nonetheless disappointing — what do all these people find in express that they couldn't have before.
If I wanted something with a high throughput of simple requests (like a chat server) or realtime responses using websockets, I'd typically go with a Node.JS inspired framework like Express.
But as this thread states, developer productivity can't be overstated, if the shipped code does what is needed.
Ugh, I so disagree with that statement and this whole post. The company culture should be one that promotes using any technology, as long as it solves the problem. You should be hiring engineers who are comfortable picking up any language/framework, not fanboys who can only develop in X or Y.
As a start-up, you should be trying to iterate as fast as you can, not future-proofing your application. Chances are, your application will get a complete re-write once you've got enough engineers, or you're just a badass from the get-go and the code is solid all around regardless of what language or framework you used.
I can't stress this enough, but like it or not Rails (and Django) are some of the most feature complete frameworks out there. Particularly because of the ecosystem they've created and the community that supports them.
As far as remarks about Ruby or language X being slow. It really doesn't matter. The primary cause for slow applications is poor architecture and shitty code, not the speed of the language. People building one massive piece of shit monolithic application because they didn't bother to learn about microservices. Not to mention the amount of engineers who haven't gotten a clue about how to scale an application. With some proper HTTP caching and nginx to help you bypass the entire application layer, you can speed up your application by orders of magnitude.
The comment about Django being a Rails clone... wow, just wow. Although they share the Active Record design pattern for the ORM, they are vastly different.
This post makes my blood boil, because it's about language flame wars and fanboys.
So you end up being forced to optimize earlier, and the process of optimizing a single small component is generally simpler (you can profile just that process, for instance).
That said, there's nothing keeping you from gaining many of the same benefits from a well-disciplined, modular monolith, and I think there's a pretty high risk of a fast-moving and over-stressed team (like a lot of startups) being put under more stress by the time and complexity costs of microservices, and thus making much worse decisions than they would on a monolith.
In practice, I see service architecture as a way of making people think harder about how different parts relate to each other.
Personally, it would take a lot for me to switch a part of my monolith to a microservice and lose the speed of having everything done in the same process and the guarantees that having a single relational database offers. Having to reconcile data that got off sync because it was in two different data stores is not fun for anyone, and, to me, it's not worth it just to force yourself to not call any private methods on the other service. I just expose a public ABI and say "to interact with this part of the application, you may only call these functions here".
If you have a web application that handles most of the traffic on your site, and you have some management task/process that hogs resources in the same application, you're affecting your end users by running those processes on the same service.
The idea of microservices is to separate components so one does not affect the other, and you can scale individual components easily.
Say you have services X, Y, and Z. Service Z handles a lot of traffic and is becoming a bottleneck to the whole system. You spin up 2-3 more instances, throw a load balancer in front of them, and increase throughput, all without ever touching the rest of the system. Pretty seamless!
In addition, monolithic systems tend to be a pain in the ass for release cycles.
Microservices allow you to very easily bring components up and down and do zero down time deploys by using a load balancer.
Using our previous example, consider doing a release 2.0 for service Y. You spin up an additional instance of service Y with version 2.0 and the old instance is running version 1.0.
You take the old instance out of the load balancer and stick the new one in. With the flip of a switch, your end user ends up using version 2.0 of service Y, without ever having to bring the system down.
Now obviously microservices aren't the right design decision for every application. But as your system grows and uses different components, it's usually best to separate them out as individual services so that you can scale horizontally using load balancers.
On the other hand, I think [Phoenix](http://www.phoenixframework.org/) could be the next big web thing. Not b/c it is super fast (although still faster than Rails) but b/c it is super stable and easily distributed.
The big advantage of Node.js (and thus Sails) is, of course, that the front end and back end can be written in the same language (ie. less to learn), but that might change in a few years with [WebAssembly](https://medium.com/javascript-scene/what-is-webassembly-the-...).
A "faster" language only gives a linear improvement in performance. It's only worth it if a 5-10x increase in hardware cost crosses the line between profit and failure. If it doesn't, I'll choose the tools that get the job done with half the team size and lets them get home early every time.
It's important to note that Express, the most popular Node framework, is a clone of Ruby's Sinatra, not of Rails. That's a great back-end when your front-end is iOS or React and you have a relatively simple data model. But it's not as strong a solution if you need to do server-rendered pages (which we need to support IE8). The bigger issue is that Rails is just a much more mature and full-featured framework than Express or Sails.js (which is designed to be Rails for Node). From migrations to validations to strong parameters to many other areas, Rails just offers a ton of back-end functionality that is not as mature on Node frameworks. The big question is how much back-end business logic needs to be implemented.
I haven't run into any issues with Ruby's server performance. AWS instances are easy to spin up, and any Ruby compute time is almost certainly going to be overwhelmed by network and database access. The performance we're focused on is developer productivity, and I think Ruby retains an advantage there over Javascript (though obviously we use both). If I were trying to support millions of simultaneous web socket connections, I would almost certainly go with Node (or maybe Go), but I remain a huge fan of the Rails platform.