5 ms·

Given that you will have to figure out scaling issues eventually anyway, the speed of compiled languages should NOT be weighed heavier than programming ease in

Given that you will have to figure out scaling issues eventually anyway, the speed of compiled languages should NOT be weighed heavier than programming ease in your decisionmaking. Programmer time is FAR more expensive than hardware these days.

free652 13y ago
Actually it matters a lot. Since when the programmers manage servers? More servers = more people managing them. And if for a compiled language you need 2 data centers for Ruby you need 20... And level 4 data centers are expensive. Ruby is great at what it does. I don't see Node.js replacing it anytime soon. But Ruby won't be in enterprise anytime soon also.
gesman 13y ago
Throwing money in hardware to compensate for chosen framework's sluggishness doesn't seems to run well with people who sign the checks.
- outside1234 13y ago
  Neither does buying extra programmers.
- bcoates 13y ago
  This has not been my experience. Any problem that can be solved by buying another server is generally considered to be a solved problem.
  - epsylon 13y ago
    Yep, engineer time costs probably orders of magnitude more than adding a few servers.
deleted 13y ago
[deleted]
- beat 13y ago
  Correlation is not causation. A 600x performance difference doesn't suggest a language-level performance issue. Quite the opposite, in fact! Multiple orders of magnitude performance problems are usually algorithmic in nature, or a really hard physical bottleneck.
  - lmm 13y ago
    Point taken; thinking about it more, AIUI they had a 1 request - 1 thread model, whereas our architecture was (despite the old tech) more event-driven. Still, what do you think is a typical ratio? I've read pieces suggesting language-level overhead of 60x-70x is normal.
    - beat 13y ago
      For the exact same algorithm of moderate complexity, there should be less than an order of magnitude of performance difference between any languages, from a high-level language like Ruby to hand-coded assembly. Performance issues come from blocking and bottlenecks, not programming language choice. Waiting on database queries, waiting on networks, waiting on disk - those hurt. Using O(n^2) algorithms when O(n log n) or O(1) could be used hurts. Bad indexing on data sources hurts. Handling excessive or redundant data hurts. Threads that could be doing work getting blocked (or deadlocked) by other threads that could get out of the way in a better architecture - that hurts. Programming languages, that's nothing. And in Ruby's case, even that limit can be addressed. Ditch the perceived inefficiencies of the Ruby interpreter in favor of JRuby running on the highly tuned JVM, and see if things are faster.
- bdcravens 13y ago
  It bears saying that using an inherently multi-threaded library like Sidekiq would enable much higher performance than you're describing.
jalopy 13y ago
I've toed this line for a long time, but concern about performance is really starting to be an issue for me when I make a decision about what language/framework to use. Here's my line of thinking: " If another language can provide 10x more performance in 2x the code of Ruby, that's a tradeoff I'd seriously consider. If I do ever have a hit on my hands, and it starts scaling quickly, there's a cost, management, and maintenance issue to bottlenecking myself with Ruby. " I realize that there are many parts to a system and that other parts encounter scaling considerations before the programming language does - ie database. However, it seems there are known, quick to implement solutions that can solve the data scaling problem in a cost effective manner. Reimplementing my application logic with another language seems to be a very cost-ineffective and time consuming task. I'd rather head that concern off at the pass by picking that language with 10x the performance and 2x the amount of code.
- pkolaczk 13y ago
  What if there are languages that offer 10x performance with the same amount of code? And what if there are other languages that have not only faster runtimes, but are also much faster to code in?

free652 13y ago

Actually it matters a lot. Since when the programmers manage servers? More servers = more people managing them. And if for a compiled language you need 2 data centers for Ruby you need 20... And level 4 data centers are expensive. Ruby is great at what it does. I don't see Node.js replacing it anytime soon. But Ruby won't be in enterprise anytime soon also.

gesman 13y ago

Throwing money in hardware to compensate for chosen framework's sluggishness doesn't seems to run well with people who sign the checks.

outside1234 13y ago
Neither does buying extra programmers.
bcoates 13y ago
This has not been my experience. Any problem that can be solved by buying another server is generally considered to be a solved problem.
- epsylon 13y ago
  Yep, engineer time costs probably orders of magnitude more than adding a few servers.

deleted 13y ago

[deleted]

beat 13y ago
Correlation is not causation. A 600x performance difference doesn't suggest a language-level performance issue. Quite the opposite, in fact! Multiple orders of magnitude performance problems are usually algorithmic in nature, or a really hard physical bottleneck.
- lmm 13y ago
  Point taken; thinking about it more, AIUI they had a 1 request - 1 thread model, whereas our architecture was (despite the old tech) more event-driven. Still, what do you think is a typical ratio? I've read pieces suggesting language-level overhead of 60x-70x is normal.
  - beat 13y ago
    For the exact same algorithm of moderate complexity, there should be less than an order of magnitude of performance difference between any languages, from a high-level language like Ruby to hand-coded assembly. Performance issues come from blocking and bottlenecks, not programming language choice. Waiting on database queries, waiting on networks, waiting on disk - those hurt. Using O(n^2) algorithms when O(n log n) or O(1) could be used hurts. Bad indexing on data sources hurts. Handling excessive or redundant data hurts. Threads that could be doing work getting blocked (or deadlocked) by other threads that could get out of the way in a better architecture - that hurts. Programming languages, that's nothing. And in Ruby's case, even that limit can be addressed. Ditch the perceived inefficiencies of the Ruby interpreter in favor of JRuby running on the highly tuned JVM, and see if things are faster.
bdcravens 13y ago
It bears saying that using an inherently multi-threaded library like Sidekiq would enable much higher performance than you're describing.

jalopy 13y ago

I've toed this line for a long time, but concern about performance is really starting to be an issue for me when I make a decision about what language/framework to use. Here's my line of thinking: " If another language can provide 10x more performance in 2x the code of Ruby, that's a tradeoff I'd seriously consider. If I do ever have a hit on my hands, and it starts scaling quickly, there's a cost, management, and maintenance issue to bottlenecking myself with Ruby. " I realize that there are many parts to a system and that other parts encounter scaling considerations before the programming language does - ie database. However, it seems there are known, quick to implement solutions that can solve the data scaling problem in a cost effective manner. Reimplementing my application logic with another language seems to be a very cost-ineffective and time consuming task. I'd rather head that concern off at the pass by picking that language with 10x the performance and 2x the amount of code.

pkolaczk 13y ago
What if there are languages that offer 10x performance with the same amount of code? And what if there are other languages that have not only faster runtimes, but are also much faster to code in?