6 ms·

Ruby isn't fast enough. We're getting 2-20x speedups by switching to Go. (Some things are io-bound waiting on the database, that's the 2x end of the scale, some

Ruby isn't fast enough. We're getting 2-20x speedups by switching to Go. (Some things are io-bound waiting on the database, that's the 2x end of the scale, some things we're doing more compute on and that's the 20x end of the scale.)

ryan_j_naughton 10y ago
Agreed. On non-DB bound things, I've experienced a 50-100X speedup with Go.
nemild 10y ago
Are you surprised that static type/compiled languages like Go (or C or C++ or many others) are significantly faster than many dynamic type/interpreted languages like Ruby and Javascript? If performance alone is important to you (rather than many other considerations like ease of coding, library ecosystem, number of developers who know the language) - you'll almost always do better with compiled languages - especially those with good concurrency support. But the power of many of the dynamic languages is that they provide an ease of coding that reduces the cost of development significantly, especially for earlier stage companies where the benefits of performance may be less important than other considerations. For many teams I've seen, you can also rewrite the most computationally heavy parts using FFI, allowing you to have the benefits of dynamic languages without some of its disadvantages for computationally heavy work (though it comes at a cost of adding a new language into your stack). I say this teasingly, but you may want to rewrite your slow Golang codebase to see how much faster performance you could get with C++ (but again, it comes with a cost to your development team - and only your team can decide what tradeoffs to make given the stage of your product/company).
- brlewis 10y ago
  Why did you throw JavaScript in there? V8 is in the same 20x-faster-than-Ruby club that Go is in. http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=yarv http://benchmarksgame.alioth.debian.org/u64/compare.php?lang...
  - nemild 10y ago
    Not as a slight to Javascript, but simply because it is an interpreted language like Ruby - though you're right that benchmarks show a large performance gap. (Javascript has significantly more investment in it, which is partially why it's such a performant language for an interpreted language) Compare Javascript to many compiled languages, and it's still much slower with a heavier memory footprint (for heavy computation especially at internet scale or for realtime needs like graphics, you'll want to at least consider compiled languages). But my original point is that performance shouldn't be the primary characteristic you measure a language or framework on, unless it is absolutely critical for your needs and you're fine with the other disadvantages that might bring.
    - brlewis 10y ago
      "Interpreted language" is an imprecise term. A language is a language whether implemented in a compiler, an interpreter, or a REPL that includes a compile step. JavaScript is faster than Go in some benchmarks, and slower in others. In benchmarks where it's much slower, the reason isn't that JavaScript interpreters exist. The reason is design decisions in the JavaScript language that make optimization difficult. http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=go http://benchmarksgame.alioth.debian.org/u64/compare.php?lang... Someone familiar with the V8 compiler might correct me, but I suspect that the binary tree program is slowed by JavaScript object-property access always being a dictionary lookup. I suspect that fasta and reverse-complement are slowed by JavaScript's one-type numeric tower ... everything's a float.
      - pcwalton 10y ago
        JavaScript property lookup hasn't been forced into hash table access for probably a decade now.
      - igouy 10y ago
        > … I suspect that the binary tree program is slowed by … I suspect that fasta and reverse-complement are slowed by … Maybe it's the way the programs are written. For example, binary-trees Go #6 program is no longer shown because it doesn't do what's required.
- brianolson 10y ago
  It's not a surprise, just a counterpoint. We have a big webapp in Ruby, and a bunch of data processing stuff also in Ruby because that was convenient to write it all in the common server side language. But now we have the problem that actually the data processing needs to go faster. Our page load speed isn't great either, but it's easier to try changing out little parts on the back end.
  - nemild 10y ago
    I totally agree, and it's great to hear the backstory of your process, which is typical of so many companies that start with Ruby/RoR and then grow (e.g., Twitter, Github). Here's a question that others might value for you: Would you have written the app originally in a different language(s) or framework(s)? Or is the approach you chose (start with Ruby then selectively refactor), the approach you still would have taken given all you know now?
    - MrBra 10y ago
      What about, probably they couldn't even be here commenting this post if they hadn't started off with Ruby/Rails?
- brlewis 10y ago
  Separate reply because it's a separate topic: Dynamic types aren't the reason for Ruby's slowness either. The Racket code that beat Ruby by 25x in the Mandelbrot benchmark has no type annotations: http://benchmarksgame.alioth.debian.org/u64/program.php?test=mandelbrot&lang=racket&id=4 http://benchmarksgame.alioth.debian.org/u64/program.php?test...
  - igouy 10y ago
    Incidentally, neither u64 nor u32q are being updated -- that data is from before November 2015.
- mixedCase 10y ago
  The thing about Go is that being a simple language and not requiring so much of the bureaucracy other statically typed+compiled languages demand means you lose very little development speed (if any) while gaining a tremendous amount of speed, obsoleting Ruby in a huge amount of situations. The same cannot be said of languages like Java, C#, C++, C or Rust, for different reasons.
  - twic 10y ago
    As someone who went from Java to Go, i'd say the opposite - i lost a lot of development speed due to the poorer tooling and lack of expressiveness.
    - mixedCase 10y ago
      I was comparing it to Ruby. Java has the bureaucracy I mentioned and that expresiveness you speak of is often the biggest creator of technical debt which specially shines when someone else has to work with your code and understand all your different abstractions. As far as tooling goes, what are you particularly missing from the Java ecosystem? Honestly I have big gripes with Java's tooling, most important of all the language's hard-dependency on big IDEs to get anything done.
      - tobz 10y ago
        So would you say that Ruby's ability to monkeypatch third-party libraries at runtime is not the type of expressiveness that "specially shines" when others have to work with your code? Because I've had to deal with that type of shit before. Java might have a history of AbstractBuilderFactorySingletons, but you'd be hard-pressed to find an IDE that couldn't make quick work of it. Monkeypatched at runtime? Good luck!
        bazzargh 10y ago
        I've had to deal with both and monkeypatching isn't the worst thing, because it's static & greppable. foo.method(:bar).source_location ...and you've found the hack. In java land, third party breakage is just as common and countless times I had to decompile random jars to figure out where the bug was, and resort to strace to figure out which jars were being loaded by misbehaving classloaders. Forking a gem is preferable to monkeypatching, but sometimes this can lead to a chain of forks just to change one line in an indirect dependency, worse than the patch. No, the worst thing is method_missing. Methods that appear nowhere in the source getting invoked, and they only appear at runtime. You can do similar things with InvocationHandler in java but it gets used far, far less.
chillacy 10y ago
Are you comparing Rails to whatever framework you're using in Go, or ruby to go? Because rails is notoriously slow and heavyweight, even for ruby. Sinatra is faster but then you're lacking in features and conveniences that Rails provides, like ActiveSupport and ActiveRecord

ryan_j_naughton 10y ago

Agreed. On non-DB bound things, I've experienced a 50-100X speedup with Go.

nemild 10y ago

Are you surprised that static type/compiled languages like Go (or C or C++ or many others) are significantly faster than many dynamic type/interpreted languages like Ruby and Javascript? If performance alone is important to you (rather than many other considerations like ease of coding, library ecosystem, number of developers who know the language) - you'll almost always do better with compiled languages - especially those with good concurrency support. But the power of many of the dynamic languages is that they provide an ease of coding that reduces the cost of development significantly, especially for earlier stage companies where the benefits of performance may be less important than other considerations. For many teams I've seen, you can also rewrite the most computationally heavy parts using FFI, allowing you to have the benefits of dynamic languages without some of its disadvantages for computationally heavy work (though it comes at a cost of adding a new language into your stack). I say this teasingly, but you may want to rewrite your slow Golang codebase to see how much faster performance you could get with C++ (but again, it comes with a cost to your development team - and only your team can decide what tradeoffs to make given the stage of your product/company).

brlewis 10y ago
Why did you throw JavaScript in there? V8 is in the same 20x-faster-than-Ruby club that Go is in. http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=yarv http://benchmarksgame.alioth.debian.org/u64/compare.php?lang...
- nemild 10y ago
  Not as a slight to Javascript, but simply because it is an interpreted language like Ruby - though you're right that benchmarks show a large performance gap. (Javascript has significantly more investment in it, which is partially why it's such a performant language for an interpreted language) Compare Javascript to many compiled languages, and it's still much slower with a heavier memory footprint (for heavy computation especially at internet scale or for realtime needs like graphics, you'll want to at least consider compiled languages). But my original point is that performance shouldn't be the primary characteristic you measure a language or framework on, unless it is absolutely critical for your needs and you're fine with the other disadvantages that might bring.
  - brlewis 10y ago
    "Interpreted language" is an imprecise term. A language is a language whether implemented in a compiler, an interpreter, or a REPL that includes a compile step. JavaScript is faster than Go in some benchmarks, and slower in others. In benchmarks where it's much slower, the reason isn't that JavaScript interpreters exist. The reason is design decisions in the JavaScript language that make optimization difficult. http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=go http://benchmarksgame.alioth.debian.org/u64/compare.php?lang... Someone familiar with the V8 compiler might correct me, but I suspect that the binary tree program is slowed by JavaScript object-property access always being a dictionary lookup. I suspect that fasta and reverse-complement are slowed by JavaScript's one-type numeric tower ... everything's a float.
    - pcwalton 10y ago
      JavaScript property lookup hasn't been forced into hash table access for probably a decade now.
    - igouy 10y ago
      > … I suspect that the binary tree program is slowed by … I suspect that fasta and reverse-complement are slowed by … Maybe it's the way the programs are written. For example, binary-trees Go #6 program is no longer shown because it doesn't do what's required.
brianolson 10y ago
It's not a surprise, just a counterpoint. We have a big webapp in Ruby, and a bunch of data processing stuff also in Ruby because that was convenient to write it all in the common server side language. But now we have the problem that actually the data processing needs to go faster. Our page load speed isn't great either, but it's easier to try changing out little parts on the back end.
- nemild 10y ago
  I totally agree, and it's great to hear the backstory of your process, which is typical of so many companies that start with Ruby/RoR and then grow (e.g., Twitter, Github). Here's a question that others might value for you: Would you have written the app originally in a different language(s) or framework(s)? Or is the approach you chose (start with Ruby then selectively refactor), the approach you still would have taken given all you know now?
  - MrBra 10y ago
    What about, probably they couldn't even be here commenting this post if they hadn't started off with Ruby/Rails?
brlewis 10y ago
Separate reply because it's a separate topic: Dynamic types aren't the reason for Ruby's slowness either. The Racket code that beat Ruby by 25x in the Mandelbrot benchmark has no type annotations: http://benchmarksgame.alioth.debian.org/u64/program.php?test=mandelbrot&lang=racket&id=4 http://benchmarksgame.alioth.debian.org/u64/program.php?test...
- igouy 10y ago
  Incidentally, neither u64 nor u32q are being updated -- that data is from before November 2015.
mixedCase 10y ago
The thing about Go is that being a simple language and not requiring so much of the bureaucracy other statically typed+compiled languages demand means you lose very little development speed (if any) while gaining a tremendous amount of speed, obsoleting Ruby in a huge amount of situations. The same cannot be said of languages like Java, C#, C++, C or Rust, for different reasons.
- twic 10y ago
  As someone who went from Java to Go, i'd say the opposite - i lost a lot of development speed due to the poorer tooling and lack of expressiveness.
  - mixedCase 10y ago
    I was comparing it to Ruby. Java has the bureaucracy I mentioned and that expresiveness you speak of is often the biggest creator of technical debt which specially shines when someone else has to work with your code and understand all your different abstractions. As far as tooling goes, what are you particularly missing from the Java ecosystem? Honestly I have big gripes with Java's tooling, most important of all the language's hard-dependency on big IDEs to get anything done.
    - tobz 10y ago
      So would you say that Ruby's ability to monkeypatch third-party libraries at runtime is not the type of expressiveness that "specially shines" when others have to work with your code? Because I've had to deal with that type of shit before. Java might have a history of AbstractBuilderFactorySingletons, but you'd be hard-pressed to find an IDE that couldn't make quick work of it. Monkeypatched at runtime? Good luck!
      - bazzargh 10y ago
        I've had to deal with both and monkeypatching isn't the worst thing, because it's static & greppable. foo.method(:bar).source_location ...and you've found the hack. In java land, third party breakage is just as common and countless times I had to decompile random jars to figure out where the bug was, and resort to strace to figure out which jars were being loaded by misbehaving classloaders. Forking a gem is preferable to monkeypatching, but sometimes this can lead to a chain of forks just to change one line in an indirect dependency, worse than the patch. No, the worst thing is method_missing. Methods that appear nowhere in the source getting invoked, and they only appear at runtime. You can do similar things with InvocationHandler in java but it gets used far, far less.

chillacy 10y ago

Are you comparing Rails to whatever framework you're using in Go, or ruby to go? Because rails is notoriously slow and heavyweight, even for ruby. Sinatra is faster but then you're lacking in features and conveniences that Rails provides, like ActiveSupport and ActiveRecord