How Go detects struct copies with sync.noCopy(func25.dev) |
How Go detects struct copies with sync.noCopy(func25.dev) |
if it looks like a hack, walks like a hack, and quacks like a hack...
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.
This was Go's design philosophy until Rob Pike left - to do the simple thing simply and not try to be clever about it.
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 ?
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 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.
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.
Also, AFAIK, they only leverage standard language behaviour and are not a hardcoded special case.
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.
- 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.
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.
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.
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.
The real hack to me is that anything which simply has Lock() and Unlock() methods is considered uncopyable.
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.
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.