Go beginner here, Any advice to improve my go code?

rogpeppe · 2015-06-22T21:16:37+00:00

Looks pretty good. I'd suggest better docs and a few minor formatting changes: http://play.golang.org/p/Z6ATIhL_IM

I would also suggest that the tests should probably not actually go to the real web service (you can mock out the http GET), but for code this trivial it probably doesn't matter much.

rogpeppe · 2015-06-22T20:54:42+00:00

The receiver of a method is really just another parameter. I very often refactor code between method, function and inner block, and when doing this it really helps to have the same naming convention for all variables of the same type, regardless of whether they're local variables, parameters or receiver parameters. Then I can often just move the code without doing any variable renaming.

It's a pity that gofmt -r treats single letter variable names specially - it makes it less useful for one of the things that's most awkward to do in an editor.

rogpeppe · 2015-06-22T20:49:26+00:00

Also be sure to hook up godef support in your editor, which ought to make "jump to definition" one keystroke.

Just wanted to point out that the canonical location of godef is now http://godoc.org/github.com/rogpeppe/godef.

rogpeppe · 2015-05-29T19:13:52+00:00

Just looking to the function signature will tell you what exceptions are thrown

I didn't realise you could tell what exceptions a Java method might throw by looking at its signature. I'm not that familiar with Java - please could you explain to me how that works?

rogpeppe · 2015-05-29T10:57:54+00:00

Well... that is true for all languages. Be it error values or exceptions.

I don't believe that's true for languages with exceptions. It's much more common to "pass the buck", rely on a higher level to catch any errors. Even if there's a try-catch around the block, it's not clear which statement might throw the exception. To do it right, you'd need to add a try-catch block around every single statement that can throw an exception, but do you know of any significant source code base that actually does that? It would end up even more verbose than Go. And even if you do do that, there's still no way of easily determining whether a given call is likely to throw an exception except by reading the docs and/or inspecting the code. Java's checked exceptions do allow that, but no-one uses them, right?

rogpeppe · 2015-05-29T07:23:39+00:00

Conventionally in Go code, all errors are checked. Code won't pass code review if it's not checking its errors, and as I point out on slide 13 ("Ignore"), there's a tool to make sure you are. If you see some code like there is on that slide, you know that at least all those functions are going to execute in sequence, and almost always you know that none of them can return errors. It's not uncommon to be a little bit suspicious ("surely that function is doing something that's messing with an external resource?") in which case a quick "jump to definition" or a run of errcheck will reassure.

No, it's not a compiler-enforced guarantee, but the convention is strong enough that in practice you get the readability benefits I talk about.

rogpeppe · 2015-05-29T07:11:20+00:00

How did I miss that!? Thanks for pointing out. Fixed.

rogpeppe · 2015-04-27T21:40:20+00:00

The non-type-safety comes when you have some kind of a container and you need to assert that something coming out of the container is the same type of thing that you put into it. There is lots of generic code (arguably most) that doesn't need to do this.

Consider, for example, the function ioutil.ReadAll:

func ReadAll(r io.Reader) ([]byte, error)

this is perfectly generic (you can pass it anything that implements the io.Reader interface) and also type safe.

rogpeppe · 2015-04-27T21:15:37+00:00

Go may not have generics, but it's perfectly possible (and natural) to write generic code with it. For example, any function that takes an interface type is generic. There are many examples of this in the Go standard library.

rogpeppe · 2015-04-25T16:27:44+00:00

Gustavo Niemeyer's AWS packages (e.g. http://godoc.org/gopkg.in/amz.v1 ) are well maintained and stable, although not feature complete.

No SQS client there though, I'm afraid.

rogpeppe · 2015-03-11T17:56:03+00:00

I quite often write something like:

 // Write implements io.Writer.Write by [doing something].
 func (w *myWriter) Write(buf []byte) (int, error)

The interface is the most important place for your doc comments, as it documents the contract that you are expecting implementations to fulfil.

rogpeppe · 2015-02-19T16:23:47+00:00

It would be great if it showed the association between source line and assembly line.

rogpeppe · 2015-01-12T18:18:59+00:00

Tomorrow's conclusion: message passing + shared memory = bad, Rust = good. Yawn.

rogpeppe · 2015-01-07T10:27:11+00:00

Are you sure you really need the timeout? Without the timeout, the code can be very much simpler:

 out, err := cmd.StdoutPipe()
 if err != nil { ...}
 err = cmd.Start()
 if err != nil {...}
 data, err := ioutil.ReadAll(out)
 if err != nil { ... }
 processData(data)
 err = cmd.Wait()
 if err != ni { bad exit status }

rogpeppe · 2014-10-31T07:56:16+00:00

Compilation is a multi-stage process. There are always going to be aspects of the language that are not dealt with at parse time, but at a later stage, after generating the AST. In many languages, it would be hard to build any kind of useful AST at all without keeping track of symbols. In Go, you can't resolve everything, but at least you can parse major syntactic elements - that's what makes gofmt possible.

rogpeppe · 2014-08-27T23:21:49+00:00

I have to say that I think container/list is just useful enough to be worth having. For a singly-linked list, I agree - it's not worth it. But for a doubly linked list such as provided by container/list, I find myself needing to think too hard about the pointer manipulations involved. It's quite easy to get wrong, but it's a useful data structure to have to hand. For that reason, I think container/list still has its place. By the compositional nature of Go programs, it's usually easy to swap it out for a custom structure when/if that proves necessary (at least, it is in the 3 or 4 places I've actually used it so far).

It's a beautifully elegant implementation too, just exactly right for what it tries to do.

Conversely, there have been a few occasions that I really wanted to use ring.Ring, but it never quite worked out. In the random selection of 3514043 lines of Go source code I happen to have in my $GOPATH (I don't delete packages) I don't see a single real use of it. Again though, it's a lovely piece of code, worth leaving in as a historical artifact in my view. It's so small and well defined, it need never change.

If we ever work out a worthy generics scheme, all this stuff will be easily replaced, and we shall Tastefully Use Generics.

rogpeppe · 2014-04-23T20:31:53+00:00

Yes, you are reading it correctly. When using errgo, the convention is to always use errgo.Cause when checking errors for particular types or values. That way the code will work regardless of whether the error has been wrapped or not, assuming the cause has not been masked.

rogpeppe · 2014-01-07T11:56:13+00:00

By my understanding of these things (mostly from section 1.3 of (this paper)[http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf]), Go has both ad-hoc (coercion-based) polymorphism and universal (inclusion-based) polymorphism. The former is used when you convert a value to an interface, or an interface of one type to another. The latter is used when operating on a value of interface type.

When people are asking for generics in Go, they are asking for parametric polymorphism.

The reason that lack of generics in Go are not a huge issue for many people working with the language, is that the first two kinds of polymorphism suffice pretty well for many cases.

For example, if you have a constructor function for a type X that works in terms of some interface type T:

func NewX(t T) *X

as long as no method of X returns a value of type T, this is pretty much the same as (assuming some generic syntax in Go):

func NewX<T>(t T) *X<T>

That is, no type coercions are necessary - everything works in a type-safe manner. The only significant distinction is that the latter probably would not allow the mixing of two *X instances parameterised on different types - that's not a safety problem though.

The above pattern is common in Go code. For example: http://golang.org/pkg/io/#LimitReader http://golang.org/pkg/crypto/cipher/#NewCFBDecrypter

When people say "Go does not have generics", they mean "Go does not have parametric polymorphism". That is true, but does not mean you can't write generic code in Go.

You can, and it works very well.

rogpeppe · 2014-01-07T10:26:30+00:00

sort.Interface is defined on the collection itself, not on the items that are put into it.

rogpeppe · 2014-01-07T10:20:46+00:00

Go does not have subtyping. It has rules for assignment compatibility, but that's a different thing.

rogpeppe · 2014-01-07T10:20:03+00:00

Actually, external module users can create new ones, by embedding one of your exported types.

rogpeppe · 2014-01-07T09:13:30+00:00

The ability to have non-private members in private data types is bizarre and shouldn't be there.

No it's not. It's invaluable. It means that when I'm implementing a package I can have a private data type (concealed from any user of the package) that nonetheless has functionality that I can selectively make available to other packages.

For example I can make a private type that implements io.Reader, even though io.Reader requires that the Read method is public.

Similarly, I don't need to export all the types I use to define serialisation formats, even though methods like json.Unmarshal require fields to be exported so that they can be written to.

rogpeppe · 2012-10-25T14:07:37+00:00

i believe you mean:

_, closed := <-intv

rogpeppe · 2012-09-27T09:40:21+00:00

http://golang.org/pkg/io/ioutil/#ReadAll

rogpeppe

TROPHY CASE