Because the creators won't give us generics
Why generic builtins instead of a Channel interface?
Why is len a function and not a method?
We debated this issue but decided implementing len and friends as functions was
fine in practice and didn't complicate questions about the interface (in the Go
type sense) of basic types.
I guess there's a certain cleanliness whereby all methods exist on one side of the language/library dividing line.
† The sole exception perhaps being "error", which is a pre-declared interface comprising 1 method.
---
In a similar vein, this takes some getting used to:
x.append(y) # No!
append(x, y) # Probably Not!
x = append(x, y) # Yes! (but this is not Lisp - despite appearances, the collection is mutable)Ah! Beacause it is like Lisp?
(setf x (nconc x y))
Surely, we could wrap append with a appendf (append functional), such that we can do:
x = appendf(x, y); # no mutation: original x preserved
That's why you have to care about the return value in normal Go. The slice x opaquely references a backing array with a certain max capacity. If you append one too many times then it's going to return a completely new value that references a new backing array that has more legroom ... with all your existing elements copied into it.
(p.s. I just noticed that Go actually considers that "Probably Not" case a compile-time error)
Go was invented for internal Google use, and then shared with the world, and Google is an engineering company. If engineers would have rebelled, higher management probably would have done something about it.
-----
Although I don't understand why they keep fighting it. A simple style generics (Java style) shouldn't make code that ugly.
Not necessarily. Go was invented for internal Google use, but most of Google's code is still in C++ and Java. New projects are often started in C++ and Java, even, as they depend on libraries written in those languages. I think this would be true even if Go were perfect; switching languages is hard. But it means you shouldn't assume Google has solved whatever problems one would encounter while implementing Google product X in Go. Or that all Google engineers believe Go is a good language; as with any large group of programmers, there are people with opposing viewpoints about the virtues of various programming languages.
Google management doesn't tend to impose top-down technical decisions such "product team X must use Go" [1] or "the Go team must add language feature X". They generally give broad direction and then trust the engineers doing the work to find the best technical approach to accomplish the task.
[1] Although you generally must stay within the handful of approved languages: C++, Java, Go, JavaScript (for frontend stuff), Python (mostly for internal stuff, and getting less socially acceptable over time). One reason for this list is that when you write a Google system in a new language, you need a bunch of support from the rest of the company to do it: build infrastructure, libraries, etc.
Go was invented by a small group at Google with the aim of solving some of Google's problems as they saw them. It's not as if the whole of Google came together and collectively designed the language they needed. I wouldn't read too much into the fact that it happened to be invented at Google, rather than wherever else Rob Pike happened to be working at the time.
Java-style generics are a lot of things (notably “bolted on”), but “simple” certainly isn't one of them. Wildcards are complex. F-bounded polymorphism is complex. Non-denotable types are complex.
Variance is straightforward anyway. A lot of things in Go, like the semantics of "nil" and zero values, are more complex than variance. And, as a designer, if you're worried about the complexity, just make all type parameters invariant, like C++ does. It's a bad excuse to not have generics at all.
Rust works exactly the same way as Go (coercions, no subtyping), except that there is subtyping in Rust via the region system. But Go doesn't have that. No region system, no subtyping.
And I don't think making all type parameters invariant eliminates any complexity. It just pushes it onto the user.
Also, from “Foo <: Bar”, you can't automatically conclude that “[]Foo <: []Bar”. That requires the additional assumption that [] is a covariant type constructor, which in Go it isn't.
The next obvious step is getting an answer to "what is the meaning of saying Go doesn't have subtyping?", which is essentially what you asked above:
> What distinction between coercion and subtyping are you making?
But this is a question for pcwalton, not you. :-) However, I have some thoughts on the matter.
While exploring the extent of my wrongness, I found it very interesting that the Go language spec doesn't mention the words "subtype" or "polymorphism" or "structural" at all. The FAQ mentions "subtype" and "covariance," but doesn't lead to anything conclusive. What I think this means is that the language designers of Go probably don't think of interfaces as being tied to the formal notion of subtype, but rather that of assignability or coercions. This just takes us in a circle though, which leads me to guess that this is a simple matter of two groups of people having different names for the same thing.
(0) Structs and interfaces are unarguably types.
(1) If a struct S has all the methods required by an interface I, then every term of type S also has type I.
As for coercions, they are one possible implementation of subtyping. Another possible implementation is guaranteeing that, whenever “Foo <: Bar”, then “Foo” and “Bar” have a common in-memory representation.
But languages shall never be conflated with their implementation details!
For example, if you start with some base assumptions about which type constructors in Go are invariant, e.g., pointers, slices, arrays, etc., then you could feasibly come up with a rule like this: If T <: U, then Foo<T> <: Foo<U> if Foo's type parameter doesn't appear within an invariant type constructor in the definition of Foo. If a rule like that is all you need (and those types of rules have precedence in Go, like whether a type permits equality comparisons or not), then I think that more or less backs up pcwalton's point that subtyping isn't necessarily the thing you have to worry about when adding parametric polymorphism to Go. It's the other stuff, like the mentioned zero values and presence of `nil`.
Although zero values are inelegant, I don't see why they would interact so badly with parametric polymorphism. In Rust terms, it's as if every type implicitly implemented the Default trait. (EDIT: You're right, steveklabnik. It's closer to Default than to Zero. Thanks!)
As for nil, I'd rather not comment, since I'm not familiar with the specifics of how it works in Go. (But a previous conversation with pcwalton made it perfectly clear that it doesn't work the same as in Java or .NET.)
No. There's a defined coercion between values and interface types, which is not the same thing as subtyping. This affects the semantics: for example, you can't pass a value of type []MyStruct to a function taking []interface{}.
Whether or not they are a show stopper for the users - well, that depends on your use case and preferences. Since show stoppers are a subjective thing. Objectively you could implement everything in Assembly or even Machine code, and people used to write rather complex programs this way.
I personally know there are a lot of types of systems I would never implement in Go if given the choice, because it would be too bothersome, and I don't like RSI. YMMV.
IIRC most of Google is C++ and Java, which both have generics.
I read somewhere that they have a lot (I think it was in the MLOC range) of proprietary/in-house code written in go.
[1] https://www.quora.com/Does-Google-use-the-Open-Source-Kubern...
Kubernetes is growing in popularity. Among older systems, Mesos (with Marathon, usually) seems to be quite popular.
Spotify uses Helios [1] to run their stuff. We evaluated it briefly and decided it was too limited and immature compared to Kubernetes.
Mesos + a framework such as Marathon or Aurora was the most needy choice before Kubernetes came on the scene. Mesos probably scales farther than Kubernetes in terms of pure cluster sizes, but it also depends on what framework you use on top (Mesos itself is just a scheduler). I don't know if any of them are as flexible as Kubernetes in terms of things like volume management, config/secret management and security. It's also worth pointing out that Kubernetes can run on Mesos.
How is Mesos "needy"? Can you elaborate?
Needy has a negative connotation and it's not word I would necessarily associate with the Apache Mesos project. I've run a number of clusters in production now for just over a year with Marathon and it pretty much "just works." I have done 5 or 6 rolling upgrades now without issues. I haven't found it to be needy at all, quite the opposite, its been rock solid and the management overhead has been nominal.
>" I don't know if any of them are as flexible as Kubernetes in terms of things like volume management, config/secret management and security."
I think that Mesos is actually more flexible as it allows you to cherry pick the non-scheduler specific components to fit your use case. As an example for secrets management you can use something like Consul Vault or integrate Keywhiz or completely roll your own.
I feel like with Kubenetes you buy into the "whole thing". Using the example of secret management - you have one choice for secret management and the last time I checked they were stored in etcd in clear text. So if that doesn't fit your security requirements it seemed like you were out of luck.
Mesos also has a nice for for persistent volumes:
See: http://mesos.apache.org/documentation/latest/persistent-volu...
and:
http://schd.ws/hosted_files/mesosconeu2016/08/MesosConEurope...
Sorry, that was the damn autocorrect — I typed "beefy". As in large and powerful.
I'm not surprised if Mesos has solutions for what you describe. When I said "I don't know", I meant it literally! :-)
That said, Kubernetes provides nice built-ins, but doesn't force you to use them. You can use Vault for secrets management, for example.
[0] Don't be silly, of course we rolled our own.