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

Go subtleties

harrisoncramer.me

Post reply on HN
Print view View original

121–130 of 190 posts

Re: Go subtleties

#121

Post by tczMUFlmoNk »

Someone wrote: post #93

FTA: “In Go, empty structs occupy zero bytes. The Go runtime handles all zero-sized allocations, including empty structs, by returning a single, special memory address that takes up no space. This is why they’re commonly used to signal on channels when you don’t actually have to send any data. Compare this to booleans, which still must occupy some space.” I would expect the compiler to ensure that all references to t…

If you have a buffered channel with 100 "true"s in it, you're using 100 bytes.

If you have a buffered channel with 100 "struct{}{}"s in it, you only need to store the length, since the element type is zero-sized.

Re: Go subtleties

#122

Post by ttz »

DanielHB wrote: post #48
spoiler wrote: post #24

Earlier quoted context omitted.

I know it's not exclusive to Go or any language, but you can most certainly write incomprehensible code in it. If anything, expressiveness and proper abstractions can save you from this. I think people often get burnt by bad abstractions in expressive languages, but it's not a problem of the language, but the author's unfamiliarity with the tools at their disposal. If someone starts being clever with abstractions bef…

I like to say this: "Only my code is allowed to be clever" But, on a serious note, I agree with you. Go lacks a lot of power, especially in its type system, that causes a ton of problems (and downtime) that in other languages is trivial to prevent statically.

out of curiosity (not meant snidely), do you have an example of a case where the weaker type system resulted in serious problems?

Re: Go subtleties

#123

Post by tptacek »

DarkNova6 wrote: post #17

As somebody who only views Go from a distance, I see this list as a combination of „what‘s the big deal?“ and „please don‘t“.

If you don't write Go at all, this blog post isn't going to be useful to you, and you aren't its audience. It's fine not to have an apt take for a programming-language-specific article!

Re: Go subtleties

#124

Post by kbolino »

bpicolo wrote: post #44
rowanseymour wrote: post #22

Earlier quoted context omitted.

That works until 1) you don't want to export the value types 2) the return values aren't simple structs but slices or maps because []x is not a []X even if x implements X.

For 1/, you can return a struct value type without exporting it. If it satisfies the receiving interface they won’t have a problem. That’s exactly the pattern I use for most Go development

This affects discoverability, though. Your unexported type won't have public documentation. So you end up having to publish an interface anyway (even if you don't return it) or document in words what the method set looks like.

Re: Go subtleties

#125

Post by gethly »

usrnm wrote: post #12
valzam wrote: post #6

Earlier quoted context omitted.

I guess as a corollary, Go really rewards writing the dumbest code possible. No advanced type shenanigans, no overuse of interfaces, no complex composition of types. Then you will end up with a very fast, resource light system that just runs forever.

To be fair, checking if an interface is nil is very dumb code, and the fact that it doesn't work is one of my biggest gripes with the language. In this case it's clearly the language (creators) who's dumb

Interface is just behavior. That is the main difference from other languages. Go is about "what", not "who". So when you are checking for nil, you are essentially asking whether the variable has any logic it can perform. And that can happen only if some behavior was provided, ie. it is not nil.

Re: Go subtleties

#126

Post by gethly »

h4ck_th3_pl4n3t wrote: post #116
valzam wrote: post #6

Earlier quoted context omitted.

I guess as a corollary, Go really rewards writing the dumbest code possible. No advanced type shenanigans, no overuse of interfaces, no complex composition of types. Then you will end up with a very fast, resource light system that just runs forever.

Oh boi, all my RW mutexes for maps across goroutines would disagree.

Use sync.Map or create simple wrapper to control access.

Re: Go subtleties

#127

Post by gethly »

jasonthorsness wrote: post #79

Great list! Reminds me to check out more of the new stuff in 1.25. The one thing I wish Go had more than anything is read-only slices (like C#). The one thing I wish more other languages had that Go has is structural typing (anything with Foo() method can be used as an interface { Foo() }.

Yeah, having mutability optional would be great. It would also allow a lot of data to pass through the stack instead of heap due to pointers, which Go is riddled with for absolutely no reason(imo).

On the other hand, now that we have iterators in Go, you can create a wrapper for []byte that only allows reading, yet is iterable.

But then we're abstracting away, which is a no-go in Go and also creates problems later on when you get custom types with custom logic.

Re: Go subtleties

#128

Post by linhns »

lagniappe wrote: post #69
acatton wrote: post #53

> The wg.Go Function > Go 1.25 introduced a waitgroup.Go function that lets you add Go routines to a waitgroup more easily. It takes the place of using the go keyword, [...] 99% of the time, you don't want to use sync.WaitGroup, but rather errgroup.Group. This is basically sync.WaitGroup with error handling. It also has optional context/cancellation support. See https://pkg.go.dev/golang.org/x/sync/errgroup I know it…

>golang.org/x/ is stuff that should be in the standard library but isn't, for some reason think of it as testing/staging before being merged into stable stdlib

I do believe it’s backwards compatibility and evolving APIs

Re: Go subtleties

#129

Post by gethly »

radlad wrote: post #106

> Using len() with Strings, and UTF-8 Gotchas Try utf8.RuneCountInString().

Problem with this is that it requires the whole string to be iterated over, byte by byte, or rune by rune, whereas len() does no such thing as the length is stored in the underlying type.

Re: Go subtleties

#130

Post by gethly »

furyofantares wrote: post #89

I balked a little when the article refers to format strings as "string interpolation" but there's multiple comments here running with it. Am I out of date and we just call that string interpolation these days? I also found this very confusing: > When updating a map inside of a loop there’s no guarantee that the update will be made during that iteration. The only guarantee is that by the time the loop finishes, the ma…

Mutating maps during iteration is a big red flag.
Post reply on HN