Go generics proposal moves to “likely accept”

I still remember when lack of generics and other common stuff was one of their main selling points in the beginning.

Someone here more familiar with the process could maybe summarize the next several steps and the timeline within which we might expect to get a "go" binary that can compile generics.

I don&#x27;t follow go language design very closely, but I&#x27;m curious about how this is going to be implemented, if it actually becomes accepted. What comes immediately to mind is boxing in Java (i.e. you can&#x27;t have a generic of a primitive).<p>If go implements generics on top of boxing like Java did, isn&#x27;t that basically just syntax sugar on top of `type T interface {}`?<p>For example, today I <i>can</i> write &quot;generic&quot; go code like so:<p><pre><code> type T interface {} func main() { ints := []T {1,2,3,4} intsum := Sum(ints, func(a T, b T) T { return a.(int) + b.(int) }) fmt.Println(intsum.(int)) } func Sum(s []T, add func(T, T) T) T { var sum = s[0] for i := 1; i &lt; len(s); i++ { sum = add(sum, s[i]) } return sum } </code></pre> The obvious issue is that the compiler defers type checking to runtime via the type assertions, so it&#x27;s quite possible to panic on unexpected input; but then again the go compiler doesn&#x27;t do anything against NPEs either. If the goal is to get the compiler to actually enforce generic types, wouldn&#x27;t it run into exactly the same sort of problems Java 1.5(?) did in the 90s, or the compiler performance complaints that you get from languages like Rust?

At this point, I fear that, with time, languages will end up adopting each and every paradigm, all of the syntactic sugars, and so on. I escaped perl for a reason.

It&#x27;s interesting how &quot;angle brackets vs. square brackets&quot; is such an issue for many Go programmers commenting on the generics proposals (including earlier ones).<p>Maybe it is just revealing where those programmers are coming from. Java and C++? Angle brackets! Eiffel, Scala? Square brackets!<p>Are there any parser considerations (like &lt;Foo &lt;Bar&gt;&gt; being an issue in C++, afair), or is it just taste (or Scala vs. C++ background)?

For those who are against generics (in general, or with Go specifically), what&#x27;s your particular rationale? I find myself unable to create an effective anti-generics argument in the same way I can make a pro-generics argument.<p>So far what I&#x27;ve seen here seem to be:<p>- You can already use interface{} for something similar to generics<p>- I don&#x27;t want the language to become more complex<p>- I can&#x27;t conceive of how it&#x27;ll be done efficiently&#x2F;effectively<p>- I don&#x27;t, personally, see the value of generics (i.e., it wouldn&#x27;t change any code I&#x27;ve ever written)

I&#x27;ve been writing Go for years and never came across a problem that made me want to have generics.<p>Anyone able to give me a simple example demonstrating why Go needs this?

Woot. looks like Go might jump decades from the 70s all the way up to mid 2000s language design.

Has Go&#x27;s interface{} single-handedly confused a generation of software developers, to the extent that they just couldn&#x27;t understand the language? Is this what happens when languages reach an escape velocity of userbase?