Are generics not essential in a modern industry language? How else can you avoid rewriting data structures? Void pointers and polymorphic parameters expect the programmer know the underlying type.
Given how successful Go has been without generics, it appears generics are not essential in a modern industry language.
I'm happy generics are coming to Go, but living without them hasn't been difficult. (Like the article author, I feel like I'm jumping through more ugly hoops due to lack of a proper enum type than I am due to lack of generics.)
We went through all this with Java in 2004. Lots of people saying "we don't need generics", then a few years later nobody can imagine writing code without them. You may not yet know what you're missing, but you will.
Flaws often represent design tradeoffs. Rust's lengthy compile times are a tradeoff for a highly sophisticated type system, where Go made the opposite choice (a simple type system for fast compiles). As a web engineer I prefer the latter for a rapid development/debug cycle.
The problem with void pointers is that if you make a mistake, you get undefined behavior. If you make a bad cast in Java, Go, or C#, instead, it fails. You get nil, you get an exception, or you get a panic, depending on how you do the cast, and which language you're using. None of these result in undefined behavior.
If you look at Java and C#, neither had generics either. You used casts, just like Go. It's safe, because the casts are safe (unlike void pointers). People started using Java and C# anyway, even though they didn't have generics.
Java then added generics in J2SE 5.0, which came out in 2004, when Java was nearly 10 years old. A year later, in 2005, C# added generics as well, with the release of C# 2.0.
Given that Go is about 11 years old now, it doesn't seem so out of place.
C# had generics already, they just weren't fully baked for 1.0 release and they decided to postpone them instead of delaying the .NET 1.0 release.
That is one of the reasons why the CLR already had most of the infrastrucure for proper handling of generic code instead of being a compiler only sugar.
It really depends on the types of programs you are writing. A lot of CRUD style "microservices" being built these days don't ever construct any complex in-memory structures, instead deferring that to databases etc.
Also many system-ish programs, CLIs and the like also don't really need complex structures or benefit from authoring them + the algorithms that traverse them in a program-specific way.
That said, I'm not a fan of Go but generics are far from the only reason why I'm not a fan and it could probably exist as a somewhat useful language without them indefinitely.
There are times when you wish you had them, but they are typically conversion type functions. Those just don't happen that often for a lot of applications.
It's easy to show some contrived add func, and how you need one of every single number type in Go. But in practice, people rarely ever need such a function.
I'm happy generics are coming to Go, but living without them hasn't been difficult. (Like the article author, I feel like I'm jumping through more ugly hoops due to lack of a proper enum type than I am due to lack of generics.)