Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we built Uber Engineering's highest query-per-second service using Go (2016)

eng.uber.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#51

Post by erik_seaberg »

dashwav wrote: post #30
matt2000 wrote: post #23

Earlier quoted context omitted.

My sense is that most people moving to Go are coming from Node and that explains their excitement about the performance. Not many upsides when you’re already on Java.

I mean there is a definite performance gain from Java to Go, although I would agree most people probably wouldn't hit it - but if its just as easy to write, might as well use the better language. On top of that Go makes concurrency so much easier to factor in and program with, which in the backend server space is a very important asset over Java. As an interesting addendum, I found this to be a really interesting res…

Go has a little syntactic sugar for the same green threads other languages have, but it's missing a lot of immutable and thread-safe data structures.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#52

Post by soedirgo »

asdfman123 wrote: post #28
sidlls wrote: post #27

Earlier quoted context omitted.

They also would have to sift through some really terrible programmers who have fully bought into the worst practices of enterprise-y OO development.

Is that really true? Honest question. Or is that just bias against things that are not new and fancy?

This might be related.

From pg: "...you could get smarter programmers to work on a Python project than you could to work on a Java project." [1]

[1] http://www.paulgraham.com/pypar.html

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#53

Post by surfmike »

MuffinFlavored wrote: post #50
asdfman123 wrote: post #24

Earlier quoted context omitted.

Yeah, boring programming languages are criminally underrated. Fro instance: > High developer productivity. Go typically takes just a few days for a C++, Java or Node.js developer to learn, and the code is easy to maintain. (Thanks to static typing, no more guessing and unpleasant surprises). This is why the rest of the world doesn't use JS for everything. > There is a lot of momentum behind Go at Uber, so if you’re p…

> This is why the rest of the world doesn't use JS for everything. What?

I think they’re referring to static typing.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#54

Post by not_a_cop75 »

woeirua wrote: post #36

This is a very inefficient implementation. Really, just poor quality work overall, as anyone with even a basic understanding of spatial indexing would know that an R-tree would be many times faster, as illustrated here: https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...

So am I to understand this shows a little bit about why Uber is not the center of excellence it needs to be?

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#55

Post by 0xEFF »

rayvy wrote: post #44

I think this write up is very fair for a solid engineering team. Is it groundbreaking and eye opening? Absolutely not, I’d say the most “hmm I didn’t know that” part of the entire thing was the part about R-Trees and S2. Is that bad? Absolutely not. These guys did the work, logged their performance and are sharing their story. However, and I believe this is where the animosity in the comments is coming from - given t…

> I guess Leetcoding and Production Engineering really are different things.

This is key point.

They delivered value to the business. That's the only thing that matters.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#56

Post by PunchTornado »

To all the people "why not do it in Java / Java could have done it".

Why not do it in a different language? Having Go and Node around is awesome because we can change the language. Don't you get bored to use just a single language? I'd get so so so bored if I didn't change languages every year. Glad that uber offers Go jobs.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#57

Post by erik_seaberg »

MrBuddyCasino wrote: post #38
dashwav wrote: post #30

Earlier quoted context omitted.

I mean there is a definite performance gain from Java to Go, although I would agree most people probably wouldn't hit it - but if its just as easy to write, might as well use the better language. On top of that Go makes concurrency so much easier to factor in and program with, which in the backend server space is a very important asset over Java. As an interesting addendum, I found this to be a really interesting res…

> I mean there is a definite performance gain from Java to Go I don't think thats true.

The GC isn't very good yet, but brute-force sequential code can keep more state on the stack where it doesn't matter. (Just please codegen that instead of expecting everyone to read it.)

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#58

Post by ionforce »

0xEFF wrote: post #55
rayvy wrote: post #44

I think this write up is very fair for a solid engineering team. Is it groundbreaking and eye opening? Absolutely not, I’d say the most “hmm I didn’t know that” part of the entire thing was the part about R-Trees and S2. Is that bad? Absolutely not. These guys did the work, logged their performance and are sharing their story. However, and I believe this is where the animosity in the comments is coming from - given t…

> I guess Leetcoding and Production Engineering really are different things. This is key point. They delivered value to the business. That's the only thing that matters.

> They delivered value to the business. That's the only thing that matters.

But this bit isn't true during the interview process.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#59

Post by jryan49 »

PunchTornado wrote: post #56

To all the people "why not do it in Java / Java could have done it". Why not do it in a different language? Having Go and Node around is awesome because we can change the language. Don't you get bored to use just a single language? I'd get so so so bored if I didn't change languages every year. Glad that uber offers Go jobs.

Usually when you're trying to ship something, the more boring (predictable) parts the better.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#60

Post by thejigisup »

woeirua wrote: post #36

This is a very inefficient implementation. Really, just poor quality work overall, as anyone with even a basic understanding of spatial indexing would know that an R-tree would be many times faster, as illustrated here: https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...

clearly the most efficient solution is to pontificate about other people's implementations while never having done anything of the sort at that scale yourself.
Post reply on HN