How Go detects struct copies with sync.noCopy

ffunc25 4 days ago 24 commentsRead Article on func25.dev

HI version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

50% Positive

Analyzed from 669 words in the discussion.

Discussion (24 Comments)Read Original on HackerNews

woadwarrior01•about 2 hours ago

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

stevecoalbear•about 1 hour ago

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.

kbolino•13 minutes ago

RAII has the advantage that you can't forget to do it, but defer has the advantage that you can handle failure in ways other than panicking. Of course, in many cases (e.g. closing a file), there's generally not much you can do anyway even if you want to handle the error directly, but at least it's possible.

tialaramex•37 minutes ago

> no builtin list type

Wait, which thing do you mean by a "list type" ? A growable array type like Rust's Vec<T> or C++ std::vector<T> 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.

josephg•32 minutes ago

It’s not simple though. The language is simpler, sure. But you pay for language simplicity with program complexity. In go, you have to write and debug a lot more code.

I don’t mind spending a few extra weeks learning a more complex language if doing so saves me months of time down the track programming and debugging. That is an excellent investment.

mainde•15 minutes ago

I've not seen this in my experience tbh, the extra code that Go requires is ugly but not complex, the lack of ergonomics actively discourages "clever" solutions and, as a result of this, people tend to write the kind of straightforward code that doesn't end up needing lengthy programming or intense debugging.

At my workplace we've used many languages over the years (C#, Python, Go) and Go teams are the ones that by far do the least amount of yak shaving and have the most intelligible codebases.

breakingcups•about 1 hour ago

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.

programcookie•about 1 hour ago

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

pjmlp•37 minutes ago

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

never_inline•about 2 hours ago

Every language can't be rust.

neilalexander•about 2 hours ago

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

woadwarrior01•about 2 hours ago

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.

kbolino•about 1 hour ago

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.

stevecoalbear•about 1 hour ago

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.

tgv•about 1 hour ago

Nah... I like Go, but this is a hack. Wiktionary --not the ultimate authority, I know, but still-- defines to hack as: To make a quick code change to patch a computer program, often one that, while being effective, is inelegant or makes the program harder to maintain.

I could accept having an anonymous embedding as a kind of syntax directive. So many languages have had directives bolted on later, so that wouldn't be a deal breaker. But then it should be accessible in all code and (external) code should be able to implement behavior as well.

CamouflagedKiwi•about 2 hours ago

This feels like it should ideally be something public in the structs package so anyone can leverage it, not just a specially blessed internal thing for the sync package.

0x696C6961•about 1 hour ago

https://github.com/golang/go/issues/70811 Go moves slowly

ape4•22 minutes ago

I agree, its a nice piece of semantics to be added to a struct

wbl•44 minutes ago

You can very easily define one yourself.

kbolino•35 minutes ago

You can exploit the mechanism described in the article yourself, but it's already changed once in the past and is not part of any compatibility guarantee. As with structs.HostLayout, a blessed structs.NoCopy in the standard library could guarantee that it works forever. I think the bigger issue remains that it doesn't actually do anything in the language (but, then again, neither does structs.HostLayout--yet).