> While historically Uber has been mostly a Node.js and Python shop, the Go language is becoming the language of choice for building many of Uber Engineering’s new services.
It feels like this type of narrative is becoming more common.
Its more of a application life-cycle thing rather than Node.js/Python being bad.
One creates the first version in Node.js/Python as its quick to build and iterate an app. At this stage you are still hammering out exactly how things need to be done and accessing the actual needs of your users. Speed of iteration is the most important attribute for any choice made during this stage as generally you don't have enough scale for choices to matter much and it prevents wasted effort on things that end up on the cutting room floor.
Once you have built the app, and it gets stable major feature wise, you then have plenty of data to drive decisions about what the pieces actually need to be and the tool best suited for them. Go happens to be well suited for swapping out various generic back end pieces with something custom to the problem at hand.
Another way to think about it is the Node.js/Python version is the next step up from diagramming the app out on paper. Its more like the previsulazation stage of a movie (roughly animated, with intern voiceovers). This is important as it can save you a bunch of time on things that are unneeded and can help identify problem areas you should focus on first.
"One creates the first version in Node.js/Python as its quick to build and iterate an app."
That's the narrative, but I don't find Python (I have minimal experience with Node) faster to write in any way but library availability, and very painful to refactor without the ability to reach for a type checker.
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.
Go is lighter than the other two. It can run on lesser hardware (or resources) and is pretty much reliable. The code is easy to write and simple. I don't get to "enjoy" too many smart hacks from others in Go. Its a nice language for what it was meant to do: systems programming. Although Elixir is really shaping up to be a solid competitor. Elixir's syntax and idioms are easier to read, IMO.
It is indeed fast. I'm just waiting for it to mature a little bit more to use it in production. My goal is to start working on production system after summer 2016. By the, more information about gotchas and issues should have arose.
It feels like this type of narrative is becoming more common.