Live data from Hacker News

How Go detects struct copies with sync.noCopy

func25.dev

81–82 of 82 posts

Re: How Go detects struct copies with sync.noCopy

#81

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.

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

It doesn't matter which one you mean, because Go has neither of them.

Re: How Go detects struct copies with sync.noCopy

#82
post #64
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.

This is good for Go ecosystem!
Post reply on HN