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

31–40 of 82 posts

Re: How Go detects struct copies with sync.noCopy

#31

Post by porridgeraisin »

mainde wrote: post #25
josephg wrote: post #22

Earlier quoted context omitted.

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 f…

Yep. But with go 1.22/1.23 and later this is changing. It's becoming a hell of a mess like many other big languages. I think it was two consecutive releases back in 2024 where they added for ... range and generics? That was when I gave up.

Sad that the one language that managed to occupy that nice spot in language design space for an extended period of time, isn't doing so anymore.

Of course, you can actively restrict yourself to standard go, but not needing to do that was the whole point.

Re: How Go detects struct copies with sync.noCopy

#33

Post by a2ff6eeb0 »

insanitybit wrote: post #15
stevecoalbear wrote: post #12

Earlier quoted context omitted.

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

How much additional complexity do users need to be aware of when writing new code because of the way this was implemented? Adding new features makes the language bigger, for something that Claude tells me is used 20 times in total in the entire Go codebase.

Re: How Go detects struct copies with sync.noCopy

#34

Post by fithisux »

meerita wrote: post #30

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.

He's right. Countering the performance advantage of Rust and keeping its simplicity would be higher priority.

Re: How Go detects struct copies with sync.noCopy

#36

Post by shakow »

saturn_vk wrote: post #35
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...

So, like https://doc.rust-lang.org/std/marker/index.html ?

Those are integrated in the compiler and don't need a second tool to work.

Also, AFAIK, they only leverage standard language behaviour and are not a hardcoded special case.

Re: How Go detects struct copies with sync.noCopy

#37

Post by jerf »

porridgeraisin wrote: post #31
mainde wrote: post #25

Earlier quoted context omitted.

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 f…

Yep. But with go 1.22/1.23 and later this is changing. It's becoming a hell of a mess like many other big languages. I think it was two consecutive releases back in 2024 where they added for ... range and generics? That was when I gave up. Sad that the one language that managed to occupy that nice spot in language design space for an extended period of time, isn't doing so anymore. Of course, you can actively restric…

The support for iterators is relatively new, though being limited to data structures that an iterator makes sense on, they don't exactly get around in the language and pollute everything everywhere.

The support for generics is years old and I don't believe anyone who claims it has ruined the language. I've barely encountered them in the wild and I've never encountered the thing people were really worried about in the wild where something has 4 generic parameters that are themselves complicated generic parameters of other things. If you're encountering that, it is either some one-off library I've never encountered, or it's because you or your team are writing it, to which the solution is, stop that.

I'm not even sure I've yet seen a "generic" in a library in Go that isn't simply straight up a generic data structure, the core use case for generics. I've written a couple of such things but they're all internal code.

Re: How Go detects struct copies with sync.noCopy

#38

Post by throw-the-towel »

mainde wrote: post #25
josephg wrote: post #22

Earlier quoted context omitted.

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 f…

It's hard and annoying to read though. Constantly beating around the bush, circling the point but not stating it, not unlike LLM prose.

Re: How Go detects struct copies with sync.noCopy

#39

Post by MartinodF »

mainde wrote: post #25
josephg wrote: post #22

Earlier quoted context omitted.

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 f…

100% also our experience. We have an internal CLI which has grown to almost half a million lines of Go, mostly contributed to by first-time gophers (and agents nowadays), and with relatively little work spent on making sure the core entities and interfaces encourage doing the right thing, the entire codebase is still surprisingly readable and free of unexpected behaviors.

Re: How Go detects struct copies with sync.noCopy

#40

Post by Georgelemental »

shakow wrote: post #36
saturn_vk wrote: post #35

Earlier quoted context omitted.

So, like https://doc.rust-lang.org/std/marker/index.html ?

Those are integrated in the compiler and don't need a second tool to work. Also, AFAIK, they only leverage standard language behaviour and are not a hardcoded special case.

Nearly everything in that module relies on at least some hardcoded compiler magic (what Rust calls "language items", with a `#[lang = "..."]` attribute on the definition). The only exception is `Send`—and even that is still an auto trait, which on stable Rust can only be defined by the standard library. (There are plans to also remove the lang-item status from `Unpin`.)
Post reply on HN