Uber Go Style Guide • Hacker News Board

Re: Uber Go Style Guide

#121

Post by apta » Sat, Oct 12, 2019, 2:45 PM UTC

klabb3 wrote: post #90

heroHACK17 wrote: post #64

I really like the horizontal 'Good/Bad' code comparisons in this guide. I didn't realize how horizontal vs. vertical code comparison affects readability; IMO horizontal is MUCH more readable. Example: https://github.com/uber-go/guide/blob/master/style.md#defer-...

+1. It is quite an achievement by Go as a language and/or community to have generally short lines of code where two columns fit in a regular website width. I don't like everything about Go, but it's usually pretty easy on the eyes for this reason.

I don't think that the prevalence of single letter variable names can be considered an achievement (which is how they get short lines to begin with). It's quite a hindrance to readability. golang as a language does nothing to support shorter lines.

Re: Uber Go Style Guide

#122

Post by nicklauri » Sat, Oct 12, 2019, 2:54 PM UTC

pmezard wrote: post #21

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…

Cannot wait for "Uber Rust Style Guide".

I would love to see that too, but I think that's likely never happened. Because Rust is kinda hard and takes quite amount of time and money to train new people, add more stacks on maintaining projects, and important thing is that I don't see why they have to use Rust. Go is good enough and they can work around with Go's disavantages.

Re: Uber Go Style Guide

#123

Post by steveklabnik » Sat, Oct 12, 2019, 2:58 PM UTC

weberc2 wrote: post #119

dpc_pw wrote: post #107

Earlier quoted context omitted.

I'm sorry, but that is a naive misconception. "everything is owned by the GC" is a sign of not understanding concept of ownership, BTW. GC is not an actor in the system, so does not participate in the ownership. A Java finalizers might kind of do stuff, but that's when all references are gone, so they have exclusive ownership. Anyway... Languages with GC still do have ownership. It is just defaulting to be the most p…

Ok, then educate me—what is ownership if not the responsibility for managing (cleaning up) a resource? In my C and C++ days, I never heard of it refer to some kind of exclusive permission to mutate a resource (which seems to be your meaning), but rather as the responsibility to free the resource (as in “the owner must and only the owner _can_ free the owner resource”). It seems likely that you and I are using differe…

In Rust, we also say that it’s the right to destroy.

Re: Uber Go Style Guide

#124

Post by mytailorisrich » Sat, Oct 12, 2019, 3:35 PM UTC

xmprt wrote: post #102

ninkendo wrote: post #51

Earlier quoted context omitted.

Work on their internal chat app, I guess? https://eng.uber.com/uchat/

That's built on top of Mattermost which is open source. They do build their own infra instead of using cloud though so that probably uses a big part of it.

However you look at it, Uber and other new so-called tech companies these days spend like there is no tomorrow instead of focusing on the bottom line.

Re: Uber Go Style Guide

#125

Post by nine_k » Sat, Oct 12, 2019, 4:25 PM UTC

bcrosby95 wrote: post #59

sanxiyn wrote: post #8

Earlier quoted context omitted.

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!

I would describe Rust more like a read-write lock than not sharing.

A lock is acquired and detected at runtime.

Ownership and move semantics are checked at compile time, and allow effective "not sharing" without waiting or defensive copies.

Re: Uber Go Style Guide

#126

Post by weberc2 » Sat, Oct 12, 2019, 5:14 PM UTC

steveklabnik wrote: post #123

weberc2 wrote: post #119

Earlier quoted context omitted.

Ok, then educate me—what is ownership if not the responsibility for managing (cleaning up) a resource? In my C and C++ days, I never heard of it refer to some kind of exclusive permission to mutate a resource (which seems to be your meaning), but rather as the responsibility to free the resource (as in “the owner must and only the owner _can_ free the owner resource”). It seems likely that you and I are using differe…

In Rust, we also say that it’s the right to destroy.

Thanks for responding, Steve. I understand that “ownership” implies the right to destroy in any language. The bit I’m not so clear about is whether or not there are other rights/responsibilities (such as the right to mutate) as the OP suggests and whether a definition that includes those rights/responsibilities can meaningfully apply to any language or just Rust.

Re: Uber Go Style Guide

#127

Post by Groxx » Sat, Oct 12, 2019, 6:19 PM UTC

jonahx wrote: post #120

Groxx wrote: post #111

I'll throw in one request for functional options as written here : please don't use closures to capture the data. If you use closures, it's nearly impossible to compare the results for equality in tests or code that might care to validate / deduplicate / whatever those args. You can achieve it with a moderate amount of heavily-implementation-dependent reflection (get the func type, construct arg(s), call func, check…

are you saying you’re against the functional options approach? can you provide an example of a testing difficulty you’ve had?

I mean that this:

    func MyOption(arg int) Option {
      return myoption(func(opts type) { opts.thing = arg })
    }

will result in this:

    MyOption(5) == MyOption(5) // false

Which makes it a pain in 1) testing, since you can't see the options that were passed, and 2) middleware, since you can't see the options that were passed, to validate or extend them safely. And 3) debuggers or Printf since you can't see the value in the closure until it's executed.

Instead do:

    type myOption int
    func MyOption(arg int) Option {
      return myOption(arg)
    }

since it has none of those problems.

Whether you use the "loop and opt.apply(arg)" pattern or not doesn't really matter - that's a purely internal detail (personally I find it over-simplifies things and causes problems). Just "avoid passing values through func closures".

Re: Uber Go Style Guide

#128

Post by jlokier » Sat, Oct 12, 2019, 6:21 PM UTC

PudgePacket wrote: post #113

jlokier wrote: post #103

This recommendation surprised me: if err := ioutil.WriteFile(name, data, 0644); err != nil { return err } I've often seen guides for many languages that say don't use an assignment as an "if" condition. It may be a typo, and so is a source of errors, or it hides errors. Many compilers warn about it, and some people will consider it poor enough to refactor it out. Of course it's not the assignment which is being teste…

It helps reduce uninitialised variables, and if the condition is false, you don't have an extra variable hanging around in the scope that could potentially be misused by the developer later.

You seem to have missed the point of the comment you're replying to, which already acknowledges that scope-limiting is a good thing to do.

Re: Uber Go Style Guide

#129

Post by closeparen » Sat, Oct 12, 2019, 6:35 PM UTC

jrockway wrote: post #65

Something that I don't see style guides addressing, but think they should, is how to cancel work when the caller no longer cares about the answer. (Consider an aborted RPC, or someone pressing the "stop" button in their browser.) A lot of people will do things like: func (s *Server) HandleFoo(ctx context.Context, in *input) status { ch This will block on the channel write even if the context becomes cancelled. Instea…

Ideally application code doesn’t have to manage this, it’s done in the RPC library before accepting work and while awaiting responses.

Re: Uber Go Style Guide

#130

Post by twic » Sat, Oct 12, 2019, 6:54 PM UTC

weberc2 wrote: post #119

dpc_pw wrote: post #107

Earlier quoted context omitted.

I'm sorry, but that is a naive misconception. "everything is owned by the GC" is a sign of not understanding concept of ownership, BTW. GC is not an actor in the system, so does not participate in the ownership. A Java finalizers might kind of do stuff, but that's when all references are gone, so they have exclusive ownership. Anyway... Languages with GC still do have ownership. It is just defaulting to be the most p…

Ok, then educate me—what is ownership if not the responsibility for managing (cleaning up) a resource? In my C and C++ days, I never heard of it refer to some kind of exclusive permission to mutate a resource (which seems to be your meaning), but rather as the responsibility to free the resource (as in “the owner must and only the owner _can_ free the owner resource”). It seems likely that you and I are using differe…

Ownership is (at least) two things: who has the responsibility for destroying an object when it's finished with, which GC takes care of, and who has the right to mutate an object while it's alive, which GC doesn't.

I mostly write Java for a living, have done for a decade, and still occasionally trip myself up by mutating an object I'd forgotten I've shared.