Constraints in Go

i have been writing Go exclusively for 5+ years and to this day i use generics only in a dedicated library that works with arrays(slices in Go world) and provides basic functionality like pop, push, shift, reverse, filter and so on.

Other than that, generics have not really solved an actual problem for me in the real world. Nice to have, but too mush fuss about nothing relevant.

I sometimes wonder if they should have implemented generics. On the one hand you had a group of people using go as it was and presumably mostly happy with the lack of generics. On the other side you have people (like me) complaining about the lack of generics but who were unlikely to use the language once they were added.

It's very subjective but my gut feeling is they probably didn't expand their community much by adding generics to the language.

Having recently had to work on a Go project for the first time, I think I agree with you here. I'd tried Go a little bit when it came out, had zero interest in what it offered, and then when I was asked to work on this project a couple months ago I thought it would be fun to try it out again since I had read the language had improved.

No, it still feels like programming with a blindfold on and one hand tied behind my back. I truly don't get it. I've worked with a lot of languages and paradigms, am not a zealot by any means. Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing unreadable boilerplate to work around the bad language design. I know I must be missing something because some people much smarter than me like this language, but... what is it?

> I see even experienced Go programmers constantly wasting time writing unreadable boilerplate

if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.