Live data from Hacker News

Go structs are copied on assignment (and other things about Go I'd missed)

jvns.ca

1–10 of 176 posts

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#2
Donovan and Kernighan's "The Go Programming Language" is one of the best pieces of technical writing I've ever read. Buy it and read it cover to cover.

Then read the [Go Language Specification][1] cover to cover. It's dry but refreshingly not legalese.

[1]: https://go.dev/ref/spec

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#8
post #5

Misconceptions probably come from Java or Python where a bunch of things are implicitly done for you. I much prefer Golang’s explicitness. The stuff with slices are confusing though

Agreed on this one, the "fix" involving the capacity flag, e.g. "2:3:3" is unintuitive compared to Python where there is no such concept.

Still, as far as sharp edges go these are nothing compared to Java.

See the discussion from:

Common I/O Tasks in Modern Java

https://news.ycombinator.com/item?id=41142737

House of horrors, especially the URL equality triggering DNA requests.

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#9
post #3

Not understanding structs vs pointers is a pretty basic misconception in go. Does this trip anyone else up? I found it unenlightening / unsurprising, and the linked "100 mistakes" piece also very basic and in some cases just plain wrong.

"Very basic" is the entire point of this exercise. Just because things are basic doesn't mean people won't misunderstand them, and won't benefit from clarification.

Which of those 100 mistakes were "plain wrong"? That would be useful feedback for the author.

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#10
One of the many things I find inspiring about Julia is how quick she is to admit to mistakes she has made or things that she hasn't understood.

If she didn't understand it, I can 100% guarantee that there are large numbers of people out there who also didn't understand it - many of whom were probably too embarrassed to ever admit it.

I think this is a useful trait for senior software engineers generally. If you're a senior engineer you should have earned enough of a reputation that the risk involved in admitting "I didn't know that" can be offset by everything you provably DO know already. As such, you can help everyone else out by admitting to those gaps in your knowledge and helping emphasize that nobody knows everything and it's OK to take pride in filling those knowledge gaps when you come across them.

Post reply on HN