Live data from Hacker News

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

eng.uber.com

71–80 of 124 posts

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

#71
post #67

Earlier quoted context omitted.

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.

While he was a bit rude I wouldnt assume he hasn't built something at this sort of scale.

nah i think its a pretty fair assumption

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

#72
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...

It's funny because had you tried to brute force any of their interview questions (spatial or not) it would have been instant rejection. Often feels like algo analysis is an exercise to get a job and not something engineers actually do, even when required.

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

#73
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...

It's funny because had you tried to brute force any of their interview questions (spatial or not) it would have been instant rejection. Often feels like algo analysis is an exercise to get a job and not something engineers actually do, even when required.

The entire line of argument would have been immediately rejected in a phone screening or an on-site interview at any of the major companies, and even many lesser companies that deal with spatial data. Anyone doing spatial queries and not using existing spatial data structures had better have a really good reason for not doing so.

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

#74
post #67

Earlier quoted context omitted.

While he was a bit rude I wouldnt assume he hasn't built something at this sort of scale.

nah i think its a pretty fair assumption

Let's just ignore the fact that in this case scale has nothing to do with the actual efficiency of the algorithm they implemented. As the link I posted mentioned, had they used a more efficient algorithm they could have used far fewer resources, or used the same resources to scale up further, with much faster response times overall.

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

#76
post #63
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...

I'm currently implementing an rtree in elm. Does anyone have good references about rtrees that they like?

I think this is the first paper on R Trees.

http://www-db.deis.unibo.it/courses/SI-LS/papers/Gut84.pdf

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

#77
post #55
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.

[deleted]

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

#78
post #55

Earlier quoted context omitted.

> 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.

That's half of the interview process. The other half is convincing your future-peers you aren't a liability. Provide value, get along well, communicate decently.

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

#79
post #67

Earlier quoted context omitted.

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.

While he was a bit rude I wouldnt assume he hasn't built something at this sort of scale.

The vast majority of programmers haven't built something at this sort of scale, so while it's very possible that he has, odds are that he hasn't.

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

#80
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?

More popular languages get more early developers, so will be naturally predisposed to have objectively bad developers. You'll definitely find more bad Java devs than bad Haskell devs, but you'll also probably find a higher rate of bad devs in Java or PHP than you will Haskell or F# or something.
Post reply on HN