The article is just wrong. > And it’s no wonder. Until Rails 4, the core framework didn’t even support concurrent request handling. And even in Rails 4, concur

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