10 ms·

We've been playing around with Go where I work. The concurrency model is great, and the type/object/interface approach is pretty flexible. The language designer

by lbarrow 14y ago

We've been playing around with Go where I work. The concurrency model is great, and the type/object/interface approach is pretty flexible. The language designers also succeeded in eliminating many of the pain points they felt with C/C++/Java: dependency bloat and compilation speed. My workflow with Go has more in common with an interpreted language than anything else. However, the lack of generics seems like a pretty bad oversight. It's annoying to rewrite common functional operations (e.g. map, reduce) over and over again with slightly different argument types (or sprinkling type casts all over your code).

objclxt 14y ago
This is probably one of the most discussed things on the Go mailing list (golang-nuts, if anyone is interested). Unlike some other features (like exceptions, again something oft discussed) there seems to be some openness towards it, but also a desire to not introduce anything that would cause increased complexity without a similar or greater increase in value.
- lbarrow 14y ago
  Go's approach to exception handling has a greater impact on the way Go programs are written than the lack of generics. That said, I'm fine with the exception handling because it's obviously a conscious decision by the language designers, and it fits in with the spirit of the language. The lack of generics doesn't feel like that. It strikes me more as an oversight than anything else. This is especially true because some builtins (i.e. make) are generic functions -- they're just special, and you aren't allowed to make your own.
  - azth 14y ago
    There are some other oversights too: lack of immutability/const qualifier; nil pointers in the language; `defer` working at the function, rather than the scope level, etc. Even for error handling, why not use a sum/option type as several other languages use?
    - millerm 14y ago
      Regarding nil references, I now always think of this Sir Charles Antony Hoare quote when the topic arises: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965."
      - azth 14y ago
        So he's saying he rejected declarations that allow you to declare either nullable or non-nullable types? Kotlin and Rust seem to have an interesting approach. In Kotlin, you have to explicitly declare nullable types, and Rust does not allow references/pointers to be null in the first place if I am not mistaken. I have just recently started learning more about Scala, and although it allows nulls to be passed, they are not idiomatic, and I am guessing it would not be too hard to have an automatic style checker that catches uses of null (at least those that do not interface to Java libraries).
        masklinn 14y ago
        No, he's saying he now rejects references being nullable (as the default state of all reference types). A concept of "nothing here" is sometimes necessary so he probably doesn't reject explicit nullability annotations (option types as in Haskell, MLs or Rust for instance; this is not exactly an original approach either).
        bad_user 14y ago
        Scala's approach is sane because you can't dissalow nulls when you're working with libraries that work with null values. On the other hand Scala gives you the tools to deal with nulls very efficiently. You can easily lift nullable values to Options, and because Option is a monadic type, it can be used in for-comprehensions and is very composable. Languages like Kotlin are missing the point.
  - durin42 14y ago
    It's not an oversight. They've said (r and rsc) that they want to wait and make sure they get generics Right in the context of the rest of the language, and make it an easy feature to use in the presence of everything else (should it ever be added.) I'll admit, I've wished for generics occasionally myself, but it's been remarkably rare in the end.
    - masklinn 14y ago
      > They've said (r and rsc) that they want to wait and make sure they get generics Right in the context of the rest of the language Yet they still blessed a few builtin collections with generics without waiting to "get generics Right"
      - burntsushi 14y ago
        What's your point? It's much simpler to bless a few builtins than implement an entire generics system (with respect to the rest of the language).
    - eta_carinae 14y ago
      > They've said (r and rsc) that they want to wait and make sure they get generics Right in the context of the rest of the language In this case, wouldn't it have been better to ship 1.0 with generics? Retrofitting generics in a language already released with an existing code base sure doesn't seem like the best way to make sure the feature is "done right".
  - damian2000 14y ago
    In C# generics were introduced with version 2.0 (around 4 years after C# 1.0). It is now a language feature I couldn't live without.
    - pjmlp 14y ago
      They were already half-way done by .NET 1.0 release, Microsoft decided not to delay the release because of generics. http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-generics-history-some-photos-from-feb-1999.aspx http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-gener...
46Bit 14y ago
Similar feelings here, although I've only been playing with it for a week or so. As someone who grew up (literally) on interpreted languages, Go feels far more pleasant to code in than C/C++.
naner 14y ago
However, the lack of generics seems like a pretty bad oversight. The lack of generics was not an oversight but an explicit design decision.
- xahrepap 14y ago
  Do you have a link to a wiki page or blog post or anything that explains why they decided to omit generics?
  - lbarrow 14y ago
    http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
    - xahrepap 14y ago
      Thanks
  - eternalban 14y ago
    http://research.swtch.com/generic http://research.swtch.com/generic
- sigzero 14y ago
  Maybe he should have said the lack of generics was a mistake and needs to be corrected?
irahul 14y ago
> It's annoying to rewrite common functional operations (e.g. map, reduce) over and over again with slightly different argument types (or sprinkling type casts all over your code). Personally I would go with interface{} and type cast.
- burntsushi 14y ago
  This isn't viable if it's a performance critical portion of your code. Idiomatic Go (currently) is to use a for loop for map and reduce/fold operations.
  - irahul 14y ago
    > Idiomatic Go (currently) is to use a for loop for map and reduce/fold operations. There is going to be a for loop one way or the other. The question is n occurrences of for loop or one occurrence of for loop in a generic_map func followed by n-1 occurrences of call to generic_map and type casting. As for performance, function calls themselves incur a performance penalty. That doesn't necessitate putting all code inline. If the profiler says that interface{} and type casting incurs a significant performance penalty(it does incur a penalty but does it matter?), then I would go for inline for.

by lbarrow 14y ago

objclxt 14y ago

This is probably one of the most discussed things on the Go mailing list (golang-nuts, if anyone is interested). Unlike some other features (like exceptions, again something oft discussed) there seems to be some openness towards it, but also a desire to not introduce anything that would cause increased complexity without a similar or greater increase in value.

lbarrow 14y ago
Go's approach to exception handling has a greater impact on the way Go programs are written than the lack of generics. That said, I'm fine with the exception handling because it's obviously a conscious decision by the language designers, and it fits in with the spirit of the language. The lack of generics doesn't feel like that. It strikes me more as an oversight than anything else. This is especially true because some builtins (i.e. make) are generic functions -- they're just special, and you aren't allowed to make your own.
- azth 14y ago
  There are some other oversights too: lack of immutability/const qualifier; nil pointers in the language; `defer` working at the function, rather than the scope level, etc. Even for error handling, why not use a sum/option type as several other languages use?
  - millerm 14y ago
    Regarding nil references, I now always think of this Sir Charles Antony Hoare quote when the topic arises: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965."
    - azth 14y ago
      So he's saying he rejected declarations that allow you to declare either nullable or non-nullable types? Kotlin and Rust seem to have an interesting approach. In Kotlin, you have to explicitly declare nullable types, and Rust does not allow references/pointers to be null in the first place if I am not mistaken. I have just recently started learning more about Scala, and although it allows nulls to be passed, they are not idiomatic, and I am guessing it would not be too hard to have an automatic style checker that catches uses of null (at least those that do not interface to Java libraries).
      - masklinn 14y ago
        No, he's saying he now rejects references being nullable (as the default state of all reference types). A concept of "nothing here" is sometimes necessary so he probably doesn't reject explicit nullability annotations (option types as in Haskell, MLs or Rust for instance; this is not exactly an original approach either).
      - bad_user 14y ago
        Scala's approach is sane because you can't dissalow nulls when you're working with libraries that work with null values. On the other hand Scala gives you the tools to deal with nulls very efficiently. You can easily lift nullable values to Options, and because Option is a monadic type, it can be used in for-comprehensions and is very composable. Languages like Kotlin are missing the point.
- durin42 14y ago
  It's not an oversight. They've said (r and rsc) that they want to wait and make sure they get generics Right in the context of the rest of the language, and make it an easy feature to use in the presence of everything else (should it ever be added.) I'll admit, I've wished for generics occasionally myself, but it's been remarkably rare in the end.
  - masklinn 14y ago
    > They've said (r and rsc) that they want to wait and make sure they get generics Right in the context of the rest of the language Yet they still blessed a few builtin collections with generics without waiting to "get generics Right"
    - burntsushi 14y ago
      What's your point? It's much simpler to bless a few builtins than implement an entire generics system (with respect to the rest of the language).
  - eta_carinae 14y ago
    > They've said (r and rsc) that they want to wait and make sure they get generics Right in the context of the rest of the language In this case, wouldn't it have been better to ship 1.0 with generics? Retrofitting generics in a language already released with an existing code base sure doesn't seem like the best way to make sure the feature is "done right".
- damian2000 14y ago
  In C# generics were introduced with version 2.0 (around 4 years after C# 1.0). It is now a language feature I couldn't live without.
  - pjmlp 14y ago
    They were already half-way done by .NET 1.0 release, Microsoft decided not to delay the release because of generics. http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-generics-history-some-photos-from-feb-1999.aspx http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-gener...

46Bit 14y ago

Similar feelings here, although I've only been playing with it for a week or so. As someone who grew up (literally) on interpreted languages, Go feels far more pleasant to code in than C/C++.

naner 14y ago

However, the lack of generics seems like a pretty bad oversight. The lack of generics was not an oversight but an explicit design decision.

xahrepap 14y ago
Do you have a link to a wiki page or blog post or anything that explains why they decided to omit generics?
- lbarrow 14y ago
  http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics
  - xahrepap 14y ago
    Thanks
- eternalban 14y ago
  http://research.swtch.com/generic http://research.swtch.com/generic
sigzero 14y ago
Maybe he should have said the lack of generics was a mistake and needs to be corrected?

irahul 14y ago

> It's annoying to rewrite common functional operations (e.g. map, reduce) over and over again with slightly different argument types (or sprinkling type casts all over your code). Personally I would go with interface{} and type cast.

burntsushi 14y ago
This isn't viable if it's a performance critical portion of your code. Idiomatic Go (currently) is to use a for loop for map and reduce/fold operations.
- irahul 14y ago
  > Idiomatic Go (currently) is to use a for loop for map and reduce/fold operations. There is going to be a for loop one way or the other. The question is n occurrences of for loop or one occurrence of for loop in a generic_map func followed by n-1 occurrences of call to generic_map and type casting. As for performance, function calls themselves incur a performance penalty. That doesn't necessitate putting all code inline. If the profiler says that interface{} and type casting incurs a significant performance penalty(it does incur a penalty but does it matter?), then I would go for inline for.