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

71–80 of 91 posts

Re: Show HN: My notes on Working with Go

#71

Post by sjroot »

ed25519FUUU wrote: post #70
sjroot wrote: post #59

Earlier quoted context omitted.

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

Agreed! In my situation, lots of developers were porting Java APIs to go. They essentially had to be rewritten twice:

1st way: the way our Java devs thought Go was “supposed” to be written

2nd way: how Go should probably actually be written

By embracing the simplicity and Go’s opinionatedness the first time around, you’ll save yourself a lot of refactoring headache later.

Re: Show HN: My notes on Working with Go

#72

Post by ggordan »

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…

it looks like the generated code of a protobuf enum

Re: Show HN: My notes on Working with Go

#73

Post by throwaway894345 »

AnimalMuppet wrote: post #64
throwaway894345 wrote: post #37

Earlier quoted context omitted.

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

I don’t buy this at all. No one finds out that Go lacks generics when they’re neck deep in a project, it’s widely known ahead of time. If you need something that is type-safe >95% of the time, Go isn’t the answer (yet, anyway) and you rule it out before the first line of code is written and move on to other languages (of course, lots of life-or-death applications are written in C which has a weaker type system than Go, so I would also be skeptical about applications that need >95% type safety).

Re: Show HN: My notes on Working with Go

#74

Post by yencabulator »

axaxs wrote: post #68
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.

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.

Re: Show HN: My notes on Working with Go

#75

Post by axaxs »

yencabulator wrote: post #74
axaxs wrote: post #68

Earlier quoted context omitted.

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

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.

I'm not. I've been a Go programmer for years, and I literally quoted your comment above mine - it says (or slices)

Re: Show HN: My notes on Working with Go

#76

Post by heleninboodler »

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…

> If your enum itself is not a string value, but you NEED a string representation, then it should just implement `Stringer`.

I don't understand. Isn't this exactly what they did?

The only actual problem I see with this enum implementation is that the module-level value->string map is module public, which should definitely be fixed. Other than that, this looks like a bog-standard enum implementation with slightly odd internal naming conventions.

> I seriously have to add it to three different places?

Well, come on, now. The idiomatic example has two places to edit as well, and the third place here is for functionality the idiomatic example doesn't have (mapping back from string to value). You could always generate this map at runtime in an init() function but I suspect some would complain about that as well.

Re: Show HN: My notes on Working with Go

#77

Post by The_rationalist »

throwaway894345 wrote: post #67
The_rationalist wrote: post #65

Earlier quoted context omitted.

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

5 years.

Wow OK you're then an interesting data point that make me accept to begin doubting about the supremacy of C#/Kotlin over Go.

Re: Show HN: My notes on Working with Go

#78

Post by throwaway894345 »

The_rationalist wrote: post #77
throwaway894345 wrote: post #67

Earlier quoted context omitted.

5 years.

Wow OK you're then an interesting data point that make me accept to begin doubting about the supremacy of C#/Kotlin over Go.

Productivity isn’t the only factor. C# and Kotlin are great languages in their own right. Notably for very dynamic workloads, the respective JIT compilers can do some impressive optimizations.

Re: Show HN: My notes on Working with Go

#79

Post by bouncycastle »

cy_hauser wrote: post #32
bouncycastle wrote: post #15

Earlier quoted context omitted.

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

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

For that, you will need to know a bit about Go. The full totorial is here https://www.ardanlabs.com/blog/2014/03/exportedunexported-id...

So in the end there's really no trick, you still can't access them directly.

Re: Show HN: My notes on Working with Go

#80

Post by erik_seaberg »

nobleach wrote: post #29
zero_shift wrote: post #25

Earlier quoted context omitted.

Also GC is a real no-no for real-time.

Go has a GC. Specifying the need for manual memory-management might be moving the goal-posts a bit. Edit Phone auto-correct from memory management to measurement.

To be fair, it's possible to write code that does no heap allocation in each of these languages. None of them guard against mistakes that create GC work, and Java would not be my choice for this.
Post reply on HN