3 ms·

Your comment and others on Rust here sound a lot like people learning Haskell. There is a similar frustration with fighting the type system and weird concepts (

by qznc 10y ago

Your comment and others on Rust here sound a lot like people learning Haskell. There is a similar frustration with fighting the type system and weird concepts (Monads). I believe lazyness is the biggest problem with Haskell and Rust is eager, so Rust should be more successful than Haskell. The Go comments sound a lot like Java in the early days. Easy language. Quick to get started. Easy to get lots of programmers. If desperate, just train them. Today Java is not so simple anymore, because the Pros wanted more features (eg Generics). I believe Rust will get Generics at some point. Typesafe containers are too useful.

kornish 10y ago
I think you mean "I believe Go will get generics." Rust already has generics: https://doc.rust-lang.org/beta/book/generics.html https://doc.rust-lang.org/beta/book/generics.html. I certainly hope the Go authors can find an implementation of generics with a set of tradeoffs that appeal to them. Typesafe containers certainly are extremely useful.
- civility 10y ago
  I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: https://news.ycombinator.com/item?id=9622417 I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach.
  - qznc 10y ago
    Did they consider the OCaml approach of "generic modules"? I would combine it with C++-style instantiation. By having it on the module level instead of functions/structs, you should be able to avoid the linker bloat. Are there OCaml users in the Go community? Also, there is the hybrid method between C++ and Java, which C# implements: Instantiation for value types and type erasure for reference types.
    - civility 10y ago
      > Did they consider the OCaml approach of "generic modules"? Heh, I certainly can't speak for them, and I don't know what they've considered outside of that link. I also don't know C# or OCaml well enough to say if Go should/could adopt their strategies. However, Java's generics aren't very satisfying, and I think Go is wise to not jump in prematurely. Hygienic macros (as in Scheme or Rust (Nim? Elixir? Julia?)) seem like a more mature concept that could solve most of the problem.

by qznc 10y ago

kornish 10y ago

I think you mean "I believe Go will get generics." Rust already has generics: https://doc.rust-lang.org/beta/book/generics.html https://doc.rust-lang.org/beta/book/generics.html. I certainly hope the Go authors can find an implementation of generics with a set of tradeoffs that appeal to them. Typesafe containers certainly are extremely useful.

civility 10y ago
I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: https://news.ycombinator.com/item?id=9622417 I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach.
- qznc 10y ago
  Did they consider the OCaml approach of "generic modules"? I would combine it with C++-style instantiation. By having it on the module level instead of functions/structs, you should be able to avoid the linker bloat. Are there OCaml users in the Go community? Also, there is the hybrid method between C++ and Java, which C# implements: Instantiation for value types and type erasure for reference types.
  - civility 10y ago
    > Did they consider the OCaml approach of "generic modules"? Heh, I certainly can't speak for them, and I don't know what they've considered outside of that link. I also don't know C# or OCaml well enough to say if Go should/could adopt their strategies. However, Java's generics aren't very satisfying, and I think Go is wise to not jump in prematurely. Hygienic macros (as in Scheme or Rust (Nim? Elixir? Julia?)) seem like a more mature concept that could solve most of the problem.