5 ms·

>> But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffi

by fasteo 11y ago

>> But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffic system I don't get this reasoning.

fixxer 11y ago
They're going from Ruby, so Go is a pretty easy transition with respect to skill set and helped them accomplish scale (as seen from the analysis). I agree that other languages could accomplish the same effect, but I'm not surprised by their sentiment given where they were coming from.
Ao7bei3s 11y ago
Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. It makes perfect sense to me. What would you have recommended them, for a reasonably-high-performance server implementation? (Please don't say C.) https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=yarv&data=u64q https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...
- plydatbk 11y ago
  Lua would beat go every day of the week.
  - jbeja 11y ago
    As Clojure would beat Lua every second of a day.
    - plydatbk 11y ago
      show me the clojure firewall and I'll take you seriously. Or the even something simple as an interesting clojure ML project. Java gross.
    - bitcrusher 11y ago
      If you're talking about raw performance, I'm afraid you're mistaken. If you're perhaps referring to the 'aesthetics' of the language syntax, that's pretty subjective, in which case you're right for your tastes.
    - saosebastiao 11y ago
      I'm a big clojure fan and not the biggest Lua fan, but I'm afraid you are mistaken. You won't find any dynamically typed language implementation that can come close to LuaJIT for the general use case.
      - raspasov 11y ago
        What if you type hint everything in Clojure properly so all reflection is avoided? (does take some time, but with something like YourKit it'll be only a few hours max on a mid-size project)
  - cdelsolar 11y ago
    [citation needed]
- fasteo 11y ago
  >>> It makes perfect sense to me Yes. Other than some very basic scripts, I have never worked with Ruby, so I was not aware that it is so slow. Thanks for pointing that out. As for my recommendation, it is pretty standard worker architecture: Their system seems to be an ingesting-only system, that is, the clients are getting an empty HTTP 200 OK response. Given this, I would put openresty (nginx) in the front, with some trivial Lua code[1] to en-queue payloads to beanstalkd. Then, you can either have your workers inside openresty (using Openresty timers) or have them as separate processes and written in the language of choice. We have been using this for a couple of years now and it is working really well for our use case, also an ingesting-only system. [1] https://github.com/smallfish/lua-resty-beanstalkd/blob/master/t/02-put.t https://github.com/smallfish/lua-resty-beanstalkd/blob/maste...
  - sinzone 11y ago
    we use the same technology with KONG [1] [1] https://github.com/mashape/kong https://github.com/mashape/kong
- saosebastiao 11y ago
  Scala, Java, Clojure, C#, F#, Node, LuaJIT, Erlang, Elixir, Haskell, D, Nim... There are lots of reasonably fast options out there that aren't C.
- pjmlp 11y ago
  > Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. Than MRI Ruby you mean. The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.
  - dragonwriter 11y ago
    > > Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. > Than MRI Ruby you mean. Given the nature of orders-of-magnitude comparisons and the lack of Ruby implementations that are even one order of magnitude faster than MRI, "...than Ruby" is reasonably accurate if "...than MRI Ruby" is at all accurate. > The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation. Maybe, though that's unproven. AFAIK, actual Ruby implementations with AOT only seem to gain about a factor of 2 improvement, not an order of magnitude.
  - pselbert 11y ago
    That's exactly the space that Crystal [0] seems to be exploring. Statically type checked and pre-compiled via LLVM. So it isn't the Ruby designers themselves, but definitely Ruby flavored. 0: http://crystal-lang.org/ http://crystal-lang.org/
- andrewvc 11y ago
  There's nothing concurrent in this case, parallel sure, but concurrency wise this is all shared nothing. And languages are not faster than one another. They are faster at certain tasks but the variability for a given task is really case specific. For io heavy workloads like this underlying libraries and implementations dominate execution time. You could have written this in any number of languages. I don't know why go is more logical than say Java JavaScript.
- vidarh 11y ago
  > Go is 1-2 orders of magnitude faster than Ruby That may be true for some types of code, but for an app that's predominantly shuffling data over the network you should be spending most of the time in kernel space executing syscalls, and then language differences are largely irrelevant. > and much easier to write concurrent code in. How? Writing concurrent code in Ruby is trivial since 1.9.x (prior to 1.9 you had to battle the green threads in MRI for some stuff), which isn't exactly new.
- arthurcolle 11y ago
  I was always a big fan of Erlang's concurrency model but I've really been getting into Elixir lately. It is just such a productive language to write and lends itself to extremely maintainable codebases.
tptacek 11y ago
It's less about Go being incredibly fast than about Ruby being anomalously slow. It makes sense if you start from the presumption that Go is the only "fast" language they're considering.
- fixxer 11y ago
  But that would prevent the knee-jerk tribal language war response.
- vidarh 11y ago
  Frankly, if you're going to be processing requests and shuffling them to S3, Ruby is nowhere near being the limiting factor unless you do something pathologically bad. Having spent time recently optimizing a setup that does pretty much exactly what they're doing (in Rails; I don't like Rails, but in this case Rails is not a problem), the time saved doing things like eliminating unnecessary buffering all over the place (e.g. POSTs gets buffered by pretty much everything that likes to consider itself a web server, sometimes multiple times; if you e.g. run Nginx in front of pretty much any Ruby web servers running Rails, worst case you may end up with things passed through at least 3, possibly 4 buffers). Basically they should be IO bound.
vidarh 11y ago
They're unfamiliar with network programming, and so picked a language that seems fast to them, is my assessment. Based on their description, they should be IO bound. If they're IO bound, their system should spend the vast majority of time in the kernel executing system calls. If they do that, then whichever language they use has very little relevance to whether or not their system ends up being fast. EDIT: As an example, my first ever production Ruby app was a messaging middleware server that processed about 3 million messages a day (34/sec) on 10% of a single mid-range 2005-era Xeon core. It was totally unoptimized, and used select() instead of the more modern, faster alternatives. Also, only about 10% of that time was spent in user space. 90% of it was in the kernel, executing system calls, so most meaningful optimization would be in improving the usage of system calls that are exactly the same across languages. At the time, going beyond a single core required multiple instances, as Ruby lacked native threads back then. But processing 500-600/sec across 2-3 processes on a dual core 2005-era Xeon would not have been challenging even then with that quite naive and dated approach. As someone else pointed out, they're doing ~4k/sec on a modern dual-core Xeon. Based on the above I'd expect it to be fairly easy to match their ~4K/sec with Ruby today.

by fasteo 11y ago

>> But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffic system I don't get this reasoning.

fixxer 11y ago

They're going from Ruby, so Go is a pretty easy transition with respect to skill set and helped them accomplish scale (as seen from the analysis). I agree that other languages could accomplish the same effect, but I'm not surprised by their sentiment given where they were coming from.

Ao7bei3s 11y ago

Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. It makes perfect sense to me. What would you have recommended them, for a reasonably-high-performance server implementation? (Please don't say C.) https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=yarv&data=u64q https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...

plydatbk 11y ago
Lua would beat go every day of the week.
- jbeja 11y ago
  As Clojure would beat Lua every second of a day.
  - plydatbk 11y ago
    show me the clojure firewall and I'll take you seriously. Or the even something simple as an interesting clojure ML project. Java gross.
  - bitcrusher 11y ago
    If you're talking about raw performance, I'm afraid you're mistaken. If you're perhaps referring to the 'aesthetics' of the language syntax, that's pretty subjective, in which case you're right for your tastes.
  - saosebastiao 11y ago
    I'm a big clojure fan and not the biggest Lua fan, but I'm afraid you are mistaken. You won't find any dynamically typed language implementation that can come close to LuaJIT for the general use case.
    - raspasov 11y ago
      What if you type hint everything in Clojure properly so all reflection is avoided? (does take some time, but with something like YourKit it'll be only a few hours max on a mid-size project)
- cdelsolar 11y ago
  [citation needed]
fasteo 11y ago
>>> It makes perfect sense to me Yes. Other than some very basic scripts, I have never worked with Ruby, so I was not aware that it is so slow. Thanks for pointing that out. As for my recommendation, it is pretty standard worker architecture: Their system seems to be an ingesting-only system, that is, the clients are getting an empty HTTP 200 OK response. Given this, I would put openresty (nginx) in the front, with some trivial Lua code[1] to en-queue payloads to beanstalkd. Then, you can either have your workers inside openresty (using Openresty timers) or have them as separate processes and written in the language of choice. We have been using this for a couple of years now and it is working really well for our use case, also an ingesting-only system. [1] https://github.com/smallfish/lua-resty-beanstalkd/blob/master/t/02-put.t https://github.com/smallfish/lua-resty-beanstalkd/blob/maste...
- sinzone 11y ago
  we use the same technology with KONG [1] [1] https://github.com/mashape/kong https://github.com/mashape/kong
saosebastiao 11y ago
Scala, Java, Clojure, C#, F#, Node, LuaJIT, Erlang, Elixir, Haskell, D, Nim... There are lots of reasonably fast options out there that aren't C.
pjmlp 11y ago
> Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. Than MRI Ruby you mean. The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.
- dragonwriter 11y ago
  > > Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. > Than MRI Ruby you mean. Given the nature of orders-of-magnitude comparisons and the lack of Ruby implementations that are even one order of magnitude faster than MRI, "...than Ruby" is reasonably accurate if "...than MRI Ruby" is at all accurate. > The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation. Maybe, though that's unproven. AFAIK, actual Ruby implementations with AOT only seem to gain about a factor of 2 improvement, not an order of magnitude.
- pselbert 11y ago
  That's exactly the space that Crystal [0] seems to be exploring. Statically type checked and pre-compiled via LLVM. So it isn't the Ruby designers themselves, but definitely Ruby flavored. 0: http://crystal-lang.org/ http://crystal-lang.org/
andrewvc 11y ago
There's nothing concurrent in this case, parallel sure, but concurrency wise this is all shared nothing. And languages are not faster than one another. They are faster at certain tasks but the variability for a given task is really case specific. For io heavy workloads like this underlying libraries and implementations dominate execution time. You could have written this in any number of languages. I don't know why go is more logical than say Java JavaScript.
vidarh 11y ago
> Go is 1-2 orders of magnitude faster than Ruby That may be true for some types of code, but for an app that's predominantly shuffling data over the network you should be spending most of the time in kernel space executing syscalls, and then language differences are largely irrelevant. > and much easier to write concurrent code in. How? Writing concurrent code in Ruby is trivial since 1.9.x (prior to 1.9 you had to battle the green threads in MRI for some stuff), which isn't exactly new.
arthurcolle 11y ago
I was always a big fan of Erlang's concurrency model but I've really been getting into Elixir lately. It is just such a productive language to write and lends itself to extremely maintainable codebases.

tptacek 11y ago

It's less about Go being incredibly fast than about Ruby being anomalously slow. It makes sense if you start from the presumption that Go is the only "fast" language they're considering.

fixxer 11y ago
But that would prevent the knee-jerk tribal language war response.
vidarh 11y ago
Frankly, if you're going to be processing requests and shuffling them to S3, Ruby is nowhere near being the limiting factor unless you do something pathologically bad. Having spent time recently optimizing a setup that does pretty much exactly what they're doing (in Rails; I don't like Rails, but in this case Rails is not a problem), the time saved doing things like eliminating unnecessary buffering all over the place (e.g. POSTs gets buffered by pretty much everything that likes to consider itself a web server, sometimes multiple times; if you e.g. run Nginx in front of pretty much any Ruby web servers running Rails, worst case you may end up with things passed through at least 3, possibly 4 buffers). Basically they should be IO bound.

vidarh 11y ago

They're unfamiliar with network programming, and so picked a language that seems fast to them, is my assessment. Based on their description, they should be IO bound. If they're IO bound, their system should spend the vast majority of time in the kernel executing system calls. If they do that, then whichever language they use has very little relevance to whether or not their system ends up being fast. EDIT: As an example, my first ever production Ruby app was a messaging middleware server that processed about 3 million messages a day (34/sec) on 10% of a single mid-range 2005-era Xeon core. It was totally unoptimized, and used select() instead of the more modern, faster alternatives. Also, only about 10% of that time was spent in user space. 90% of it was in the kernel, executing system calls, so most meaningful optimization would be in improving the usage of system calls that are exactly the same across languages. At the time, going beyond a single core required multiple instances, as Ruby lacked native threads back then. But processing 500-600/sec across 2-3 processes on a dual core 2005-era Xeon would not have been challenging even then with that quite naive and dated approach. As someone else pointed out, they're doing ~4k/sec on a modern dual-core Xeon. Based on the above I'd expect it to be fairly easy to match their ~4K/sec with Ruby today.