It is not essential, but without it, it is much more cumbersome. I programmed it with Java so I know it can be done but I would not choose a language without it if I could.
It is absolutely necessary nowadays, yes. Our applications are often more complex than what people did in Java 1.5, Cobol, or C, and definitely need to be developed at a faster pace.
This thread was in the context of go generics, which generally means go 1.18, when user defined generics were added to the language. Go always had support for a minimal number of containers, I've never rolled my own when working in the language.
Go had special compiler support for slices, maps, and channels before then, and they got used as the default containers for everything.
Using those was annoying when you needed to do the same thing to, say, a slice of strings and a slice of ints, but if you aren't using a generic heavy style, it actually comes up surprisingly rarely. And, if I'm being honest, I'd consider most of the uses of generics I've seen the average enterprise dev use to be mistakes.
no inheritance but there are interfaces to be able to provide alternate implementations. Similar to traits in Rust. If it quacks like a duck, has feathers like a duck, swims like a duck…
Go just assumes if you satisfy the interface, you’re good.
maybe, it is just some effort for someone who coded in classic OO for last 20 years to wrap head around this new concept fast and judge if it will satisfy all/most use cases.
