151–160 of 261 posts
Earlier quoted context omitted.
Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.
It comes up in Scala. The solution is to have notation to specify the variance of types.
It might be fun to share my viewpoint from an angle that's probably fairly unique. I've started a number of large, highly deployed Go projects: Terraform, Vault, Packer, Consul, Nomad, and numerous libraries and other things. I started a company that employs hundreds of full time Go developers. Go has been one of our primary languages since Go 1.0 (and I used it prior to that). Let me start by saying that there are _…
Prior to using Go professionally, I scoffed at the language and wrote it off as an extreme form of Blub paradox. Having worked in languages with generics, as well as languages with advanced type systems (Haskell, Rust, Scala), it seemed like a huge step back.
Initially, I did have a problem with the lack of generics, because I leaned on the feature regularly when writing software. Four years of professional use later and I can say that I am very much glad for the lack of generics. It is almost always straightforward and easy to read and understand Go code that someone else has written. The same cannot be said for the other languages I've mentioned.
For the problem domain we are using it in (devops), it has been a godsend. The company makes use of many different languages from various paradigms, yet anyone can pick up Go quickly if they want/need to contribute to or deeply understand our tooling.
func Reverse (type Element) (s []Element) {
first := 0
last := len(s) - 1
for first Reverse(int)(s)
Reverse(int, s)
I hope this doesn't happen. I love golang because it is simple and easy to read. Both will go away when generic programmer start to write unreadable meta-programming class which "you don't need to understand, just use them". I admire golang devs for being opinionated and stand up for the core lines of their language so far. I see generic as renouncing these principles.
Earlier quoted context omitted.
>then I have to be familiar with the full semantics of C# generics Or you could research the very detailed discussion and documentation available on the topic of C# generics.
How is your suggestion not equivalent to "be familiar with full semantics of C# generics"? How does that help me with being productive using Go's implementation of generics, which has fundamentally different type system and syntax to begin with?
Earlier quoted context omitted.
It makes code unreadable. void lol >, E>()
Pretty much all syntax is unreadable if you don't know the lingo. For example, try presenting the ubiquitous for (int i = 0; i to ten random people without prior programming experience and see how many of them can correctly tell you what all that means. Similarly, { a, b in a > b } is probably not very clear to people who don't write Swift and perfectly lovely closure syntax to people who do. There's language syntax…
Earlier quoted context omitted.
Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.
It comes up in Scala. The solution is to have notation to specify the variance of types.
He's right. It's easy to understand one level of variance: you can replace a return type by a subtype and a parameter type by a supertype. (I wouldn't be surprised that many programmer don't undestand this.)
Two levels already requires some deep thinking (assuming definition-site variance: `List` or `List` as a return type / parameter type, was is allowed to replace it?
More than that? (`List>`) Hahaha, good luck.
And by the way, Java has notations to specify the variance of type, but only at the use-site, which is different from doing it at the definition site (both enable expressing things the other can't do... but you can actually have both, as I think is the case in Kotlin, though there are some limitations).
Earlier quoted context omitted.
Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can’t tell if it’s a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.
You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.
a := Bar(baz)(buzz)
It might be fun to share my viewpoint from an angle that's probably fairly unique. I've started a number of large, highly deployed Go projects: Terraform, Vault, Packer, Consul, Nomad, and numerous libraries and other things. I started a company that employs hundreds of full time Go developers. Go has been one of our primary languages since Go 1.0 (and I used it prior to that). Let me start by saying that there are _…
They're quite different documents, so I think this is somewhat unfair and misleading. The go spec doesn't spend prose on explaining rationals, alternatives, historical references, etc.