4 ms·

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 repl

by 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)?
    - dbaupp 9y ago
      One polymorphic version, like OCaml or Haskell, not specializing like C++ or Rust. The compiler can and does specialize functions as an optimization, but that's not necessary nor part of the semantic model.
      - ngrilly 9y ago
        I always thought that generating one polymorphic version would be a better fit for Go than generating multiple specialized versions. It's interesting that Swift adopted this approach and confirms what you said earlier about Swift having essentially the same constraints as Go and being a good source of inspiration of Go. What's the status of Swift on Linux, to write web services and connect to databases?
        dbaupp 9y ago
        There's lots of testing for Swift on Linux (e.g. every pull request runs tests on macOS and Linux), and Apple recently announced https://github.com/apple/swift-nio https://github.com/apple/swift-nio which seems to have been very well received, e.g. the Vapor framework is completely switching to it for Vapor 3.
        ngrilly 9y ago
        Thanks for the link. Does Swift provide something similar to goroutines?
- ernst_klim 9y ago
  >OCaml doesn't have shared memory multicore parallelism because it ignores already researched and widely-implemented solutions? OCaml people definitely not ignore them, they are carefully investigating existing code and elaborating modern and efficient solution [1](unlike Go, which is too opinionated). [1] https://github.com/ocamllabs/ocaml-multicore/wiki/Memory-model https://github.com/ocamllabs/ocaml-multicore/wiki/Memory-mod...
  - ngrilly 9y ago
    I'm aware of the ongoing work to enable multicore parallelism in OCaml. It's the reason why I mentioned OCaml in my comment. My comment was rhetoric. My apologies if it was not clear. That said, I don't see the link between the work done on OCaml multicore parallelism and Go "being too opinionated"... If I follow you, Go people, unlike OCaml people, are "too opinionated", and don't "carefully investigate existing code" and don't "elaborate modern and efficient code". Do you realize how arrogant (and a bit ridiculous) this sounds?

by dbaupp 9y ago

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)?
  - dbaupp 9y ago
    One polymorphic version, like OCaml or Haskell, not specializing like C++ or Rust. The compiler can and does specialize functions as an optimization, but that's not necessary nor part of the semantic model.
    - ngrilly 9y ago
      I always thought that generating one polymorphic version would be a better fit for Go than generating multiple specialized versions. It's interesting that Swift adopted this approach and confirms what you said earlier about Swift having essentially the same constraints as Go and being a good source of inspiration of Go. What's the status of Swift on Linux, to write web services and connect to databases?
      - dbaupp 9y ago
        There's lots of testing for Swift on Linux (e.g. every pull request runs tests on macOS and Linux), and Apple recently announced https://github.com/apple/swift-nio https://github.com/apple/swift-nio which seems to have been very well received, e.g. the Vapor framework is completely switching to it for Vapor 3.
        ngrilly 9y ago
        Thanks for the link. Does Swift provide something similar to goroutines?
ernst_klim 9y ago
>OCaml doesn't have shared memory multicore parallelism because it ignores already researched and widely-implemented solutions? OCaml people definitely not ignore them, they are carefully investigating existing code and elaborating modern and efficient solution [1](unlike Go, which is too opinionated). [1] https://github.com/ocamllabs/ocaml-multicore/wiki/Memory-model https://github.com/ocamllabs/ocaml-multicore/wiki/Memory-mod...
- ngrilly 9y ago
  I'm aware of the ongoing work to enable multicore parallelism in OCaml. It's the reason why I mentioned OCaml in my comment. My comment was rhetoric. My apologies if it was not clear. That said, I don't see the link between the work done on OCaml multicore parallelism and Go "being too opinionated"... If I follow you, Go people, unlike OCaml people, are "too opinionated", and don't "carefully investigate existing code" and don't "elaborate modern and efficient code". Do you realize how arrogant (and a bit ridiculous) this sounds?