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

61–70 of 91 posts

Re: Show HN: My notes on Working with Go

#61

Post by sjroot »

randomdata wrote: post #50
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.

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.

Re: Show HN: My notes on Working with Go

#62

Post by sauerbraten »

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

Re: Show HN: My notes on Working with Go

#63

Post by throwaway894345 »

cmckn wrote: post #54
throwaway894345 wrote: post #44

Earlier quoted context omitted.

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.

Vast majority of my experience is Java, but I'm in a C# role right now. I have to agree with you, having only used Go tangentially -- the tooling is more approachable and bootstrapping a project is more straightforward. I can go ;) from zero to _something_ in a much shorter time

This is what drew me to Go circa 2012, and I’ve been pleased to find that Go’s value proposition doesn’t end after a short period of time but continues to pay dividends for individual developers and for the project as a whole over the long term.

Re: Show HN: My notes on Working with Go

#64

Post by AnimalMuppet »

throwaway894345 wrote: post #37
Insanity wrote: post #22

Earlier quoted context omitted.

Mh, so you wrote one micro-service and came to that conclusion? What did you do to learn the language beforehand? For what it's worth, I've been programming with Go professionally for a few years, and I do agree with the "null" issue. Although in practice - with a good development culture - it's less of a problem than you might think initially. We tend to avoid using pointers (because, they're not even faster than st…

I'm a big fan of ML-like type systems, but I never understand why Go gets so much more grief than Python, JS, etc for having nil. At least in Go, only reference types can be nil as opposed to literally any variable. Same with conversation about generics: "How can anyone write software in a language without [type-safe] generics?" of course lots of profitable software is written in languages with no type safety whatsoe…

I think that it doesn't bother people when a non-type-safe language isn't type safe. If you reach for Python, you know what you're getting. But when a type-safe language is type-safe-except-for-X, that bothers people who wanted a type-safe language.

And it's one thing if the except-for-X is "except for conversions", like casts in C, C++, and Java. Non-type-safe generics aren't usually a place where you are deliberately bypassing the type safety; they're a place where you'd like to have the type safety you have everywhere else in the language.

Re: Show HN: My notes on Working with Go

#65

Post by The_rationalist »

throwaway894345 wrote: post #44
The_rationalist wrote: post #40

Earlier quoted context omitted.

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.

It would be interesting to say how much years of experience actively programming in C# you have.

Re: Show HN: My notes on Working with Go

#66

Post by mylinkedlist »

The_rationalist wrote: post #34
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.

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

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.

Re: Show HN: My notes on Working with Go

#67

Post by throwaway894345 »

The_rationalist wrote: post #65
throwaway894345 wrote: post #44

Earlier quoted context omitted.

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.

It would be interesting to say how much years of experience actively programming in C# you have.

5 years.

Re: Show HN: My notes on Working with Go

#68

Post by axaxs »

sauerbraten wrote: post #62

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

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

Re: Show HN: My notes on Working with Go

#69

Post by zeroc8 »

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

Every developer on the project then uses his favorite subset. Which may or may not be the same one you prefer and know. Unless of course you know everything ;)

Re: Show HN: My notes on Working with Go

#70

Post by ed25519FUUU »

sjroot wrote: post #59
curryst wrote: post #45

Earlier quoted context omitted.

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

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

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

Agree. As much as possible, always leave it up to your caller on whether or not you want the blocking calls to run concurrently. Over-use of `go` as well as unnecessarily buffered channels are two really common anti-patterns with new Go developers.

And don't get me wrong, they're not breaking or absolutely terrible design choices, it's just that they're choices you typically wouldn't make after spending quality time writing apps with the language.

Post reply on HN