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

Uber Go Style Guide

github.com

Post reply on HN
Print view View original

41–50 of 140 posts

Re: Uber Go Style Guide

#41

Post by mytailorisrich »

kerng wrote: post #36
ra7 wrote: post #2

Is Go the primary language in Uber now? I see a lot of tools written in Go coming out of Uber. What kind of services inside Uber is Go used for?

Probabaly more of an emotional, rather then rational decision. I heard that many Go folks from Google joined Uber. Looking at the stock, they probably should focus on building new things/better the business model, rather then rewriting things in Go.

What else have they got to do, though?

Uber have thousands of engineers to develop and maintain a taxi hailing app...

Re: Uber Go Style Guide

#42

Post by weberc2 »

kerng wrote: post #36
ra7 wrote: post #2

Is Go the primary language in Uber now? I see a lot of tools written in Go coming out of Uber. What kind of services inside Uber is Go used for?

Probabaly more of an emotional, rather then rational decision. I heard that many Go folks from Google joined Uber. Looking at the stock, they probably should focus on building new things/better the business model, rather then rewriting things in Go.

I'll bite. Why do you suppose it's an emotional decision? And why do you assume they're rewriting things and not writing new code in support of their business model?

Re: Uber Go Style Guide

#44

Post by K0SM0S »

OJFord wrote: post #22
badrequest wrote: post #17

Earlier quoted context omitted.

Uber have well over 1,500 microservices written in Go, it is the primary language backend services are written in at Uber.

> Uber have well over 1,500 microservices written in Go 1500 ?! I can't even imagine how micro a microservice could be such that Uber could have so many. edit: Having said that, the Monzo blog post also on the front page says it has 1100 microservices, so I suppose I've just not worked somewhere with 'actual' microservices. What constitutes a 'service', a single procedure for RPC?

I haven't worked with microservices directly but what I gather is:

- build a UNIX philosophy, "efficient atomicity" so 1 microservice = 1 command

- you then build logic with these like Lego bricks, that's your glue code => backend ties that together

On a typical base Linux install you have something between 250 and 1500 packages. Average Java repo has like, what, 80 files maybe? 120? Break it down to functions / structs and you can see the 1500 being a reasonable estimate of a modular architecture.

So you have one microservice to return a catalog, another to take a search input, another to serialize this stuff, another to autofill something, another to autofill some other thing, etc. Your app architecture schema is produced by/in microservices.

That's the extreme approach to microservice architecture (the 1 command / 1 object / 1 function / 1 struct atomicity Lego-style), and in such a case most microservices would typically look very much alike, with exactly the same "general" parts (auth, db connect, etc) and just your business logic varying in between.

With so small microservices, a team of 4 may be responsible for a good dozen microservices, a team of 10 may handle a hundred... You quickly rise to high hundreds in such scenarios.

Disclaimer: This is extensively parroted from the latest episode of "Go Time", a fantastic podcast imho.

Re: Uber Go Style Guide

#45

Post by mav3rick »

thinkingkong wrote: post #43

How would you enforce any of these? Are these guides or reasons to not accept PRs? Seems like it would be worth encoding in a tool if this is for teams.

Mostly by people following these and you bootstrap by some trusted people getting +2 rights. As more people are trusted they get the rights.

Re: Uber Go Style Guide

#46

Post by kerng »

weberc2 wrote: post #42
kerng wrote: post #36

Earlier quoted context omitted.

Probabaly more of an emotional, rather then rational decision. I heard that many Go folks from Google joined Uber. Looking at the stock, they probably should focus on building new things/better the business model, rather then rewriting things in Go.

I'll bite. Why do you suppose it's an emotional decision? And why do you assume they're rewriting things and not writing new code in support of their business model?

Because they have publicly talked about it:

https://eng.uber.com/schemaless-rewrite/

Re: Uber Go Style Guide

#47

Post by badrequest »

sidlls wrote: post #32

The section on exporting functions to check errors just exposes Go's weakness in error checking. It's unnecessarily verbose.

The way to do this properly got much better in the most recent Go release, the linked documentation doesn't yet take that into account, it would seem.

https://github.com/golang/go/wiki/ErrorValueFAQ

Re: Uber Go Style Guide

#48

Post by morelisp »

skybrian wrote: post #26
sanxiyn wrote: post #4

"Copy Slices and Maps at Boundaries. Slices and maps contain pointers to the underlying data so be wary of scenarios when they need to be copied. Keep in mind that users can modify a map or slice you received as an argument if you store a reference to it. Similarly, be wary of user modifications to maps or slices exposing internal state." This could be used as an ad for Rust borrow checker, verbatim. You can't modify…

Yes, that's not good, but it seems like in practice this doesn't come up too often in Go? More typically you're building a new slice containing the results of a query or other computation, and returning it without keeping a reference. Or instead of exposing an internal map, you have a Get method.

I have found this to be true of everything other than byte slices, where the result is some of the worst bugs I've had the displeasure of tracking down.

Many Go libraries like to offer passing a byte slice to reuse as a destination. Many Go libraries take byte slices or structs containing them as arguments. A common result is "loop over some input, read it into the reusable slice, pass the slice to the next step". It even sort of works - until the next step does something asynchronous.

It doesn't help that:

- Lots of things return a new slice "sometimes" - _this_ append() result is safe to pass on; this other one is not; this other one "it depends".

- The `x[:]` idiom to turn an array into a slice looks exactly like a Python copy, but actually shares the same backing store.

In the end we basically banned reusing slices as a result. (The rule I tell new programmers is "if you pass the slice elsewhere in a loop, the slice needs to be allocated within the loop.") Which is a shame, because the performance gain from safe reuse is often significant. But until the type system blocks us from changes, usually in the oblivious callee, which turn a safe use into an unsafe one, it's simply too much effort to remember and review each case.

Re: Uber Go Style Guide

#49

Post by weberc2 »

K0SM0S wrote: post #44
OJFord wrote: post #22

Earlier quoted context omitted.

> Uber have well over 1,500 microservices written in Go 1500 ?! I can't even imagine how micro a microservice could be such that Uber could have so many. edit: Having said that, the Monzo blog post also on the front page says it has 1100 microservices, so I suppose I've just not worked somewhere with 'actual' microservices. What constitutes a 'service', a single procedure for RPC?

I haven't worked with microservices directly but what I gather is: - build a UNIX philosophy, "efficient atomicity" so 1 microservice = 1 command - you then build logic with these like Lego bricks, that's your glue code => backend ties that together On a typical base Linux install you have something between 250 and 1500 packages. Average Java repo has like, what, 80 files maybe? 120? Break it down to functions / stru…

This seems really excessive. You'd have to have really good tooling to build, deploy, and debug (since log streams are oriented per-function, not per-request), and I'm not sure how that could be performant, especially if you're making O(N) (or worse) network calls per request. My understanding is that microservices are typically 1-5 per team.

Re: Uber Go Style Guide

#50

Post by weberc2 »

kerng wrote: post #46
weberc2 wrote: post #42

Earlier quoted context omitted.

I'll bite. Why do you suppose it's an emotional decision? And why do you assume they're rewriting things and not writing new code in support of their business model?

Because they have publicly talked about it: https://eng.uber.com/schemaless-rewrite/

From your own link:

> As our business grew, so did our resource utilization and latencies; to keep Schemaless performant, we needed a solution that would execute well at scale.

That's the third sentence. Clearly it was not an "emotional decision" and it was in support of their business model (scale).

Post reply on HN