Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My notes on Working with Go

github.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Show HN: My notes on Working with Go

#41

Post by arwineap »

sjroot wrote: post #30

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.learngoprog…

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?

Re: Show HN: My notes on Working with Go

#42

Post by shp0ngle »

mylinkedlist wrote: post #23

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.

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.)

Re: Show HN: My notes on Working with Go

#44

Post by throwaway894345 »

The_rationalist wrote: post #40
throwaway894345 wrote: post #36

Earlier quoted context omitted.

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 part…

Just don't use the features you haven't yet learn. In a few years of experience you will reach a plateau of productivity in go that you'll only be able to beat by migrating toward a more featureful/better thought language

Like I said, I came to Go from C#, and my experience has been such that I’m generally more productive in Go. Further, I already addressed the fallacy that you can just avoid certain features.

Re: Show HN: My notes on Working with Go

#45

Post by curryst »

sjroot wrote: post #30

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.learngoprog…

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.

Re: Show HN: My notes on Working with Go

#48

Post by [deleted] »

arwineap wrote: post #41
sjroot wrote: post #30

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.learngoprog…

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?

[deleted]

Re: Show HN: My notes on Working with Go

#49

Post by lattalayta »

mylinkedlist wrote: post #23

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.

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.

Re: Show HN: My notes on Working with Go

#50

Post by randomdata »

sjroot wrote: post #30

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.learngoprog…

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.

Post reply on HN