11–20 of 176 posts
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.
_, obj := range ...
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
[flagged]
This seems hubris for someone who depends on types, looping constructs, and compilers.
Maybe you meant writing machine code or 6502, then I'd likely agree, but C is quite literally (& excellently) designed for quiche eaters.
/s
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.
As she points out though, a lot of dynamic languages don’t behave this way. A string after all points to a heap allocation; so it’s not unreasonable to think of a string as a pointer.
So there is definitely a common language heritage that will find the behavior of value copies in Go surprising. I came into Go with compiled language experience but I'd been exclusively in dynamic scripting languages exclusively for over a decade. I had to remind myself about this as well.
To generalize the title into a rule is good to remember that in Go everything is passed by value(copy).
If you're in 2024 and you're in some programming class making a big deal about pass-by-value versus pass-by-reference, ask for your money back and find a course based in this century. Almost literally any topic is a better use of valuable class time than that. From what I've seen of the few unfortunate souls suffering through such a curriculum in recent times is that it literally anti-educates them.
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
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.
I agree it can be confusing, as the URL also can act as a client that performs actual connections. The documentation actually mentions that URI is a better choice when you want only a representation
In general I don't think the other examples are that bad. The reason why there are so many different ways of performing I/O, is because Java is evolving and adding better solutions, but can't really remove older stuff like "URL" because it is widely used.
I see similar issues with other languages as they evolve, and I think Java has managed it well. The IDEs are also often good at making suggestions on how to replace outdated code.
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.
As she points out though, a lot of dynamic languages don’t behave this way. A string after all points to a heap allocation; so it’s not unreasonable to think of a string as a pointer.
Also, not everyone knows that even the much-maligned old C does this.
It's a huge red flag/cringe when someone breaks out memcpy() just to copy a struct value (or return it, obviously).
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
/edit I bought it after reading this thread: https://groups.google.com/g/golang-nuts/c/U99js3UYz-U