unfortunately, i agree with you. Ive moved to elixir for all web work and the erlang vm just blows ruby out of the water at restapi/web services stuff. Im a huge ruby/rails fan though, and have earned a living off the ruby ecosystem. I just dont see how ruby can overcome the vm disadvantage to be honest, though id really like to see them try
They don't have to. With a good architecture (caching, etc) Rails scales well in the overwhelming majority of cases. Performance is only one of many things to worry about when choosing a technology.
It is, sometimes. But a cache hit in 50-150ns beats the pants off of a round trip to the backing database or microservice, which might take tens of milliseconds. That's 100,000-1,000,000x faster.
It's the same reason you'd never find a modern CPU without multiple layers of caching.
That's not the kind of caching GP was referring to, at least not to my reading. I think you'd be hard pressed to find any application level caching that could serve up a cache in the nanosecond range. At best you're looking at sub millisecond range, and that's when the cache lives in memory on the same hardware. Application caching on any modern cloud provider is almost always going to be a network call and best case you're looking at sub-10ms response time. And yes, while I definitely agree that it beats hundreds of ms by a wide margin, it can very easily bite you in the ass if you're not very careful about what gets cached. Caching is a performance hack, pure and simple.
True, I was only citing the figure for memory access times on x86 (according to a quick google). There's certainly going to be more overhead depending on how the cache is implemented, whether it's in memory, or swapped out/deliberately on disk, etc.
That said, I'd call it a fundamental architecture requirement (and one you can't really avoid anyway), given fundamental limitations imposed by the speed of light.
I use jRuby, which is great and an amazing piece of engineering. However, with Rails, you're only see about a 20% speed bump and out of the box it uses too much memory to run on Heroku's free tier. You'll also miss out on the gems with c extensions (for now I think that's about to change). Additionally, there seems to be a performance regression around includes and case statements. Your devops story can also be a bit trickier, depending upon what you're experienced with. I like jRuby a lot, but it's a mixed bag for the moment.
JRuby is painful to develop with compared to MRI. Running a test suite is slower, everything is slower even if you turn off JIT to startup the JVM faster and do other tricks that I don't remember. That's why Java developers usually work in IDEs that keep compiling and doing hot reloads constantly. Maybe that could apply to JRuby. Anybody here has experiences with a Ruby IDE and JRuby? Do you?
That's not surprising, it has some real problems with certain code, the edge cases are bad sometimes. We had a 20% perf bump, but probably 4x the memory use. That said, it gets better every release, and the JVM tooling is quite nice.
