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

11–20 of 140 posts

Re: Uber Go Style Guide

#11

Post by reificator »

sanxiyn wrote: post #8
apta wrote: post #6

Earlier quoted context omitted.

Another solution is to use immutable and/or persistent data structures. Of course, because golang doesn't have generics, it becomes unwieldy to have a library of them, unlike what we see in Java, Scala, etc. where these enjoy a wider adoption.

Shared mutable state is evil, so "not mutable" has been proposed as a solution. Rust is different, because Rust's solution is "not sharing". You can still mutate!

> Rust is different, because Rust's solution is "not sharing". You can still mutate!

For the record, rust does also default to immutability, and you can share immutable references all you'd like.

Re: Uber Go Style Guide

#12

Post by meddlepal »

knorker wrote: post #10

Pretty good. Some opinions that fall under "be consistent within our code base" (which is why Uber should have a style guide at all), so all good. Just one comment though: > Embedding sync.Mutex Never do this on an exported type. If you embed sync.Mutex that makes "Lock" and "Unlock" part of your exported interface. Now the caller of your API doesn't know if they are supposed to call Lock/Unlock, or if this is a pure…

> Never do this on an exported type. If you embed sync.Mutex that makes "Lock" and "Unlock" part of your exported interface. Now the caller of your API doesn't know if they are supposed to call Lock/Unlock, or if this is a pure internal implementation detail.

Isn't that exactly what they say?

> Embed for private types or types that need to implement the Mutex interface.

Personally, I would never embed a sync.Mutex though because even for an internal type it is confusing.

Re: Uber Go Style Guide

#13

Post by ArtWomb »

knorker wrote: post #10

Pretty good. Some opinions that fall under "be consistent within our code base" (which is why Uber should have a style guide at all), so all good. Just one comment though: > Embedding sync.Mutex Never do this on an exported type. If you embed sync.Mutex that makes "Lock" and "Unlock" part of your exported interface. Now the caller of your API doesn't know if they are supposed to call Lock/Unlock, or if this is a pure…

Agree, but I can't recall ever seeing a package in the wild that labels itself as "concurrency-safe" and yet requires the caller to explicitly call Lock!

HashMap is probably a good example

https://github.com/cornelk/hashmap

Re: Uber Go Style Guide

#14

Post by logicallee »

Not an expert, but could someone explain why it says: "Panic/recover is not an error handling strategy. A program must panic only when something irrecoverable happens such as a nil dereference." Why is that any more irrecoverable than anything else? (You can check if it's nil before referencing it, right?)

Re: Uber Go Style Guide

#15

Post by ArtWomb »

No buffered channels, or if you do, you must provide a very strong rationale ;)

I still use them quite a bit. Particularly synchronizing large rule sets as bit arrays. Of course you can use sync.Wait instead. But make(chan bool, N) semantics are just more convenient. It's stealth synchronization as a by-product. And hence the warnings about determinism!

Re: Uber Go Style Guide

#16

Post by xyzzy_plugh »

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?

For backends they've standardized on Go and Java, deprecating/eliminating node and python where possible. I understand node is still prevalent for serving react-based frontends, both external and internal facing.

Re: Uber Go Style Guide

#17

Post by badrequest »

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?

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

Re: Uber Go Style Guide

#19

Post by dev_dull »

ArtWomb wrote: post #15

No buffered channels, or if you do, you must provide a very strong rationale ;) I still use them quite a bit. Particularly synchronizing large rule sets as bit arrays. Of course you can use sync.Wait instead. But make(chan bool, N) semantics are just more convenient. It's stealth synchronization as a by-product. And hence the warnings about determinism!

I'd like to hear more about this rational. With a single writer, buffering channels can help smooth out inputs when the p90 is much higher than the average with channel writers but not readers. At least that's my impression.

Re: Uber Go Style Guide

#20

Post by dev_dull »

xyzzy_plugh wrote: post #16
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?

For backends they've standardized on Go and Java, deprecating/eliminating node and python where possible. I understand node is still prevalent for serving react-based frontends, both external and internal facing.

How do they decide with a new backend service to use Go vs Java?
Post reply on HN