I wouldn’t have much heartburn over using non-ECC RAM for servers running Ruby code. I’d be a lot more afraid to run a database box without ECC RAM for extended periods of times where you’re flushing to permanent storage.
I’d be worried by any box that was acting as permanent storage on its own. Network equipment has been known to corrupt data in transit even. I prefer to go distributed as early as possible: the client explicitly makes requests to multiple backends (ultimately cassandra-like). Then it doesn’t matter if one element fails or corrupts data.
It’s interesting to note that the a bunch of this post is about low-end, low-core, but powerful machines. He talks about buying one processor vs another because one has like a 10% better performance than the other. All to run….Ruby. Which is 20 - 40x slower than other choices. You could buy all the ECC you want and high-core-but-slower machines by switching to Node, or Go, or Java or basically anything. It feels like missing the forest from the trees.
The expense of 20-40x as many machines is probably less than one extra dev, whereas the inexpressiveness of Go or Java or the unmaintainability of Node could be big drag on development (2x? 10x?). OTOH a one-off couple of hours to reduce the number of machines by 10% is probably worth it.
But that server cost will only continue to grow (unless you don’t plan on having a successful/popular site) and soon your infra will grow. Eventually that will cause you serious pain. He obviously has reasons for choosing Ruby-on-Rails, but at this point in time, I feel Ruby is a bad decision. It isn’t performant, and while Go, Java, and Elixir, all have specific challenges related to them, the benefits outweigh the negatives in most cases. I really believe that while Ruby-on-Rails was important for what it did to web development, people need to break out of their shells, take off their rose-tinted glasses and explore languages that they (too often) dismiss out of hand.
Not saying that optimizing the hardware to reduce costs isn’t important (it’s especially important for single threaded apps), but I think a lot of people fall into the “how can we reduce costs now” trap. I feel if he approached the use of Ruby as skeptically as he approached ECC-RAM then he would probably find something that fits his site much better cough Elixir cough.
Also, with Java 8 I don’t see any issues with doing web development. You have a robust ecosystem, an extremely well optimized runtime, good thread support, and deployment is pretty damn easy. Not saying it’s perfect, but I don’t think that it has the same limitations as Go.
Scaling is a nice problem to have; as long as each server more than covers its own costs then you’re fine. And if things really take off then you can afford the trouble of rewriting into a more performant language; once a system is handling 10x the traffic it once was it probably needs substantial rewriting anyway.
I can sympathise with your annoyance at the gratuitous inefficiency of Ruby, but honestly I wouldn’t weigh that kind of performance factor very much in my evaluation. If you believe that Ruby will give you even a modest development speedup (1.2x ?) then it’s probably worthwhile. (I use Scala which IMO has the upsides of both, but if I had to choose between Ruby and Go/Java/Node I’d choose Ruby and wouldn’t feel bad about it).
I get the wait until we hit scale argument, but I look at all the Rails sites that have taken off and now face (or faced) large refactors and I just don’t get the reason for waiting considering how much pain they seem to cause. Once you start to optimize you servers for high single thread performance then I think you lock yourself in. Then a refactor is a refactor AND a server re-purchase.
The logic isn’t even the hardest part of what they are doing imo, the real time sink is the DB arch and management.
I’d be really surprised if Go was inexpressive relative to Ruby, in a meaningful way. Python and Ruby developers seem to have zero problem switching over to Go as the type system is basically what they are doing anyways. And it’s probably 40x faster and can handle tens of thousands more concurrent requests.
If you really want to choose something that is friendly to Ruby devs and is good for web/concurrency then Elixir should be the go to, as Elixir is very Rubyist friendly. If you need real computational perf then Go is a great fit. Also, I think interest in RoR is waning as it is. Choosing another language and having your devs learn the new language just seems like a better idea.
The rebuttal to this was posted a few weeks ago:
https://lobste.rs/s/vdyh6n/why_use_ecc
I wouldn’t have much heartburn over using non-ECC RAM for servers running Ruby code. I’d be a lot more afraid to run a database box without ECC RAM for extended periods of times where you’re flushing to permanent storage.
I’d be worried by any box that was acting as permanent storage on its own. Network equipment has been known to corrupt data in transit even. I prefer to go distributed as early as possible: the client explicitly makes requests to multiple backends (ultimately cassandra-like). Then it doesn’t matter if one element fails or corrupts data.
It’s interesting to note that the a bunch of this post is about low-end, low-core, but powerful machines. He talks about buying one processor vs another because one has like a 10% better performance than the other. All to run….Ruby. Which is 20 - 40x slower than other choices. You could buy all the ECC you want and high-core-but-slower machines by switching to Node, or Go, or Java or basically anything. It feels like missing the forest from the trees.
The expense of 20-40x as many machines is probably less than one extra dev, whereas the inexpressiveness of Go or Java or the unmaintainability of Node could be big drag on development (2x? 10x?). OTOH a one-off couple of hours to reduce the number of machines by 10% is probably worth it.
But that server cost will only continue to grow (unless you don’t plan on having a successful/popular site) and soon your infra will grow. Eventually that will cause you serious pain. He obviously has reasons for choosing Ruby-on-Rails, but at this point in time, I feel Ruby is a bad decision. It isn’t performant, and while Go, Java, and Elixir, all have specific challenges related to them, the benefits outweigh the negatives in most cases. I really believe that while Ruby-on-Rails was important for what it did to web development, people need to break out of their shells, take off their rose-tinted glasses and explore languages that they (too often) dismiss out of hand.
Not saying that optimizing the hardware to reduce costs isn’t important (it’s especially important for single threaded apps), but I think a lot of people fall into the “how can we reduce costs now” trap. I feel if he approached the use of Ruby as skeptically as he approached ECC-RAM then he would probably find something that fits his site much better cough Elixir cough.
Also, with Java 8 I don’t see any issues with doing web development. You have a robust ecosystem, an extremely well optimized runtime, good thread support, and deployment is pretty damn easy. Not saying it’s perfect, but I don’t think that it has the same limitations as Go.
Scaling is a nice problem to have; as long as each server more than covers its own costs then you’re fine. And if things really take off then you can afford the trouble of rewriting into a more performant language; once a system is handling 10x the traffic it once was it probably needs substantial rewriting anyway.
I can sympathise with your annoyance at the gratuitous inefficiency of Ruby, but honestly I wouldn’t weigh that kind of performance factor very much in my evaluation. If you believe that Ruby will give you even a modest development speedup (1.2x ?) then it’s probably worthwhile. (I use Scala which IMO has the upsides of both, but if I had to choose between Ruby and Go/Java/Node I’d choose Ruby and wouldn’t feel bad about it).
I get the wait until we hit scale argument, but I look at all the Rails sites that have taken off and now face (or faced) large refactors and I just don’t get the reason for waiting considering how much pain they seem to cause. Once you start to optimize you servers for high single thread performance then I think you lock yourself in. Then a refactor is a refactor AND a server re-purchase.
The logic isn’t even the hardest part of what they are doing imo, the real time sink is the DB arch and management.
I’d be really surprised if Go was inexpressive relative to Ruby, in a meaningful way. Python and Ruby developers seem to have zero problem switching over to Go as the type system is basically what they are doing anyways. And it’s probably 40x faster and can handle tens of thousands more concurrent requests.
If you really want to choose something that is friendly to Ruby devs and is good for web/concurrency then Elixir should be the go to, as Elixir is very Rubyist friendly. If you need real computational perf then Go is a great fit. Also, I think interest in RoR is waning as it is. Choosing another language and having your devs learn the new language just seems like a better idea.