I think you hit the nail on the head, Go already uses a 90% solution in many
areas, and that is why it is both simple and useful.
In the case of generics programming though, it is 0% (unless you count
interface{} as being generic - I don’t)
Java went for over a decade without generics, and many fought to exclude it
even then, still there were a lot of proposals, and type-erasure was chosen for
the least impact on the language and stdlibs, which left some things to runtime
checking. I would argue the Java solution is 90% generics. It doesn’t do
everything, and some things are difficult but doable (like generic arrays).
It might be constructive for all of the generics proponents for Go to go back
and read the Java language developers/arguments on generics.
This may be very helpful as well
https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics
> On Sep 14, 2018, at 12:16 PM, Ian Lance Taylor <i...@golang.org> wrote:
>
> On Fri, Sep 14, 2018 at 3:32 AM, alanfo <alan.f...@gmail.com> wrote:
>>
>> I was then brought back to reality by this post by Robert Engels in the
>> 'Generics - Why contracts?' thread:
>>
>> "As I’ve said elsewhere, a SIMPLE to use and understand solution that covers
>> 90% is better than a complex one to cover 100% IMO, and fits in well with
>> the rest of Go design. Go leaves out a lot - and it's a good choice."
>
> I've seen several people express this idea in different ways. I want
> to challenge it.
>
> I agree that simple is essential. That is not in dispute. If the
> current design draft is too complex, we can not adopt it as is.
>
> However, it does not follow that a 90% solution, whatever that is
> taken to mean, is acceptable.
>
> A 90% solution is frustrating, in exactly the same way that some
> people find the fact that Go currently lacks generics to be
> frustrating. That is, for generic programming, Go is already a 90%
> solution. Some people find the missing 10% to be annoying,
> frustrating, and confusing. This will continue to happen if we add
> another 90% solution to the problem.
>
> A 90% solution is complex, because by definition it means that there
> are special cases, complex cases, that do not work as expected.
> Everybody who learns Go has to learn not only how to implement the
> 90%, they also have to learn where that 90% stops.
>
> A 90% solution is not orthogonal, by definition. Go is in some ways
> not very orthogonal, but it is orthogonal in this way: all concepts in
> Go that can be meaningfully used together, work together as one would
> expect them to. There are no missing elements.
>
> When considering changes to the Go language, please do not settle for
> a 90% solution.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
