[HN Gopher] Go structs are copied on assignment (and other thing...
       ___________________________________________________________________
        
       Go structs are copied on assignment (and other things about Go I'd
       missed)
        
       Author : misonic
       Score  : 39 points
       Date   : 2024-08-10 04:40 UTC (1 days ago)
        
 (HTM) web link (jvns.ca)
 (TXT) w3m dump (jvns.ca)
        
       | MathMonkeyMan wrote:
       | 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
        
         | heyoni wrote:
         | The language spec was so good I was able to make tangible
         | contributions to an open source project just by using that and
         | I don't consider myself a go programmer at all. I want to buy
         | that book but it's technical and I feel like there might be a
         | second edition around the corner?
         | 
         | /edit I bought it after reading this thread:
         | https://groups.google.com/g/golang-nuts/c/U99js3UYz-U
        
       | metadat wrote:
       | 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.
        
         | simonw wrote:
         | "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.
        
         | adastra22 wrote:
         | 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.
        
           | jerf wrote:
           | I've several times answered questions from people coming from
           | dynamic languages that ask lots of questions about Go
           | pointers. And the answer is, actually, since Go lacks pointer
           | arithmetic, Go pointers work the way you're used to things
           | working. It's the Go _non-_ pointers that are the new bizarre
           | thing you're not used to!
           | 
           | 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.
        
           | layer8 wrote:
           | It's how structs work in C though, and Go is spiritually very
           | close to C, including explicit pointer types, address-taking
           | and dereferencing.
        
           | wrs wrote:
           | In those languages, nearly everything _is_ a pointer, they
           | just don 't call it that, which causes unnecessary confusion
           | when you need to understand what's really happening. (E.g.,
           | in Java, a String is a pointer to a string, not a string; but
           | an int is just an int, not a pointer to an int.)
        
       | zuzuleinen wrote:
       | To generalize the title into a rule is good to remember that in
       | Go everything is passed by value(copy).
        
         | jerf wrote:
         | That is the case for almost every modern language. C++ is one
         | of the few languages that has "references" and at least last I
         | looked that's a language accommodation over what are pointers
         | being passed by value in the assembly, at least until compiler
         | optimizations take over (and that's not limited to references
         | either).
         | 
         | 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.
        
       | acheong08 wrote:
       | 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
        
         | jsfysdfwmyasdf wrote:
         | > I much prefer Golang's explicitness.
         | 
         | This seems hubris for someone who depends on STW GC, escape
         | analysis, and implicit asynchronous preemptive cooperative
         | multitasking.
         | 
         | Maybe you meant Zig or C, then I'd likely agree, but Go is
         | quite literally (& excellently) designed for the bottom
         | performing developer.
        
           | fredrikholm wrote:
           | > Maybe you meant Zig or C
           | 
           | 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
        
         | metadat wrote:
         | 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.
        
           | throwaway8e83 wrote:
           | > URL equality triggering DNS 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.
        
         | jayd16 wrote:
         | What a reach to blame Java.
        
       | simonw wrote:
       | 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.
        
       | akira2501 wrote:
       | It can also be a performance issue since range has to make a copy
       | of whatever was in the slice. Slices of pure structs can be
       | tantalizing for their simplicity but you should be thinking of
       | how you want to range over them first and double check yourself
       | everytime you write:                   _, obj := range ...
       | 
       | You're explicitly asking for the two argument convenience which
       | can have a price.
        
       | unwind wrote:
       | Nice post!
       | 
       | 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).
        
       ___________________________________________________________________
       (page generated 2024-08-11 23:00 UTC)