They did. That is how they learned arenas are the wrong abstraction and why the project is now looking at memory regions instead.

▲

pjmlp 2 days ago | parent [-]

Doesn't look like it, in the end it will be like generics, half way there.

▲

9rx 2 days ago | parent [-]

Looks like the opposite of generics. Go's generics story is intrinsically linked to Java. It was the Java team that told the Go team to not implement generics until they were perfectly satisfied with the solution, and it was the same guy who ultimately designed both Java's and Go's generics. You cannot take a closer look at Java's generics than that.

▲

pjmlp 2 days ago | parent [-]

Except the Go's implementation is not as capable as Java's one.

Phil Walder delivered a design within Go's team goals.

Java team has told nothing to Go's team, they have acknowldeged their bias anti-generics.

". They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

▲

9rx 2 days ago | parent [-]

> Except the Go's implementation is not as capable as Java's one.

I have no idea what you think is on the other side of that exception. Please clarify.

▲

pjmlp 2 days ago | parent [-]

Have a read https://dev.to/leapcell/why-gos-generics-might-be-worse-than...

	▲	9rx 2 days ago \| parent [-]
		No need to outsource words. If I wanted to converse with Leapcell, I'd go to him directly. Especially when it doesn't even begin to address the concern. The disconnect is not in where Go generics are limited, but where you find the exception. There is nothing that I can find to "except against". What was "Except" in reference to?