4 ms·

Compiled, concurrency/parallelism-focused language is more performant than a dynamically typed, interpreted language in a micro benchmark. News at 11. While it

by gtaylor 13y ago

Compiled, concurrency/parallelism-focused language is more performant than a dynamically typed, interpreted language in a micro benchmark. News at 11. While it'd be great to get to the point where you need to worry a lot about performance, the reality is that most projects won't ever get there. Some of us will fail quite a few times before getting to the point of having to worry about Ruby-specific performance issues. Don't get me wrong, I have really enjoyed playing with Go. I just think we have a tendency to geek out about "performance", when it's not nearly as important as productivity/maintainability for most of us. Apologies for the rant, but these benchmarks are just short of useless, and I wish we would spend more time "benchmarking" ease of development, maintainability, and talent availability.

arkitaip 13y ago
Coding in Go isn't more difficult than coding in Ruby. Any competent dev should be able to pick it up and be productive using it within a couple of weeks. So for the same effort you get considerable performance improvements.
- MagicWishMonkey 13y ago
  The problem isn't picking up a language, it's language support (and 3rd party libraries) that are crucial. For example, if a client requests that I add a module to my application to fetch records from AD and cross reference with data pulled from salesforce, am I going to have to write a ton of low level networking code by hand or will it be trivial to find a robust open source module that does all of that for me?
- andrewvc 13y ago
  The ruby ecosystem is more valuable than the ruby VM or any of the other stuff. Go libraries are not nearly as comprehensive as ruby gems. Ultimately library availability affects productivity as much as language features do.
  - gtaylor 13y ago
    Was going to reply to arkitaip, but you nailed it on the head. I have really enjoyed working with Go, but the much more limited ecosystem does mean rolling up your sleeves and doing it yourself more often. So I agree, I don't think you can say Go is just as fast for development in every case. But these are much more interesting discussions than these silly micro benchmarks...

by gtaylor 13y ago

arkitaip 13y ago

Coding in Go isn't more difficult than coding in Ruby. Any competent dev should be able to pick it up and be productive using it within a couple of weeks. So for the same effort you get considerable performance improvements.

MagicWishMonkey 13y ago
The problem isn't picking up a language, it's language support (and 3rd party libraries) that are crucial. For example, if a client requests that I add a module to my application to fetch records from AD and cross reference with data pulled from salesforce, am I going to have to write a ton of low level networking code by hand or will it be trivial to find a robust open source module that does all of that for me?
andrewvc 13y ago
The ruby ecosystem is more valuable than the ruby VM or any of the other stuff. Go libraries are not nearly as comprehensive as ruby gems. Ultimately library availability affects productivity as much as language features do.
- gtaylor 13y ago
  Was going to reply to arkitaip, but you nailed it on the head. I have really enjoyed working with Go, but the much more limited ecosystem does mean rolling up your sleeves and doing it yourself more often. So I agree, I don't think you can say Go is just as fast for development in every case. But these are much more interesting discussions than these silly micro benchmarks...