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

61–70 of 82 posts

Re: How Go detects struct copies with sync.noCopy

#61

Post by a2ff6eeb0 »

insanitybit wrote: post #56
a2ff6eeb0 wrote: post #55

Earlier quoted context omitted.

What's "this", and what does the user need to learn to make use of it?

noCopy. In order to understand it, they have to learn that this is enforced only by `go vet` and that the marker relies on everything described in the `2. How go vet and noCopy work` section of this article. Of course, they don't have to learn anything other than "use `go vet`, it's what enforces this" to use it . But that's true of almost anything?

It's the difference between trying to learn the language and trying to learn the implementation details of a library. Is the kind of crazy hack that Rust std uses to prevent TOCTOU attacks with symlinks a language complexity issue or not?

I suppose you can add features to the language and then tell people to avoid learning them.

Re: How Go detects struct copies with sync.noCopy

#62

Post by insanitybit »

a2ff6eeb0 wrote: post #61
insanitybit wrote: post #56

Earlier quoted context omitted.

noCopy. In order to understand it, they have to learn that this is enforced only by `go vet` and that the marker relies on everything described in the `2. How go vet and noCopy work` section of this article. Of course, they don't have to learn anything other than "use `go vet`, it's what enforces this" to use it . But that's true of almost anything?

It's the difference between trying to learn the language and trying to learn the implementation details of a library. Is the kind of crazy hack that Rust std uses to prevent TOCTOU attacks with symlinks a language complexity issue or not? I suppose you can add features to the language and then tell people to avoid learning them.

> Is the kind of crazy hack that Rust std uses to prevent TOCTOU attacks with symlinks a language complexity issue or not?

I have no clue what you're talking about and I doubt that it's relevant.

The claim was made that this is "simple". It doesn't feel simple to me. I'm asking about the criteria used and how this fits into that to justify the "simple" claim.

The implementation details of this construct are implementation details of the language.

Re: How Go detects struct copies with sync.noCopy

#63

Post by a2ff6eeb0 »

insanitybit wrote: post #62
a2ff6eeb0 wrote: post #61

Earlier quoted context omitted.

It's the difference between trying to learn the language and trying to learn the implementation details of a library. Is the kind of crazy hack that Rust std uses to prevent TOCTOU attacks with symlinks a language complexity issue or not? I suppose you can add features to the language and then tell people to avoid learning them.

> Is the kind of crazy hack that Rust std uses to prevent TOCTOU attacks with symlinks a language complexity issue or not? I have no clue what you're talking about and I doubt that it's relevant. The claim was made that this is "simple". It doesn't feel simple to me. I'm asking about the criteria used and how this fits into that to justify the "simple" claim. The implementation details of this construct are implement…

The answer is that the implementation details are abstracted away by the library, the same way that the implementation details of Rust std::file access are abstracted away. That means that while the implementation may not be beautiful, the language doen't need to expand in order to accommodate 20 uses of the feature.

The language could be expanded to support this, but then every user either need to ignore a part of the language, or learn it. Oddball hacks in the internals of a library don't affect users of the library. This article is a deep dive into how the internals of a library happen to work on this iteration of Go.

Re: How Go detects struct copies with sync.noCopy

#64

Post by zmj »

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'm coming to think there's a selection effect here. The people that want to write complex code feel unsupported by Go and avoid it.

Re: How Go detects struct copies with sync.noCopy

#65

Post by tredre3 »

wasmperson wrote: post #57
kbolino wrote: post #26

Earlier quoted context omitted.

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.

> (e.g. closing a file), there's generally not much you can do anyway If closing a file fails then you treat it the same as how you would treat a write failure: int err = 1; FILE *f = fopen("whatever.txt", "w"); if(f){ if(5 == fwrite("Hello", 1, 5, f)) err = 0; if(0 != fclose(f)) err = 1; } return err; Code which writes to files and doesn't check for errors on close is subtly incorrect, although my understanding is t…

Not that it matters, but fclose() doesn't happen in the kernel, so the kernel devs can't do anything about it. All libcs have essentially the same implementation:

- is fp NULL or already already closed? return error

- call fflush() and return error if it fails (fflush also happens in userland, it does a seek() then a write() of the userland buffer)

- call close() and return error if it fails

close() follows essentially the same process inside the kernel: check fd is valid, call flush() (this time truly to disk), close it.

Re: How Go detects struct copies with sync.noCopy

#66

Post by YesThatTom2 »

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.

So… what language do you use?

No (useful) language is simple. Claiming go is not simple without naming a language for comparison is a party foul.

Re: How Go detects struct copies with sync.noCopy

#67

Post by 0x696C6961 »

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.

If this was true, why did they add generics?

Re: How Go detects struct copies with sync.noCopy

#68

Post by josephg »

YesThatTom2 wrote: post #66
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.

So… what language do you use? No (useful) language is simple. Claiming go is not simple without naming a language for comparison is a party foul.

Rust. Typescript. More complex languages let me write shorter, simpler programs.

I don't write haskell, but I understand the appeal. Haskell is this philosophy taken to its natural conclusion.

Re: How Go detects struct copies with sync.noCopy

#69

Post by josephg »

zmj wrote: post #64
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'm coming to think there's a selection effect here. The people that want to write complex code feel unsupported by Go and avoid it.

Yep. I'd much rather 50 lines of rust than 100 lines of go. I find shorter programs to be generally easier to read and more likely to be correct.

Re: How Go detects struct copies with sync.noCopy

#70

Post by pjmlp »

0x696C6961 wrote: post #67
pjmlp wrote: post #19

Earlier quoted context omitted.

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

If this was true, why did they add generics?

The generics that they eventually added, because of programming language market pressure, Kubernetes had an whole code generation gizmo to work around it, are a clunky implementation versus what could have been done if done from the get go.
Post reply on HN