5 ms·

Sorry I used to work for Amazon and we did not allow Rails to be exposed to external customers for performance reasons. I think what you classify as high perfor

Sorry I used to work for Amazon and we did not allow Rails to be exposed to external customers for performance reasons. I think what you classify as high performance is very different what I classify as high performance. Btw. I haven't seen Rails or Ruby on this list in the top 50% for a while: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ I would prefer hard data as opposed to "this is a legend". UPDATE: Rails is number 399 out of 439, having 0.3% performance of the top frameworks in a plain text task. I know, facts hurt.

aledalgrande 5y ago
Oh yeah? Want an example? Apple. https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails-engineer-apple-media-products https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails...
- StreamBright 5y ago
  No, I want facts like a reproducible performance test like Techempower.
  - gosukiwi 5y ago
    GitHub uses Rails just fine. If it works for GitHub, it will most likely work for >90% of use-cases out there.
    - StreamBright 5y ago
      Did I write anywhere that Github does not use Rails or 90% of internet cannot be run on Rails?
- google234123 5y ago
  That job is for writing tools. So... not that performance critical.
  - aledalgrande 5y ago
    That specific job might be for tools. But open Apple Music in your browser and tell me what it is using?
jasonwatkinspdx 5y ago
That's just Amazon's policy, not some sort of fundamental constraint of Rails itself. While it's true Rails will use more ram than other options for a given traffic level, many of us have scaled it just fine. The techempower benchmarks aren't particularly useful for anything other than forum warrior style arguments. They don't really measure a realistic workload. Your last sentence is entirely unnecessary.
- StreamBright 5y ago
  I agree, HN needs less and less facts nowadays and more feelings about somebodies favorite tool or framework. The quality of comments are going below Reddit levels.
  - jasonwatkinspdx 5y ago
    You are the one being emotional, and obnoxiously toxic at that. Everything I said is factual. Many of us have built successful startups on rails. I'm a very pragmatic person in general and abhor the cheering and jeering dynamic you're actively courting in this thread.
    - dang 5y ago
      Please don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - dang 5y ago
    Please don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
aantix 5y ago
Your biggest constraint is programmer productivity, not server performance. Your concerns are further diminished ~ every two years. Please re-evaluate your assumptions on that timeline. This position was established by the company that owns the one of the largest server farms in the world? Are they looking to save on a few x-large instances? Seems short-sighted to me. Sub 50ms response times are very achievable with Rails. Throwing another server at it is a very reasonable response. Especially when you want your team to remain productive in a cohesive, batteries included framework. Plenty of real-world Rails examples to demonstrate this.
davidw 5y ago
Here's some hard data: Amazon is one of the largest internet companies out there, and most of us don't need to write anything approaching that kind of scale. Not by a long shot.
ksec 5y ago
I still don't understand why you are downvoted. The fact that it is being used at Shopify and Github doesn't make Ruby Rails Fast. It just means their Business Model fits its usage COGS. Especially true if you are a SaaS with low / no Free Tier or Non-Freemium model. Now that Shopify are spending hundred millions on cloud it absolutely make sense for them speed up Ruby Rails. I just hope it wont end up being like Twitter.
aantix 5y ago
Your assumptions in computing should be reevaluated every two years. https://mobile.twitter.com/brandonhilkert/status/1397319013399613448 https://mobile.twitter.com/brandonhilkert/status/13973190133...

aledalgrande 5y ago

Oh yeah? Want an example? Apple. https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails-engineer-apple-media-products https://jobs.apple.com/en-ca/details/200226089/ruby-on-rails...

StreamBright 5y ago
No, I want facts like a reproducible performance test like Techempower.
- gosukiwi 5y ago
  GitHub uses Rails just fine. If it works for GitHub, it will most likely work for >90% of use-cases out there.
  - StreamBright 5y ago
    Did I write anywhere that Github does not use Rails or 90% of internet cannot be run on Rails?
google234123 5y ago
That job is for writing tools. So... not that performance critical.
- aledalgrande 5y ago
  That specific job might be for tools. But open Apple Music in your browser and tell me what it is using?

jasonwatkinspdx 5y ago

That's just Amazon's policy, not some sort of fundamental constraint of Rails itself. While it's true Rails will use more ram than other options for a given traffic level, many of us have scaled it just fine. The techempower benchmarks aren't particularly useful for anything other than forum warrior style arguments. They don't really measure a realistic workload. Your last sentence is entirely unnecessary.

StreamBright 5y ago
I agree, HN needs less and less facts nowadays and more feelings about somebodies favorite tool or framework. The quality of comments are going below Reddit levels.
- jasonwatkinspdx 5y ago
  You are the one being emotional, and obnoxiously toxic at that. Everything I said is factual. Many of us have built successful startups on rails. I'm a very pragmatic person in general and abhor the cheering and jeering dynamic you're actively courting in this thread.
  - dang 5y ago
    Please don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- dang 5y ago
  Please don't perpetuate flamewars or tit-for-tat spats on HN. We're trying for something different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

aantix 5y ago

Your biggest constraint is programmer productivity, not server performance. Your concerns are further diminished ~ every two years. Please re-evaluate your assumptions on that timeline. This position was established by the company that owns the one of the largest server farms in the world? Are they looking to save on a few x-large instances? Seems short-sighted to me. Sub 50ms response times are very achievable with Rails. Throwing another server at it is a very reasonable response. Especially when you want your team to remain productive in a cohesive, batteries included framework. Plenty of real-world Rails examples to demonstrate this.

davidw 5y ago

Here's some hard data: Amazon is one of the largest internet companies out there, and most of us don't need to write anything approaching that kind of scale. Not by a long shot.

ksec 5y ago

I still don't understand why you are downvoted. The fact that it is being used at Shopify and Github doesn't make Ruby Rails Fast. It just means their Business Model fits its usage COGS. Especially true if you are a SaaS with low / no Free Tier or Non-Freemium model. Now that Shopify are spending hundred millions on cloud it absolutely make sense for them speed up Ruby Rails. I just hope it wont end up being like Twitter.

aantix 5y ago

Your assumptions in computing should be reevaluated every two years. https://mobile.twitter.com/brandonhilkert/status/1397319013399613448 https://mobile.twitter.com/brandonhilkert/status/13973190133...