4 ms·

That's precisely it. We don't want to "bolt on" any feature to Go. The features should interact nicely. Language design is all about tradeoffs like this. There

by enneff 11y ago

That's precisely it. We don't want to "bolt on" any feature to Go. The features should interact nicely. Language design is all about tradeoffs like this. There's a lot of information out there about Go's design process and goals. If you read up on it (and the proposals that are the subject of this thread) you can see why parametric polymorphism isn't something that you can just shove into the language.

Ericson2314 11y ago
My point is that if Go was properly formalized as it should have been all along, this would be a lot easier. These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.
- enneff 11y ago
  Will keep that in mind. Thanks!
  - Ericson2314 11y ago
    Good luck!
- ngrilly 11y ago
  Does you critic applies to Rust as well which, as far as I know, is not formalized either? Are OCaml or Haskell propery formalized?
  - Ericson2314 11y ago
    Unfortunately they aren't. But those are all worked on by people with academic (or equivalent) PL backgrounds whose hand-waving I trust much more. Also don't forget the existence of GHC's core, and Rust's Mir (OCaml I'd hope have a good well-defined core language). Basically, for human purposes, there is a spectrum of "quasi-formality" and Go is not winning. Finally, get very excited for http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ .
    - ngrilly 11y ago
      So, basically, you're criticizing Go for something that even languages like Haskell, OCaml and Rust, worked on by people with academic PL backgrounds, don't do. Having a well-defined core language like GHC's Core or Rust's MIR doesn't give your a proper formalisation. It just makes the formalisation easier by reducing the scope of the language. Even ECMAScript 6 "desugars" to a core language. It doesn't make the language more formalised. The fact is that none of Go, Rust, OCaml and Haskell are "properly formalised", as of 2016. Nobody wins here. Thanks for the link about RustBelt.

by enneff 11y ago

Ericson2314 11y ago

My point is that if Go was properly formalized as it should have been all along, this would be a lot easier. These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.

enneff 11y ago
Will keep that in mind. Thanks!
- Ericson2314 11y ago
  Good luck!
ngrilly 11y ago
Does you critic applies to Rust as well which, as far as I know, is not formalized either? Are OCaml or Haskell propery formalized?
- Ericson2314 11y ago
  Unfortunately they aren't. But those are all worked on by people with academic (or equivalent) PL backgrounds whose hand-waving I trust much more. Also don't forget the existence of GHC's core, and Rust's Mir (OCaml I'd hope have a good well-defined core language). Basically, for human purposes, there is a spectrum of "quasi-formality" and Go is not winning. Finally, get very excited for http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ .
  - ngrilly 11y ago
    So, basically, you're criticizing Go for something that even languages like Haskell, OCaml and Rust, worked on by people with academic PL backgrounds, don't do. Having a well-defined core language like GHC's Core or Rust's MIR doesn't give your a proper formalisation. It just makes the formalisation easier by reducing the scope of the language. Even ECMAScript 6 "desugars" to a core language. It doesn't make the language more formalised. The fact is that none of Go, Rust, OCaml and Haskell are "properly formalised", as of 2016. Nobody wins here. Thanks for the link about RustBelt.