4 ms·

I think that's an inaccurate/misleading framing: the typical criticism is that it has seemed to ignore innovations from elsewhere, there's no suggestion that it

by dbaupp 9y ago

I think that's an inaccurate/misleading framing: the typical criticism is that it has seemed to ignore innovations from elsewhere, there's no suggestion that it needs to reinvent them. For instance, people consider generics a solved problem as there's numerous schemes invented by other languages, and critics think one of them should be able to work for Go.

geodel 9y ago
Is Swift scheme same as Rust which is same as Java which is similar to C++? If not then it seems to me language developers decided to use an approach what suited their purpose.
- dbaupp 9y ago
  No, they're all different, which is my point: there's a variety of schemes that all have well-understood pluses and minus, meaning new languages don't have to do the exploration themselves.
ngrilly 9y ago
Yes, but Go has specificities that make difficult to directly use the scheme used by other languages: Go is AOT compiled (we can't use C# generics), Go favors compilation speed (we can't use C++ template), Go lets the developer control memory layout with arrays and structs (we can't use OCaml generics), etc. Of course, Go should get inspiration from other languages, but adding generics is not easy as simply transposing another language implementation. There are multiple detailed proposals in the bug tracker that have failed for multiple reasons.
- dbaupp 9y ago
  Swift has essentially all the same constraints, and fretting about compilation speed with the C++ approach are hard to stomach given one of the widely-used replacement is equivalent: manually copy-pasting code, instead of letting the compiler do it. In any case, the truth of the complaint about generics isn't actually relevant here: the rebuttal is to "people complain about Go not reinventing enough", and they don't, as they (truthfully or otherwise) think it is ignoring already researched and widely-implemented solutions to the problem and complain about this (that is, the complaint is "uninventing", not "not enough reinventing").
  - ngrilly 9y ago
    I didn't mention Swift and I should have. I agree it's close enough to Go to provide useful inspiration. But even Swift implementation of generics has its issues and tradeoffs. Look for example at this thread about "Compile-time generic specialization" in Swift: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031466.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo... Repeating that Go ignores "already researched and widely-implemented solutions" is getting old, really. Would you say that OCaml doesn't have shared memory multicore parallelism because it ignores already researched and widely-implemented solutions??? Would you say that Haskell garbage collector causes long runtime pauses because it ignores already researched and widely-implemented solutions??? The truth is that solving that kind of things is a lot more complex than just copy-paste the code from another language.
    - dbaupp 9y ago
      I'm... intimately familiar with generics in Swift. :) Like all systems it has trade-offs, but the decision it makes line up with the decisions you said Go wanted to also make. In any case, that specific concern doesn't apply to Go, since it doesn't have overloading. > Repeating that Go ignores "already researched and widely-implemented solutions" is getting old, really Sure, but that still isn't the point of this discussion: it's not what people should be doing, or the underlying truth, it's what people are doing in practice and they are complaining about the Go team seemingly ignoring the past 40 years of programming language development, not complaining that they're not inventive enough.
      - ngrilly 9y ago
        You're right about the issue I mentioned which is irrelevant since there is no overloading in Go. Thanks for pointing it out. I didn't know you worked on Rust and now on Swift :-) What strategy does Swift use to compile a generic function or method? Does it generate only one polymorphic version of the code, or multiple specialized versions for each expected parameter types (often called code specialization or monomorphization)?
- pjmlp 9y ago
  There are also CLU, Ada, Modula-2, Modula-3, Eiffel, Sather, BETA as possible inspirations for implementing generics, all the way back to 1976 (CLU). As for C#, people keep forgetting .NET always had a JIT/AOT compiler since version 1.0. Just because not everyone bothers to sign their applications and call NGEN at installation time, it doesn't mean it isn't there. Also Mono always supported AOT compilation, it is the way Xamarin works on iOS and the deployment story on Windows Store since it was introduced on Windows 8.
  - ngrilly 9y ago
    I remember Mono with AOT compilation had some limitations regarding generics in the past, but maybe this has been solved since then.
    - pjmlp 9y ago
      Yes Mono has some limitations, but it isn't 100% like the iOS Xamarin compiler. http://www.mono-project.com/docs/advanced/aot/ http://www.mono-project.com/docs/advanced/aot/ In any case, a limited form of generics is better than not having any at all. They don't need to provide a turing complete implementation of generics, even a basic one like CLU had would already be an improvement. Using go generate feels like the old days, writing generic code in C and C++ with pre-processor tricks.
      - ngrilly 9y ago
        I agree. I hope the Go team will tackle this issue, when they are done with dependency management.

by dbaupp 9y ago

geodel 9y ago

Is Swift scheme same as Rust which is same as Java which is similar to C++? If not then it seems to me language developers decided to use an approach what suited their purpose.

dbaupp 9y ago
No, they're all different, which is my point: there's a variety of schemes that all have well-understood pluses and minus, meaning new languages don't have to do the exploration themselves.

ngrilly 9y ago

Yes, but Go has specificities that make difficult to directly use the scheme used by other languages: Go is AOT compiled (we can't use C# generics), Go favors compilation speed (we can't use C++ template), Go lets the developer control memory layout with arrays and structs (we can't use OCaml generics), etc. Of course, Go should get inspiration from other languages, but adding generics is not easy as simply transposing another language implementation. There are multiple detailed proposals in the bug tracker that have failed for multiple reasons.

dbaupp 9y ago
Swift has essentially all the same constraints, and fretting about compilation speed with the C++ approach are hard to stomach given one of the widely-used replacement is equivalent: manually copy-pasting code, instead of letting the compiler do it. In any case, the truth of the complaint about generics isn't actually relevant here: the rebuttal is to "people complain about Go not reinventing enough", and they don't, as they (truthfully or otherwise) think it is ignoring already researched and widely-implemented solutions to the problem and complain about this (that is, the complaint is "uninventing", not "not enough reinventing").
- ngrilly 9y ago
  I didn't mention Swift and I should have. I agree it's close enough to Go to provide useful inspiration. But even Swift implementation of generics has its issues and tradeoffs. Look for example at this thread about "Compile-time generic specialization" in Swift: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031466.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo... Repeating that Go ignores "already researched and widely-implemented solutions" is getting old, really. Would you say that OCaml doesn't have shared memory multicore parallelism because it ignores already researched and widely-implemented solutions??? Would you say that Haskell garbage collector causes long runtime pauses because it ignores already researched and widely-implemented solutions??? The truth is that solving that kind of things is a lot more complex than just copy-paste the code from another language.
  - dbaupp 9y ago
    I'm... intimately familiar with generics in Swift. :) Like all systems it has trade-offs, but the decision it makes line up with the decisions you said Go wanted to also make. In any case, that specific concern doesn't apply to Go, since it doesn't have overloading. > Repeating that Go ignores "already researched and widely-implemented solutions" is getting old, really Sure, but that still isn't the point of this discussion: it's not what people should be doing, or the underlying truth, it's what people are doing in practice and they are complaining about the Go team seemingly ignoring the past 40 years of programming language development, not complaining that they're not inventive enough.
    - ngrilly 9y ago
      You're right about the issue I mentioned which is irrelevant since there is no overloading in Go. Thanks for pointing it out. I didn't know you worked on Rust and now on Swift :-) What strategy does Swift use to compile a generic function or method? Does it generate only one polymorphic version of the code, or multiple specialized versions for each expected parameter types (often called code specialization or monomorphization)?
pjmlp 9y ago
There are also CLU, Ada, Modula-2, Modula-3, Eiffel, Sather, BETA as possible inspirations for implementing generics, all the way back to 1976 (CLU). As for C#, people keep forgetting .NET always had a JIT/AOT compiler since version 1.0. Just because not everyone bothers to sign their applications and call NGEN at installation time, it doesn't mean it isn't there. Also Mono always supported AOT compilation, it is the way Xamarin works on iOS and the deployment story on Windows Store since it was introduced on Windows 8.
- ngrilly 9y ago
  I remember Mono with AOT compilation had some limitations regarding generics in the past, but maybe this has been solved since then.
  - pjmlp 9y ago
    Yes Mono has some limitations, but it isn't 100% like the iOS Xamarin compiler. http://www.mono-project.com/docs/advanced/aot/ http://www.mono-project.com/docs/advanced/aot/ In any case, a limited form of generics is better than not having any at all. They don't need to provide a turing complete implementation of generics, even a basic one like CLU had would already be an improvement. Using go generate feels like the old days, writing generic code in C and C++ with pre-processor tricks.
    - ngrilly 9y ago
      I agree. I hope the Go team will tackle this issue, when they are done with dependency management.