This article is religion bait. TL;DR: For most things, I would put node at the top for many new web apps because of its surface similarity to frontend. -- Af

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