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.
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."
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?
My understanding is that that arena allows you to allocate memory segments, but you can't do much with it, you can't allocate var or object on it like in C++ for example, so its almost useless.
You certainly can, as they were designed as JNI replacement, with the goal to fully support the C ABI of the host platform.
You can either do the whole boilerplate manually with Panama set of APIs, or write a C header file and let jextract do the work of boilerplate generation.
