Yeah I wonder what led them down the drastic fork trajectory rather than considering this approach… kind of interesting this wasn’t even acknowledged in the article
This is kind of a poor argument. Its examples are unrealistic, so it’s hard to take the author seriously. It doesn’t delve deep into things like the risks of a strict inheritance hierarchy vs. the benefits of functional composition, or more interesting things like the subtleties of using module-scoped state versus function or class-scoped state. The list goes on.
Instead of a slightly dogmatic and mostly unsubstantiated stance, I find less opinionated guidance on what to do when much more helpful. After all the language has all of these constructs for a reason.
While I may see a strong argument for a lighter-weight programming model, it is not laid out in this article.
We ran RC4 in production and we're running 1.12.1GA in production right now as well. We have been making money while running this and serving live customer traffic so we consider it production :)
The point I'm trying to make is that these clustering capabilities are directly inside docker, so you don't have to run anything else but Docker. That is a huge win for us
we tried using EFS for shared storage but quickly depleted our I/O bursting credits and our throughput dropped to a grinding halt, because our app's worklaod is both disk write and read intensive. No solutions yet
Incorrect - that's what we're running currently but as soon as the routing mesh issues are resolved you can start running apps that listen on ports too