Show HN: My notes on Working with Go

https://github.com/betty200744/ultimate-go

by betty200744 • 6 years ago

185 56 6 years ago

github.com

mesaframe• 6 years ago

It's just code with comments what code is doing. Can we call them notes?

Jestar342• 6 years ago

It's very clearly a lot more than just commented code. They are examples/snippets of common patterns.

dgellow• 6 years ago

To answer to your comment: code with comments can be notes, yes.

colesantiago2• 6 years ago

It has Go code with comments which are notes to the author. just like the title of this post.

would be useful to somebody, seems like a good idea to me.

bouncycastle2• 6 years ago

Go is very readable. It seems I can understand what he's doing / means, even with Chinese comments!

cy_hauser• 6 years ago

My first click was the link for "Accessing a value of an unexported identifier". Figured I'd see some reflection trick or similar. In looking at that code I still have no idea what it's doing in relation to accessing an unexported identifier.

So I went to the next link down, "Unexported fields from an exported struct". Figured this would be the clever way to access the "message" field. But again I don't get it. It seems it's the same code as the last example.

This either says something about my ability to understand Go code or that maybe a bit more exposition would be useful for at least some of the examples.

smnscu• 6 years ago

Not strictly related to OP but literate programming is pretty cool: https://en.wikipedia.org/wiki/Literate_programming

mylinkedlist2• 6 years ago

Thank you. I am just beginning to learn Go. This will be very useful to me.

If anyone knows similar notes for Python & C#, please reply.

The_rationalist4• 6 years ago

What make you keep learning Go once you've tasted C# delights?

throwaway8943455• 6 years ago

I started with Java, C#, and Python and one thing I really appreciated about Go was the simplicity. I like how many features it strips from C#. Some people take the tack that a language that is the union of all features is the best possible language on the grounds that one can choose their own feature set, but this is pretty obviously fallacious when you consider that you need to collaborate with others, use 3rd party libraries, etc. I also like the fact that it compiles to a single static binary by default.

Don't get me wrong, I think C# and .Net in general are pretty cool pieces of technology, but I never find myself reaching for them because I'm very often confident that I can get the job done more quickly with Go.

coip• 6 years ago

.NET runtime

mylinkedlist2• 6 years ago

My work involves a lot of AWS infra related things. Some time ago, I was tasked with finding a way to route websocket requests to the backend, which is completely dynamic. While I was looking for solutions, I came across posts here in HN about creating simple reverse proxies using Go. This got me interested in Go. I felt Go would be an ideal language for networking related work. Note that I am a complete newbie in all these, so could be wrong.

shp0ngle• 6 years ago

This is one person notebook. Lot of it is just experiments and not idiomatic code.

(I don't mean ill to the original author, they present it as such. Just saying that here.)

lattalayta• 6 years ago

I haven't looked through all of them, but I came across this website recently. https://learnxinyminutes.com/

I think it's more geared towards people who have experience in one language and want to get a quick crash course in another. Most useful for people who learn by example.

cmckn2• 6 years ago

This is great! Super clean. Thanks for sharing!

pc86• 6 years ago

Please have commit messages more informative than "update $filename"

sjroot7• 6 years ago

Please try to contribute something actually relevant to the post.

adamhearn• 6 years ago

If you are so wise, what commit message should I use if I just changed the filename?

sjroot7• 6 years ago

Warning: opinions inbound

I clicked one part (enums) and noticed a pretty glaring issue. The way you are doing enums is really _not_ conventional Go code and probably not something I would allow past a PR review. I’m saying this as someone who has built many production systems with Go and taught it to many devs coming from Java.

This guide is more in-line with how Go enums should be designed: https://blog.learngoprogramming.com/golang-const-type-enums-...

So, while I dig a little further, I think it’s fair to warn people to take this with a grain of salt. Use the language yourself and come to your own conclusions as OP did.

colesantiago2• 6 years ago

So, while I dig a little further, I think it’s fair to warn people to take this with a grain of salt. Use the language yourself and come to your own conclusions as OP did.

I'm sure with the experience you have with Go, you can open a pull request to their notes to fix this issue.

sjroot7• 6 years ago

If no one has by EOD today, I will! Good idea. :)

arwineap• 6 years ago

I use this pattern without iota; tending towards constants as strings. This allows it to "serialize" to strings nicely instead of exposing useless (without context) integers

Do you have any thoughts on iota vs strings?

sjroot7• 6 years ago

I typically use strings for enum values as well.

curryst• 6 years ago

What is the advantage of building out enums your way vs OPs? I've done both ways, and I didn't find any situations where one was demonstrably better than the other. Is it that there are no globals? Is it that it's actually constant?

One potential annoyance to me in your design is that there isn't an easily accessible map of enum values and their string representation. That is really useful for testing; most of my enums end up with a .Validate() method that checks whether the underlying value is actually a valid member of the enum. If I have that map, it's trivial to right a test that iterates over enum keys and ensure that a) valid keys pass Validate(), and b) enum.String() returns the corret string. Enums (theoretically) shouldn't be modified at runtime, so it should be perfectly safe and valid to have a single, global instance of that data.

I thought the use of maps to store the enum keys/values was odd, but when I thought about it, maps allow the enum keys to be sparse, which can be valuable.

sjroot7• 6 years ago

First off, I should clarify that I'd actually love to see Go add support for proper enums, as I've certainly found it lacking.

My biggest issues would be maintainability and, as you mentioned, using global maps. If your enum itself is not a string value, but you NEED a string representation, then it should just implement `Stringer`.

As far as maintainability:

- The naming convention used here is not consistent with how enums are named in Go. For a good example, see the HTTP package, specifically request methods and response status codes [1]. Really, it isn't even an appropriate naming convention for constant values in any language, with `UPPERCASE_UPPERCASE_minor_note`, it looks a bit silly and took longer for me to grok.

- What if I want to add a new enum variant? I seriously have to add it to three different places? If I start touching this map in places outside the original source file, things will get really ugly really fast.

- A bit nit-picky, but: why use an `int32` here?

This file, in my opinion, is over-engineered. Go code should be simple; many people learning Go for the first time hesitate to work that way, unfortunately.

Other common issues I see with people learning Go for the first time:

- Overuse of concurrency. People like to use the `go` statement wherever possible, and create overly-complex APIs with channels. Unless you have multiple events that need to be done in parallel, yet simultaneously needing to communicate between them, you should not use them in your package's public API. Let your package consumers choose when to make that call.

- Package structure, particularly in modules. People like `src` directories, but Go doesn't work that way. Your top priority as someone learning Go should be to dig through Go's standard library itself and see how it is organized.

[1] https://golang.org/pkg/net/http/#pkg-constants

randomdata• 6 years ago

iota/const type enums are covered in another section: https://github.com/betty200744/ultimate-go/blob/master/Langu...

The code in the section labeled Enums looks like it is straight out of the Protobuf compiler. grpc is referenced later on, so that structure pattern may be related.

sjroot7• 6 years ago

Ah, that would make sense. But then I'd have to dip into my jar of opinions on gRPC + Protobufs...

TLDR: Before going down that route, you should make sure you really REALLY need them. Someone learning Go for the first time probably doesn't.

ggordan• 6 years ago

it looks like the generated code of a protobuf enum

oldgun• 6 years ago

Thanks for the work. It's quite some materials to compile. I love how you organize your thoughts and knowledge together and I've just started doing that too.

0xdeadbeefbabe• 6 years ago

Is if err != nil supposed to become if err.Type.something != thatType?

hujun• 6 years ago

good stuff, there is another really good GO online book: Go 101,https://go101.org/ a lot of details, has been really helpful for me to advance in Go

likeabbas2• 6 years ago

I really enjoyed using Go in my Distributed Systems course in college, and I've enjoyed using it as a replacement for Python for little scripts I've written since the typed aspect of it makes it easier for me to go back and read what I've done. But, I have not enjoyed the Go micro service we use at work. We went with Go thinking the coroutine thread implementation would significantly improve performance over a Java microservice, but the service turned out to be GC limited. And the overall lack of support for most language features has made this codebase much larger than it needed to be.

I wish I could convince my team to try Rust for our next service

derefr• 6 years ago

but the service turned out to be GC limited

Go indeed has a lousy GC (compared to the JVM, at least.) This is why, in most production Go codebases I've seen, there's heavy reliance on https://golang.org/src/sync/pool.go (or a NIH knocked-together version of it, if the author doesn't realize sync/pool exists.)

Try just switching a few of your most-oft-called constructors to allocate from a pool. It's pretty much the lowest-hanging fruit for Go performance gains.

likeabbas2• 6 years ago

Right, but if we go with Rust we won’t have to worry about GC issues

sauerbraten• 6 years ago

I checked out the example code for arrays (https://github.com/betty200744/ultimate-go/blob/3de8a053d9f7...) and noticed that OP seems to misunderstand a few things about Go arrays:

- the cheat sheet differentiates between 'declaring' and 'declaring and initializing', but in Go there are no uninitialized arrays (or slices) - a lot of times in this file, a slice is created instead of an array (lines 18, 21, 25, 31) - arrays in Go don't really have a capacity (it's always the same as the array's length) - the built-ins append and copy as well as the sort functions don't accept arrays (I assume this is why slices are created?)

axaxs3• 6 years ago

in Go there are no uninitialized arrays (or slices)

This is a little murky and misleading. In Go, you can actually save memory by 'declaring' only. For example, if you do var x []string, and never use x, it never actually uses memory. Whereas x := []string{} does. The JSON encoder treats the two differently, as well.

yencabulator2• 6 years ago

Much like the github link, you're confusing slices with arrays. Slices can be nil (data=nil, len=cap=0) or non-nil (data points somewhere, len and cap are what they are), but arrays are just arrays, there's no such thing as an uninitialized [3]byte.

Show HN: My notes on Working with Go

Related Stories