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

How Go detects struct copies with sync.noCopy

func25.dev

Post reply on HN
Print view View original

11–20 of 82 posts

Re: How Go detects struct copies with sync.noCopy

#11

Post by kbolino »

reorder9695 wrote: post #9
kbolino wrote: post #7

Earlier quoted context omitted.

This feels like a style complaint and not one about substance. An inaccessible (because it's named _) zero-length struct field is just another kind of metadata. It also doesn't require you to pollute the method set, which would be a bigger issue. The real hack to me is that anything which simply has Lock() and Unlock() methods is considered uncopyable.

Coming from Rust anyway (can't say I'm familiar with Go), nothing about having it as a trait would pollute the method set, traits don't have to have methods (e.g. pin, unpin, send, sync, etc.). Yes a zero length field can be metadata and this is a style complaint but a struct's fields are traditionally its data and the type is its metadata, I feel like it's harmful to mix these two as I at least wouldn't generally lo…

Interfaces in Go (the closest equivalent to traits in Rust) don't have to have methods either, but they are structurally typed. This is like "static duck typing" if you will. So an interface with no methods is implemented by every type in the language (indeed, this became such a useful pattern that the name "any" was reserved for it in Go 1.18).

Marker interfaces can exist in Go, but here they are another kind of hack. They must define at least one method (which doesn't have to be public), though that method is never actually meant to be called.

Re: How Go detects struct copies with sync.noCopy

#12

Post by stevecoalbear »

woadwarrior01 wrote: post #4
neilalexander wrote: post #3

Earlier quoted context omitted.

It's not really a hack. It's a hint to a static analyser, that's all.

Most languages would encode such behavior in a trait or a protocol instead of a zero-length struct field. It's type information and ought to be encoded in the type. From that perspective, I think it is a hack.

Go's entire schtick is being simple, eschewing language complexity in favour of letting the programmer handle it themself. Like C, but with pointer safety and garbage collection.

We learned from C++ and Rust that languages can be so smart that people can't effectively use them. Go is the opposite. It's so dumb that anyone can use it, but it doesn't have some native language features you might want.

Re: How Go detects struct copies with sync.noCopy

#13

Post by stevecoalbear »

woadwarrior01 wrote: post #2

> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...

Go's full of hacks, and holds no shame over it. Zero-initialized everything, and proceeding to 'defer' instead of RAII, generic builtin types despite lack of generics (until recently), no builtin list type, slices having capacity...

This was Go's design philosophy until Rob Pike left - to do the simple thing simply and not try to be clever about it.

Re: How Go detects struct copies with sync.noCopy

#14

Post by woadwarrior01 »

reorder9695 wrote: post #9
kbolino wrote: post #7

Earlier quoted context omitted.

This feels like a style complaint and not one about substance. An inaccessible (because it's named _) zero-length struct field is just another kind of metadata. It also doesn't require you to pollute the method set, which would be a bigger issue. The real hack to me is that anything which simply has Lock() and Unlock() methods is considered uncopyable.

Coming from Rust anyway (can't say I'm familiar with Go), nothing about having it as a trait would pollute the method set, traits don't have to have methods (e.g. pin, unpin, send, sync, etc.). Yes a zero length field can be metadata and this is a style complaint but a struct's fields are traditionally its data and the type is its metadata, I feel like it's harmful to mix these two as I at least wouldn't generally lo…

I'm only peripherally familiar with Go. IIRC, Rust defaults to move-only structs with the option to make them copyable with the Copy trait. Swift defaults to copyable structs (like Go), but has a ~Copyable generic type constraint to make them move-only.

Re: How Go detects struct copies with sync.noCopy

#15

Post by insanitybit »

stevecoalbear wrote: post #12
woadwarrior01 wrote: post #4

Earlier quoted context omitted.

Most languages would encode such behavior in a trait or a protocol instead of a zero-length struct field. It's type information and ought to be encoded in the type. From that perspective, I think it is a hack.

Go's entire schtick is being simple, eschewing language complexity in favour of letting the programmer handle it themself. Like C, but with pointer safety and garbage collection. We learned from C++ and Rust that languages can be so smart that people can't effectively use them. Go is the opposite. It's so dumb that anyone can use it, but it doesn't have some native language features you might want.

How is this simple? It's basically a hint to `go vet` that uses a special interface pattern. I'm baffled by what some people call "simple" lol

Re: How Go detects struct copies with sync.noCopy

#17

Post by programcookie »

breakingcups wrote: post #10
woadwarrior01 wrote: post #2

> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...

I'd want to blame Go's compatibility guarantee for this, but I can't because it wouldn't actually stop them from adding a proper solution for this.. Just like the magic comments, it's a sad thing to see appear in this language because it feels like magic incantations one has to know that bend over backwards to not actually extend the language to fit the use case.

This shipped with Go 1.7, almost ten years ago to the day.

Re: How Go detects struct copies with sync.noCopy

#19

Post by pjmlp »

woadwarrior01 wrote: post #2

> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...

The whole Go design philosophy in one sentence, that is what one gets by refusing to adopt modern language practices.

Re: How Go detects struct copies with sync.noCopy

#20

Post by tialaramex »

stevecoalbear wrote: post #13
woadwarrior01 wrote: post #2

> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...

Go's full of hacks, and holds no shame over it. Zero-initialized everything, and proceeding to 'defer' instead of RAII, generic builtin types despite lack of generics (until recently), no builtin list type, slices having capacity... This was Go's design philosophy until Rob Pike left - to do the simple thing simply and not try to be clever about it.

> no builtin list type

Wait, which thing do you mean by a "list type" ? A growable array type like Rust's Vec or C++ std::vector or the ArrayList type seen in several languages ?

Or do you mean a linked list type akin to C++ std::list or std::forward_list or Rust's std::collections::LinkedList ?

"List" is vague, which is appropriate if you're talking about very high level abstractions where it doesn't matter how it works and 5 gigabytes, 5 bits, 5 weeks or 5 seconds are all finite so who cares - but in the real world we usually do care.

Post reply on HN