> noCopy is a special marker for types that must not be copied after their first use.<p>if it looks like a hack, walks like a hack, and quacks like a hack...
[delayed]
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..<p>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.
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...<p>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<p>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 ?<p>Or do you mean a linked list type akin to C++ std::list or std::forward_list or Rust's std::collections::LinkedList ?<p>"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.
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.<p>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.<p>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.
It's hard and annoying to read though. Constantly beating around the bush, circling the point but not stating it, not unlike LLM prose.
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.
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.<p>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.<p>Of course, you can actively restrict yourself to standard go, but not needing to do that was the whole point.
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.<p>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.<p>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 <i>written</i> a couple of such things but they're all internal code.
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.
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".
So, like <a href="https://doc.rust-lang.org/std/marker/index.html" rel="nofollow">https://doc.rust-lang.org/std/marker/index.html</a>?
The whole Go design philosophy in one sentence, that is what one gets by refusing to adopt modern language practices.
Every language can't be rust.
It's not really a hack. It's a hint to a static analyser, that's all.
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.
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.<p>The real hack to me is that <i>anything</i> which simply has Lock() and Unlock() methods is considered uncopyable.
Coming from Rust anyway (can't say I'm familiar with Go), nothing about having it as a trait would pollute the method set, traits don't have to have methods (e.g. pin, unpin, send, sync, etc.). Yes a zero length field can be metadata and this is a style complaint but a struct's fields are traditionally its data and the type is its metadata, I feel like it's harmful to mix these two as I at least wouldn't generally look at fields to find metadata for the struct.
Interfaces in Go (the closest equivalent to traits in Rust) don't have to have methods either, but they are structurally typed. This is like "static duck typing" if you will. So an interface with no methods is implemented by every type in the language (indeed, this became such a useful pattern that the name "any" was reserved for it in Go 1.18).<p>Marker interfaces can exist in Go, but here they are another kind of hack. They must define at least one method (which doesn't have to be public), though that method is never actually meant to be called.
I'm only peripherally familiar with Go. IIRC, Rust defaults to move-only structs with the option to make them copyable with the Copy trait. Swift defaults to copyable structs (like Go), but has a ~Copyable generic type constraint to make them move-only.
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.<p>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.
Nah... I like Go, but this is a hack. Wiktionary --not the ultimate authority, I know, but still-- defines <i>to hack</i> 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.<p>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.