Which leads to writing the same code repeatedly--because trying to wedge in reusability via insufficiently expressive structural typing is entertaining but often fruitless--and making the user wonder why they didn't just use something modern (setting aside stuff like Scala, even C++ can do channels, and past that the reasons for Go start vanishing real quick).
I write go 40 hours a week and have been for over a year. There's been only a couple times I wanted generics and those are structures I haven't actually needed to reuse yet. I'm not guessing about not being generics much.
Edit
That being said, go is not for all projects. Some projects need a lot of generics. Don't use go for that.
Um, I've written Go. Nontrivial amounts, as it happens. In doing so, I recognized that I was regularly forced to write worse code in the pursuit of doing things idiomatically because I lacked the semantic richness of C++, let alone Scala. And this worse-is-better attitude of the Go community gives me a dim view of its future--and between its junk GC and its completely pedestrian semantic and syntactic propositions I already had a dim view of its present.
If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required. There are no two ways around it.
It sounds like you were forced to write/maintain some Go code and are basing your opinion on that, an opinion heavily colored by the quality of the original code and your annoyance at your employer for making you work in something other than your preferred language(s).
It's even possible the software you were tasked with writing/maintaining was a bad fit for Go. I tried to mention that in my previous response. Such things certainly exist, and most Go enthusiasts will be more than willing to admit it.
However, saying you can't write reusable, future-facing code without generics is preposterous. To refute you, all I have to do is point you at the Go standard library. A huge body of code whose purpose is purely reuse, and not a generic to be found.
Or perhaps we could look at the thousands of reusable go packages found on godoc.org.
You don't like Go. That's a perfectly acceptable stance to take. But I don't think you've really given it a fair shake, either.
> If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required.
You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained.
> And this worse-is-better attitude of the Go community gives me a dim view of its future
The Go community actively embraces Worse-Is-Better. If your opinions are well formed enough that you know you want nothing to do with it, then what is your point exactly? Yeah, you hate Go because you hate Worst-Is-Better. So what?
> You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained.
You're right. Sorry. You can do it by enacting a fair approximation of stapling your eyelids to your hairline. I apologize for not being exhaustive.
> The Go community actively embraces Worse-Is-Better. If your opinions are well formed enough that you know you want nothing to do with it, then what is your point exactly?
That I've had more than one long night dealing with an inherited Go application and it sucks and its developers should feel bad.
(OK, the last is mostly facetious. If they can't be bothered to use modern tooling, though, they should be tasked with maintaining their own crap...)
Go is a language for people who write servers. It is really really good for those uses. Look at Docker, etcd, Kubernetes, Juju, Cloudflare, Soundcloud ...
And probably a ton that are internal to a company and not really exposed as a user-facing "Go Application™" (like the stuff behind google's downloads service, some of youtube's metadata processes, etc etc).
I think the fact that early on in Go's life someone called it a "systems language" really confused a lot of people. It's not a systems language. It's just a language. The channels, goroutines, and standard library happen to be really useful when writing networked servers.
