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

21–30 of 82 posts

Re: How Go detects struct copies with sync.noCopy

#21

Post by kbolino »

wbl wrote: post #18
CamouflagedKiwi wrote: post #6

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.

You can very easily define one yourself.

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

Re: How Go detects struct copies with sync.noCopy

#22

Post by josephg »

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.

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.

Re: How Go detects struct copies with sync.noCopy

#24

Post by [deleted] »

pjmlp wrote: post #19
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.

[deleted]

Re: How Go detects struct copies with sync.noCopy

#25

Post by mainde »

josephg wrote: post #22
stevecoalbear wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

Re: How Go detects struct copies with sync.noCopy

#26

Post by kbolino »

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.

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.

Re: How Go detects struct copies with sync.noCopy

#27

Post by bewareofscams »

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.

More like Pike's design philosophy was "let's do some half-thought things and sabotage any current or future improvement proposal for decades to come, while gaslighting everyone that Go is good because Google and because people can't see difference between 'systems' and 'system' programming".

Re: How Go detects struct copies with sync.noCopy

#28

Post by bewareofscams »

kbolino wrote: post #26
stevecoalbear wrote: post #13

Earlier quoted context omitted.

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.

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.

Rust can handle that with RAII without panicking just fine. And not only Rust..

Re: How Go detects struct copies with sync.noCopy

#30

Post by meerita »

I spoke with Aliaksandr Valialkin (author of noCopy) and he gave me his reasons:

- https://x.com/valyala/status/2088638160242683954

He also gave an answer of what he would change now: https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...

It seems he's not happy anymore with the new direction of Go because they're implementing things from other languages.

Post reply on HN