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

91–100 of 140 posts

Re: Uber Go Style Guide

#91

Post by fishywang »

palebluedot wrote: post #88

The preference of channel size being unbuffered or just 1 is interesting. That seems like something specific to a problem domain; for instance, in projects I am working on now, having a large buffered channel (1000s deep) is useful for worker queues of thousands of goroutines, that all read from a task feeder channel. This type of queuing seems go-idiomatic, and negates the need for additional synchronization. In thi…

Why having a 1000s buffered channel is useful in this case? If it's unbuffered, you still get the backpressure blocking on writers as a feature, since you have a worker queues of thousands of goroutines to read and handle them.

Re: Uber Go Style Guide

#92

Post by dallbee »

palebluedot wrote: post #88

The preference of channel size being unbuffered or just 1 is interesting. That seems like something specific to a problem domain; for instance, in projects I am working on now, having a large buffered channel (1000s deep) is useful for worker queues of thousands of goroutines, that all read from a task feeder channel. This type of queuing seems go-idiomatic, and negates the need for additional synchronization. In thi…

A lot of my coworkers were getting hung up on this point too. I think they're just emphasizing that large channel buffers can hide concurrency problems, so you want to be careful when using them.

The last sentence in the recommendation emphasizes this: use them with scrutiny.

Re: Uber Go Style Guide

#93

Post by weberc2 »

dpc_pw wrote: post #56
twic wrote: post #55

Earlier quoted context omitted.

No, the point of this observation is that Go exposes this complexity, it just doesn't make it explicit.

Exactly. Ownership/lifetimes exist in almost every mainstream PL (anywhere where you can have any sort of references + mutability). It's just people pretend it doesn't, and hope everything is going to be fine. And when you bring it in front of their consciousness they scream in panic, like it didn't exist before. Once you internalize Rust ownership rules, they are almost effortless and you see and obey them in any co…

Most languages have a GC so there really is no ownership to pretend away (if you like, everything is owned by the GC). Rust can be super cool without inventing fake problems for other languages.

Re: Uber Go Style Guide

#94

Post by fishywang »

jrockway wrote: post #73
thezviad wrote: post #71

Earlier quoted context omitted.

the way to do is to pass context all the way through, until the other thing you are waiting on uses up no resources. so in your example it should be done like this: ch and the 'workFor' function should be the one that gets canceled with the context. Deep down at the very end, you would have select statement with ' Of course the world isn't perfect and not everything takes context right now (even in standard library),…

This is a very trivial example so doesn't dive into all the complexity. There is a lot of nuance here, like whether or not you really want to do an operation in the background in the first place. Background work does means that you lose the ability to apply backpressure to the calling system, and that will cause a lot of problems under load. Even if you do want to do the operation in the background, you still want to…

It does not need to be the background. You can check context cancellation without any goroutines by:

    select {
    default:
    case
When there's no other channels to select with the context, just use that code block between lengthy operations to check context cancellation and return early.

(If you are curious about how many extra time is wasted, it's easy to write a benchmark test for that. Last time I checked it was ~20ns when you are going the default/not-cancelled route)

Re: Uber Go Style Guide

#96

Post by tomohawk »

nergal wrote: post #61

Underscore in globals. Is that really go best practice?

Yes. Variables that start with lower case look like a locally defined variable in a func. Adding the underbar makes it absolutely clear, and prevents shadowing, or the need to work around shadowing with a slightly different name.

Re: Uber Go Style Guide

#97

Post by gen220 »

sanxiyn wrote: post #87
tapirl wrote: post #83

Copy Slices and Maps at Boundaries: https://github.com/uber-go/guide/blob/master/style.md#copy-s... The suggested good clone is not very efficient: https://github.com/go101/go101/wiki/How-to-efficiently-clone... In fact, I prefer the suggested bad one instead. We should let the caller to determine whether or not a clone is needed. -------------------------- Start Enums at One: https://github.com/uber-go/guide/blob/ma…

Re: Start Enums at One. As explained, it is to avoid making the first enum value the default when making it the default is not appropriate.

At my place of work, we pretty much always make the default (0) value “Unspecified”.

The rationale is, it’s often quite useful to know that the originator hasn’t specified a value, and to help new originators avoid unintended side-effects.

This style guide has the same effect, but it’s implicit; takes a few more mental cycles to parse in exchange for less code. Personally, I think it’s probably worth the trade off to type it out once and save time thinking later.

Re: Uber Go Style Guide

#98

Post by sanxiyn »

weberc2 wrote: post #93
dpc_pw wrote: post #56

Earlier quoted context omitted.

Exactly. Ownership/lifetimes exist in almost every mainstream PL (anywhere where you can have any sort of references + mutability). It's just people pretend it doesn't, and hope everything is going to be fine. And when you bring it in front of their consciousness they scream in panic, like it didn't exist before. Once you internalize Rust ownership rules, they are almost effortless and you see and obey them in any co…

Most languages have a GC so there really is no ownership to pretend away (if you like, everything is owned by the GC). Rust can be super cool without inventing fake problems for other languages.

How is it a fake problem? Uber is copying slices it doesn't need to copy, suffering significant performance penalty, because it is too error prone in Go. Rust completely prevents this error.

Re: Uber Go Style Guide

#99

Post by weberc2 »

sanxiyn wrote: post #98
weberc2 wrote: post #93

Earlier quoted context omitted.

Most languages have a GC so there really is no ownership to pretend away (if you like, everything is owned by the GC). Rust can be super cool without inventing fake problems for other languages.

How is it a fake problem? Uber is copying slices it doesn't need to copy, suffering significant performance penalty, because it is too error prone in Go. Rust completely prevents this error.

Ownership is different than mutability. Yes, immutability would prevent those errors.

Re: Uber Go Style Guide

#100

Post by ummonk »

eternalban wrote: post #86
twic wrote: post #55

Earlier quoted context omitted.

No, the point of this observation is that Go exposes this complexity, it just doesn't make it explicit.

I think this is where Rob Pike got it backwards (in terms of one of his stated goal for Go). Go is a very effective tool in the hands of experienced programmers, without having to pay the cognitive load price of 'Mommy' languages. I am reminded of Bryan Cantrill's rant regarding threads in this context. Writing solid software is hard. It takes skill, experience, and serious battle scars. Tools and languages can help,…

Even the most experienced programmer can’t hold all of a million line codebase in his or her head. And that is the issue with a language like Go - you can be careful about the code you write but it doesn’t have static analysis enforceable constraints on code other people write that interacts with your code / data.
Post reply on HN