I was surprised that they felt Node's performance was slower for computation, given the effort V8 has put into optimization. Particularly he called out "interpreted" and "dynamic-typed". But V8 compiles and optimizes frequently used functions, and recompiles running functions when it detects that they are being called with the same runtime types repeatedly. This runtime optimization can't be quite as fast overall as Go, but I'd be surprised if well-designed JS couldn't run 60-80% as fast. Maybe that's enough difference for them to make the switch.
I work at Uber. We've discovered that in terms of average response time, our node services have remarkable performance. For example, some of our fastest node services have 1-5ms p95 response time. When you start diving into the p99 latency, garbage collection pauses can spike response time to tens or hundreds of ms, and eliminating these spikes is incredibly nontrivial.
Usually, financial companies will use one of the commercial realtime jvms - it's not just some tuning. Javascript being singlethreaded would certainly simplify having a pauseless GC but it's still a nontrivial problem and I'm not sure how much that would benefit the browser use case.
I think the bigger issue here is that Node is blocking while a computationally intensive algorithm is running whereas Go can have multiple goroutines still serving requests while running the algorithm.
You just take the computationally expensive work and run it elsewhere, like a worker pool. This is a standard pattern for this kind of work and what you would do with go too, except the worker pool might just be a number of goroutines.
It's chickens*t to down vote my comment, when you could argue a fact, or explain something to me that I don't understand.
My question isn't silly. I just now wrote two short programs, one in Go and one Javascript, to run a vector multiply and add on two length 1000 vectors, a million times. The JS program is faster.
Result (in seconds):
$ node vmadd.js
0.984
$ go run vmadd.go
1.141044662
Go run first compiles the code and builds an executable. You are mostly benchmarking for both systems the compilation time. Building an executable in Go takes most of a second. A significant benchmark would check the run times.
No, if you examine the code, you'll see the timer times only the accumulated execution time for the loop. The code has been compiled. See below to eliminate doubt -- I used go build and got similar numbers.
