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

https://jvns.ca/blog/2024/08/06/go-structs-copied-on-assignment/

by misonic • 2 years ago

207 166 2 years ago

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• 2 years ago

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

trentnix• 2 years ago

Learning Go by Jon Bodner, particularly the newest edition, is also excellent.

An aside: are there any other Go books, particularly ones the explore more specific topics, that are recommended? I've read a few that I didn't find very impressive.

pss314• 2 years ago

I liked Cloud Native Go by Matthew A. Titmus and Concurrency in Go by Katherine Cox-Buday.

metadat3• 2 years ago

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.

simonw3• 2 years ago

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

adastra222• 2 years ago

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.

jerf7• 2 years ago

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• 2 years ago

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• 2 years ago

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

danpalmer• 2 years ago

Yeah I'm fairly new to Go, but have done plenty of work in languages with "no pointers" (Python, Java), with pointers (Objective-C), and with "reference/value types" (Swift). I thought I was pretty proficient with all of this, but Go's implementation was really unergonomic. It feels like it's trying to be C, but treating it more like Swift has been more effective I've found. How this all interacts with nils and missing fields in structs is also not very ergonomic, and it feels like the language is obviously missing an optional type, yet I've not seen one used commonly yet.

everybodyknows3• 2 years ago

That was my reaction too, but it does point the way to a more subtle chronic ache in coding Go: the efficiency<->simplicity tradeoff between passing some large struct to a function by reference, or by copying.

The former, "by reference" is guaranteed to impose no increase in calling overhead, irrespective of the compiler's ability to optimize the object code, however fat the struct eventually grows.

The latter, "by copying" guarantees the calling function will upon return find all fields of the struct just as before -- a great aid to understanding during code review.

teivah2• 2 years ago

Please let me know what's plain wrong; I'm always happy to receive constructive feedback.

metadat3• 2 years ago

The beginning item about if-else returns isn't go-specific and is low impact, and immediately turned me off / led me to dismiss the article as a waste of time.

After trudging through more of the list, you've collected a lot of good nuggets! Maybe move the if-else to the end, as it's not particularly insightful compared to the rest.

Also the shadowing, it's fine but much less interesting and unlikely to hook in your target audience up front.

Good luck!

zuzuleinen• 2 years ago

To generalize the title into a rule is good to remember that in Go everything is passed by value(copy).

jerf7• 2 years ago

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.

azundo• 2 years ago

Is python no longer a modern language? Objects are certainly not copied when passed to a function.

klyrs5• 2 years ago

Is copying huge blocks of data free in 2024? My benchmarks suggest otherwise, and the world still needs assembly programmers.

metaltyphoon• 2 years ago

Both C# and Swift makes a distinct difference by having both struct and classes.

jasomill• 2 years ago

For a last-century example of actual pass-by-reference, assign-by-copy, the PL/I program

  foo: proc options(main);
    dcl sysprint print;
    dcl a(3) fixed bin(31) init(1,2,3);
    put skip data (a);
    call bar(a);
    put skip data (a);
  
  bar: proc(x);
    dcl x(3) fixed bin(31);
    dcl b(3) fixed bin(31) init(3,2,1);
    x = b;
    b(1) = 42;
    x(2) = 42;
    put skip data (b);
    put skip data (x);
  end bar;
  
  end foo;

outputs

  A(1)=   1   A(2)=   2   A(3)=   3 ;
  B(1)=  42   B(2)=   2   B(3)=   1 ;
  X(1)=   3   X(2)=  42   X(3)=   1 ;
  A(1)=   3   A(2)=  42   A(3)=   1 ;

demonstrating that X refers to A in BAR and assigning B to X copies B into X (= A).

pjmlp4• 2 years ago

Sure, if they want to be bad developers in C#, F#, Swift, D, Rust, Ada, VB, Delphi, just to stay on the ones that are kind of relevant in 2024 for business, for various level of relevant, versus the ones story has forgotten about.

erik_seaberg2• 2 years ago

Maps and channels and functions are passed by reference. Slices are passed and returned by value but sometimes share state invisibly, the worst of both worlds. It would make more sense if Go either made this stuff immutable, made defensive copies, or refused and required using explicit pointers for all these cases.

dondraper36• 2 years ago

No, it's not the case and this terminology shouldn't be used as it's confusing and unhelpful.

There are reference types in Go even though this is also not a super popular term. They still follow the pass-by-value semantics, it's just that a pointer is copied. A map is effectively a pointer to hmap data structure.

In the early days of Go, there was an explicit pointer, but then it was changed.

Slices are a 3-word structure internally that includes a pointer to a backing array and this is why it's also a "reference type".

That said, everything is still passed by value and there are no references in Go.

Dylan16807• 2 years ago

But the author already knew that.

The important lesson is that assignments are by value(copy).

_lvbh• 2 years ago

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

metadat3• 2 years ago

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• 2 years ago

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• 2 years ago

What a reach to blame Java.

simonw3• 2 years ago

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.

Attummm• 2 years ago

Personally, I think that the idea that programmers should know everything is kinda bizarre.

Programming is about finding the answer. If you already knew everything, you could just sit down and type any program from your knowledge.

We all know that you can't know everything otherwise, why even write documentation or use git?

Unfortunately, it's difficult to move past this idea, and it's so pervasive that stating "I don't know" can negatively affect your standing for some.

simonw3• 2 years ago

Right! The best thing about our chosen career is that it's completely impossible to know everything - there's always a new corner of software engineering to dig into, be it how the Linux kernel works, or programming with Haskell, understanding Transformer LLM architectures, or how the Svelte compiler works or whatever.

silvestrov• 2 years ago

Many people have the same expectation of their doctor: he must know everything or he is completely useless and I should find a new doctor.

It is also insanely difficult for a doctor/surgeon to admit a mistake without being punished severly.

matrix872• 2 years ago

most of the time when people don't ask questions in industry, it isn't because they already know the answers, it's because they don't care what the answers are

blogging is culturally different because there's way more exhibitionism involved

iainmerrick2• 2 years ago

Don't you think, as others in this thread are saying, that one reason people don't ask questions is because they're afraid to admit their lack of knowledge?

We've probably all been in one of those meetings where something is being proposed, and everyone is nodding vaguely along but you're not sure the proposal is correct. Do you ask a clarifying question (and risk seeming foolish for not knowing something obvious) or just let it pass because everyone else seems happy with it?

jsmeaton• 2 years ago

This is what jumped out to me reading this article too - unashamedly admitting to having gaps in knowledge that some others might take for granted.

Bucketing some of those gaps as “probably useful but not to me right now” is also great. It shows a purpose to focus on what matters right now, with a hint to return to when it does pop up again later.

Lots of folks I work with and respect sometimes get trapped in the weeds having to understand every little thing. It’s good to be curious, but sometimes filing it away for later and shipping is more important now.

harrisi• 2 years ago

I recently included a big goof in a blog post. I accidentally consumed all my errors and didn't log them anywhere, so I was just flying mostly blind.

It was also in a language I don't have much experience in (Elixir), doing 3D rendering in OpenGL (which I also don't have much experience in), on a Mac (so no tools to debug OpenGL stuff). Definitely wasted more time than I'd like to admit, but I won't be making that mistake again. :)

xigoi• 2 years ago

I thought you were talking about Julia the language and was so confused.

blub• 2 years ago

This is the kind of mistake that I doubt even a junior Go developer would make. If one is a senior engineer and one has Go on their CV, then one must know the memory management top to bottom.

This kind of downplaying of hard skills and trying to argue that one can help by admitting gaps in their knowledge is at best weird.

petercooper• 2 years ago

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.

Agreed. I think 90%+ of the complaints people have about technical blog posts would go away if authors were more willing to admit what their blog post is really for and what their limitations are.

Writing an "Ultimate Guide to X" as a learning experience is fine if you admit that (and, ideally, use a more humble title) but pretending to be a long time expert in framing when someone isn't leads to problems and a poor reputation. You, too, are fantastic at framing your content properly, and have a great reputation amongst people I know for it.

akira2501• 2 years ago

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• 2 years ago

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

mjevans• 2 years ago

jvns highlights some of the easier to forgot or overlook mistakes, but their source article https://100go.co is a great refresher and introduction as well.

eterm• 2 years ago

This sometimes catches out people C#/.Net too, it's a big difference between Class and Struct, Class is reference type and Struct is value type. (see fiddle below), but in practice people very rarely reach for structs, so people don't tend to build up the muscle memory of using them, even if they intuitively understand the difference between reference types and value types from general use of other types.

(Fiddle demonstration for non-.Net peeps: https://dotnetfiddle.net/apDZP5 ).

rickstanley• 2 years ago

Non-C# developer question: what use-case/situation would a `struct` make sense to use instead of a `class`? Just out of curiosity.

[Edit] Well, there's a nice, special article for this very question: https://learn.microsoft.com/en-us/dotnet/standard/design-gui...

makotech221• 2 years ago

usually performance reasons; don't want to allocate on the heap, contributing to GC pressure, or you want pass by copy semantics

neonsunset2• 2 years ago

Please note that the article is quite old and does not encompass the wide variety of scenarios C# is effective at.

Structs are used for but not limited to: all kinds of "transient" data containers, pass by value semantics, precise control over layout of data in memory, low-level programming and interoperating with C/C++, zero-cost abstractions via struct generics (ala Rust or templates in C++), lightweight wrappers over existing types, etc.

Most C# codebases use them without even noticing in `foreach` loops - enumerators are quite often structs, and so are Span<T> and Memory<T> (which are .NET slice types for arrays, strings and pretty much every other type of contiguous memory, including unmanaged). Tuple syntax uses structs too - `(int x, int y)` is `ValueTuple<int, int>` behind the scenes.

.NET has gotten quite good at optimizing structs, so the more general response is "you use them for the same things you use structs in C, C++". Or the same reason you would pick plain T struct in Rust over Box/Arc<T>.

Intro to structs: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

wvenable• 2 years ago

Even if you exclude performance reasons, some things just make more sense as values rather than instances. A good example is Color. A Color might be an object that holds 3 integers (red, green, blue) but you want to treat it like you would a scalar value. For example, two color instances should be equal if they contain all the same values. Class instances all have their own identity -- two classes instances are not equal even if they contain the same values.

tsimionescu17• 2 years ago

In principle, the answer should be (if we ignored the language community and the model of the stdlib, which we shouldn't do), that structs should be used for most things, and classes only when they are needed. There's nothing a class can do that a struct can't, and structs are not automatically allocated in the heap, so they take some pressure off the GC. Go showed that you can have a fully managed GC language where all types are value types, and get pretty good ergonomics. Java is adding support for value types specifically for performance reasons, and so may have a similar attitude in the far future.

Note that Go does have one feature that makes value types more ergonomic - the ability to explicitly take a reference to one and use it as any other variable, using the syntax of C pointers (but without pointer arithmetic). In C#, if you need a reference to a structs type, your options are more limited. There is `ref` for function parameters, but if you want to store it in a field, you need to use some class type as a box, or perhaps an array of 1 element, since there are no "ref fields" in this sense (there are ref fields, but they are a completely different thing, related to the "ref structs").

Now, in working with real C# code and real C# programmers, all this is false. The community has always preferred using structs almost exclusively for small immutable values, like Color. The standard library and most C# code is not designed with wide use of structs in mind, so it's possible various methods will copy structs unnecessarily around. People aren't used to the semantics of structs, and there is no syntactic difference between structs and classes, so mutable structs will often cause confusion where people won't realize they're modifying a temporary copy instead of the modifying the original.

xnorswap2• 2 years ago

If they are small, then there can be a significant performance advantage to using a struct.

Imagine you have a Dictionary<TKey,TValue>. (That is, a dictionary (hash lookup) from type TKey to type TValue ).

Imagine your choice of key is a composite of 4 bytes, and you want to preserve the meaning of each, so let's say you define a class (shorthand to avoid all the get/set cruft):

    class MyKey {
       byte A;
       byte B;
       byte C;
       byte D;
    }

When you profile your memory usage, to your horror you discover you actually have a keysize of 64 bits for the reference to the location on the heap.

If however you use a struct, then your key is actually the 4 bytes that defines your key.

In modern .Net, you'd probably be better off defaulting to use a record (correction: record struct) type for this purpose unless you have very specific reasons for wanting fine-grained control over memory layout with the StructLayout Attribute.

See this article for using StructLayout:

https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

pjmlp4• 2 years ago

This isn't something that unsual though, from some oldies to newer ones, Delphi, Oberon variants, Modula-3, Common Lisp, Eiffel, D, Swift, and eventually Java (when value class and value record finally lands, EA available)

It is the focus on managed scripting languages, that trips people up, when they finally change to one of those compiled ones.

CharlieDigital• 2 years ago

    > and eventually Java

Wait, it's been a looong time since I did Java. What am I missing here; what does Java do differently from C#?

(C# is my daily driver so I'm quite familiar with its handling of value and reference types)

OJFord• 2 years ago

The one about named returns, err always being nil, why is err even in scope, seems like it should be a compile error to me? (I rarely write Go).

jyap• 2 years ago

In the function signature, the return variable err is type error. Since it is named it is also defined and initialized as nil.

In the code, an error is found and it does not assign a value to err and just returns it as the error value.

So it returns nil as the error when it wants to return an error with a proper value.

The code should be something like:

    if ctx.Err() != nil {
      return 0, 0, ctx.Err()
    }

tialaramex5• 2 years ago

though apparently structs will be automatically copied on assignment if the struct implements the Copy trait

What's actually going on is that the Rust compiler is always allowed to choose whether to just copy bits during assignment, but if your type implements Copy then the value isn't gone after it has been assigned as it would be with the ordinary destructive move assignment semantic -- so any code can continue to use the value whereas otherwise it would no longer exist having been moved.

Some languages make the built-in types magic and you can't have that magic in your own types, Rust mostly resists this, a few things are magic in the stdlib and you wouldn't be allowed to do this magic in stable Rust (it's available to you in nightly) but mostly, as with Copy, your types are just as good as the built-in types.

This actually feels really natural after not long in my experience.

HackerThemAll• 2 years ago

Read The Fine Manual, and read some books, so underappreciated these days...

ozfive• 2 years ago

Looks as though the range loop isn't an issue from Go 1.22 anymore.

https://go.dev/blog/loopvar-preview

tialaramex5• 2 years ago

That's a different language design mistake, which several languages have had to fix including C# back in C# 5.

The question there is, does our for-each style loop make a new variable each iteration, with the appropriate value, or does it have a single variable and it's just re-assigned for each iteration. People who haven't designed a language before might think the second option sounds optimal and won't make a practical difference, but it's actually very annoying and that's why Go changed to the former.

This time though it's not about the variable staying the same, the problem is that we got a copy of the data we cared about, not a mutable reference to that data.

maerF0x02• 2 years ago

    func findThing(things []Thing, name string) *Thing {
      for i := range things {
        if things[i].Name == name {
          return &things[i]
        }
      }
      return nil
    }

Also you could just return i or -1, and the consuming code would be clear about what it was doing. Find the index. Update the item at the index.

    if location := findThing(things, name); location != -1 {
         things[location].Name = "updated"
    }

Joker_vD2• 2 years ago

Well, if you don't mind that it doesn't work correctly with slices: [0], then sure, you may return indices.

[0] https://go.dev/play/p/Q2ntuaugbGQ

benmmurphy• 2 years ago

It does work with slices as long as you use the slice to update as well

maerF0x02• 2 years ago

That didn't work because you didn't pass the same slice in. You subsliced your things slice, which outputs a new slice.

Animats2• 2 years ago

The semantics of when stuff is copied, moved, or passed by reference are all over the place in language design.

C started with the idea that functions returned one int-sized value in a register. This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for that. It's complicated.[1]

Most hard-compiled languages only let you return values of fixed length, because the caller has to allocate space. Dynamic languages where most things are boxed just return the box. Rust makes you declare boxed types explicitly. Vec and String are already boxed, which handles the common cases.

More dynamic languages tend to let you return anything, although there can be questions over whether you have your own mutable copy, a copy-on-write copy, a read-only copy, or a mutable reference to the original. That's what got the OP here, at

    thing := findThing(things, "record")
    thing.Name = "gramaphone"

They thought they had a mutable reference to the original, but they had a mutable copy.

There's a good argument for immutability by default, but many programmers dislike all the extra declarations required.

[1] https://stackoverflow.com/questions/17473753/c11-return-valu...

zbentley• 2 years ago

This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for that.

Jesus Christ. Can we now get “return fruit by vegetable?”

Some speedups may not be worth having to memorize standards documents.

Aeglaecia• 2 years ago

programmers who get the job done without needing to memorise standards or dig into hardware specifics are surely happy enough with general optimisations applied by the compiler like tail call optimisation or copy elision ...

binary1323• 2 years ago

not complicated stuff to understand, and doesn’t even need to be understood to use correctly. Just don’t return pointers to locals.

beltsazar• 2 years ago

There's a good argument for immutability by default, but many programmers dislike all the extra declarations required.

That's one little reason why Rust is loved by many: immutability by default. Meanwhile, it's not even possible in Go to declare immutable variables!

Cthulhu_• 2 years ago

I hope it gets added, it adds so much safety to the language. Mind you, Go is not a very safe language in general, its type system is pretty loose compared to e.g. Java or Typescript. I don't believe it wants to be though.

XorNot2• 2 years ago

Immutable by default is only really possible now that we have gobs of memory though. I'm not even sure it's likely to stay popular: the demands of data processing at scale mean we're all likely to be routinely handling gigantic datasets which we don't want to copy all over the place.

The real problem is just visibility: am I editing a copy of the original? Who else can edit the original? Who's going to?

I'd argue those two questions are what we actually want to know the answer to, and immutability criteria are just an awkward compromise solution.

pram• 2 years ago

The one thing I’ve personally wanted in Go is something like final in Java, for structs.

mariozski• 2 years ago

Actually Go is always pass by value. Even when you pass the pointer you’ll get a copy of it.

the_gipsy• 2 years ago

What matters is that a function can modify the value pointed at, without necessarily returning it.

binary1323• 2 years ago

That is no different than C or C++. A pointer is just another type of value.

everybodyknows3• 2 years ago

Actually Go is always pass by value.

False, this depends upon the underlying type. The Go 'map' type is always pass (and assign) by reference.

https://go.dev/play/p/ovfuNBNtiza

kzrdude• 2 years ago

Well, that's another nice thing with Rust. Maybe it's not the saviour language but at least it brings clarity to ownership of values.

foldr2• 2 years ago

I think the same thing could happen in Rust. foo.x = bar will compile if foo is a copy or if it's a mutable reference. As in Go, you'd have to explicitly type 'foo' in order for any compiler error to show up.

mmaniac• 2 years ago

The killer IMO is the combination of mutability and implicit references. With either immutability or explicit references, the hazards are greatly lessened. In the absence of mutability, there's no observable difference between passing a reference and passing a value. With explicit references, there's always an indication when objects are liable to nonlocally mutate.

Go and C are quite wise to use pass by value and opt-in references. It avoids the programmer's burden of immutability by default while making it more obvious* when to be aware of potential mutation. A programming style incorporating local mutation also comes very naturally, which is simple, practical, and remains easy to reason about.

*Go and Rust would be wiser if they retained -> from C so that this obviousness would remain without having to check type declarations which may even have been inferred.

Python gets hit the worst by this combination. On top of having mutable references everywhere, it also doesn't make a big deal about object identity (unlike e.g. Java) and has a lot of declarative constructs. Which means you get surprising stuff like this.

  >>> foo = [[]] * 10
  >>> foo[0].append("bar")
  >>> foo
  [['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar']]

  >>> def baz(arg = []):
  ...   print(arg)
  ...   arg.append("qux")
  ... 
  >>> baz()
  []
  >>> baz()
  ['qux']

geoka9• 2 years ago

A (shameless) plug: I've been building a collection of Go bits like this. Hopefully it can be useful to someone other than me, too:

https://github.com/geokat/easygo

frankjr• 2 years ago

Another thing to watch out for is that "defer" in Go is executed at the end of the function, not at the end of the current scope. This makes it not only more difficult to reason about but also much less useful.

usrbinbash3• 2 years ago

    thing := Thing{...}
    other_thing := thing
    pinter_to_same_thing := &thing

ALL types in go are being copied by value. There is no such thing as a "reference" in this language. Even a slice or map is just a small struct with some syntactic sugar provided by the language, and when you assign a slice to another variable, you are, in fact, creating a copy of that struct.

uniq7• 2 years ago

My pet peeve with slices and maps is that they hide a reference to the actual structure, and you are never sure of what you are modifying, or the performance impact when moving around big structures.

Example with slices: https://go.dev/play/p/8arcUrGU4SU

Example with maps: https://go.dev/play/p/eq8i6z8a4jN

usrbinbash3• 2 years ago

No, there is no "hiding" of a "reference". There is copying a struct:

    s2 := s1

This copies the struct in `s1` into a new name `s2`. This struct contains, among other things, a pointer to the backing array. Therefore, when you assign to the slice

    s2[0] = "bye"

You assign to the same backing array. Slices are not arrays. Copying a slice copies a struct containing a pointer to an array. A similar situation holds true for maps. The same logic that is universal throughout the language, aka. "Go only ever copies things by value" holds true for all of these types.

https://go.dev/ref/spec#Slice_types

"A slice, once initialized, is always associated with an underlying array that holds its elements. A slice therefore shares storage with its array and with other slices of the same array; by contrast, distinct arrays always represent distinct storage."

knorker• 2 years ago

It's sad that most of the items are clear language design mistakes stemming from the creators not learning from other languages. Go is a missed opportunity. Item after item of "yeah that wouldn't happen in rust".

The list feels like it's meant to blame the programmer, but that ain't right.

antonvs• 2 years ago

This drives me crazy. Go essentially doubles down on all the programming language mistakes we spent decades discovering and finding solutions for.

When people ask all those questions about why software is still so terrible in all sorts of ways, a large part of the answer is languages like C, C++, JavaScript, Python, and now Go.

nasretdinov• 2 years ago

For me, who came from PHP, the way Go works seemed the most natural. PHP is also one of very few (old) languages which makes everything pass-by-value (except for objects, which initially also were pass-by-value but it was so confusing for people coming from other languages that they changed it).

Treating everything as a value IMO is quute nice _if you except it_, because it eliminates a whole class of possible side effects from mutating the value inside the receiver, without requiring extra complexity like immutability in the language itself.

glenjamin• 2 years ago

Something that strikes me about Go's approach here, and the explanations in many of the posts on this page, are that they're all focused on what is happening under the hood: What memory are we pointing at, what's being copied, is it a pointer etc etc.

Whereas if we start from a point of view of "What semantics and performance guarantees do we desire?", we might end up with a more coherent user-facing interface (even if internally that leads to something more complex).

Personally, my mental model is often influenced by Python - where a name is distinct from a variable, but this distinction doesn't seem to appear in many other languages.

ryandv• 2 years ago

Case of where the language affects (and can clarify/obscure) your model of the system and its behaviour: C++'s copy-assignment operator [0], which makes these semantics explicit.

[0] https://en.cppreference.com/w/cpp/language/copy_assignment

binary1323• 2 years ago

It is terrifying to read these comments. I don’t think I realized how confused so many programmers are about how programming works. Maybe the safety police are right after all.

juped• 2 years ago

I always get surprised in the opposite direction by languages that work like that, fun to see it from the other side.

As for the second mistake listed, this is practically the reverse confusion itself... I remember one time in an interview, I got this bit of arcana about Go slices right and the interviewer insisted it was wrong, and despite the evidence being on the screen in the program output at the time, I just backed down. Not sure why I or anyone ever submits to the indignity of job interviews, but it also soured me on Go itself a bit!

manlobster• 2 years ago

Golang is sometimes considered a simple language, but it's not really beginner-proof like Java was designed to be. It's a good idea to spend time learning it thoroughly.

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

Related Stories