8 ms·

Less is Exponentially More (2012)

145 points by korethr 9y ago

dahart 9y ago
> C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. For the first time, I think I'm motivated to learn Go. My big beef with C++ is there's no simple mode. Every single decision ever made in the syntax and libraries is geared for only the most complicated, high performance needed situations. My problem is that 90% of my C++ code doesn't need performance at all, and could be Python for all I care. To be fair, some of the modern changes are bringing some simplicity back. But, it still feels like wading through mud to write what should be easy things like file i/o, compared to Python or JavaScript. Using hashes and mixing hashes with other containers is so verbose and nit-picky in C++ compared to today's scripting languages that I just long to mix languages most of the time I'm writing general C++.
- mynegation 9y ago
  There is easy mode. It is called C. I am not trying to be flippant. A lot of people started in C++, writing essentially C code and then going to classes, inheritance, templates, wider usage of standard library and boost, little by little.
  - dahart 9y ago
    I’d agree with that, and I’ve done lots of object oriented C. But fwiw, that’s not quite what I meant. You can’t get away from pointers in C, and easy mode should be as pointerless / loopless / functional as possible, like what STL is doing now but simpler and even less verbose. Arduino style C is super fun though...
  - bitwize 9y ago
    But you're not supposed to program that way in C++ at all. Ask a veteran C++ programmer, and they'll tell you that buck n00bs should start out using the STL, smart pointers, and generic algorithms, make sparing use of inheritance, and never touch bare pointers.
    - TheOtherHobbes 9y ago
      This former buck noob took about three months to get to that exact place, because C++ is literally a messy archaeology of random CS ideas, and the guiding philosophy seems to “shovel these funky features in, maybe someone will use them.” Beginner books meanwhile will be five, ten, or fifteen years out of date, and reliably give you a correspondingly wrong view of current best practices. At this point C++ is almost an oral tradition. You need someone who knows what they’re doing to tell you which books to read and which parts of the language to ignore. It’s horrendously difficult to learn if you do the usual thing and try to self-teach - and needlessly so, because the core of the language isn’t that complex.
  - eadmund 9y ago
    C's not really easy mode, either. When I look at all the Unix utilities written in C, I want to weep, because it made things like buffer flows & other security flaws such attractive nuisances. C is easier than C++, certainly, but it's still a pretty rotten language to actually write code in. And I write that as someone whose second language was C, and who loved C with a passion, for many many years. I didn't realise how much I was fighting the language, and I didn't realise how much in any C program the trees of incredibly verbose C-isms obscured the forest of what I was actually trying to do.
- gowld 9y ago
  If you don't need performance, just use Java where everything works fine and is easy to understand.
- kamaal 9y ago
  >>Every single decision ever made in the syntax and libraries is geared for only the most complicated, high performance needed situations. This. The very first C++ code base I worked on was a monolith pile which had some thing like 50 features. There fore when you assemble something like that into a monolith your abstraction hunger kicks in and you run into all these crazy inheritance or template based work. These days people don't seem to write stuff as such huge monoliths. And Microservices architecture has become quite a thing now. Absence of many features in Go feel more like a positive than a negative. You get to eliminate a lot of complexity by default.
RcouF1uZ4gsC 9y ago
A counterpoint is that more can be simpler when it allows better abstraction. For example, calculus is more complicated that arithmetic and algebra. However, calculus can unify and show relations between different algebraic representations. For example, when I learned physics in middle school, I thought that remembering delta position = velocity * time but struggled with delta position = initial velocity * time + 1/2 (acceleration * time^2) When, I learned about derivatives and integrals, the formulas all made sense. In my opinion Go suffers from the ability to abstract which is most represented in its lack of generics. Instead, of being able to represent operations in a generic way, you are forced to cut and paste, and cannot express the relationship accurately, much as how I considered the relationship between acceleration and position to be opaque before I understood calculus.
- barrkel 9y ago
  That formula makes sense when you draw a velocity vs time graph and realise the area under the curve is the distance travelled. With linear acceleration, the area is a rectangle with a triangle on top, and everything starts becoming clear, even without calculus.
  - kbwt 9y ago
    You can also visualize the meaning of d/dx x^n = n x^(n-1) geometrically: There are n faces being extruded which contribute a volume of x^(n-1) dx each.
vinkelhake 9y ago
> C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. Yeah, because it cannot possibly be that many C++ programmers saw Go as step down. Pike thought that C++ programmers would flock to Go in large numbers. That didn't happen, which means that Pike didn't really understand what motivated these C++ programmers. I don't think this summary gets that much closer to the truth.
- AceJohnny2 9y ago
  > Yeah, because it cannot possibly be that many C++ programmers saw Go as step down. You just paraphrased his point.
  - vinkelhake 9y ago
    I realize that it might sound like that. But I would paraphrase his point like this: "C++ programmers spent a ton of time learning C++ so they're not going to switch to a language that isn't C++" Which is basically saying that none of the design decisions that went in to Go matter to C++ programmers because at the end of the day, Go isn't C++. Which in turn is pretty damn uncharitable towards C++ programmers. A lot of technical criticism was offered, but it's easier to ignore that and focus on something you cannot change.
    - RcouF1uZ4gsC 9y ago
      What is interesting is that Rust has seen a lot of interest from C++ programmers. Many C++ programmers like the fact that it takes their informal rules of safe memory/thread management (use RAII, don't use raw pointers, don't use mutable shared state, be careful of iterator invalidation in containers) and formalizes them in the type system so the compiler can check them. In addition, Rust has some nice features like pattern matching, algebraic data types, and Traits that are not yet available in C++. Go on the other hand, was not as compelling to C++ programmers.
WesternStar 9y ago
So what are the best examples of large programs written in go?
- chewxy 9y ago
  kubernetes, docker
- btym 9y ago
  etcd, kubernetes, docker, rkt, grafana, cockroachdb, elastic beats
- agumonkey 9y ago
  not sure if it's large but some pentesting framework went from ruby to go. devs seem to like the language enough to rewrite it all, also, performance benefits have inherent value for non small handling of lots of network events.
- jbarham 9y ago
  NSQ: http://nsq.io/ http://nsq.io/
- executesorder66 9y ago
  To add to the other comments: syncthing is another project that I use all the time, and it is written in Go.
peterevans 9y ago
Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old. Obviously, Go has not replaced C++ usage. And, these days, I would see Rust as the more likely step from C++. (Although, I still feel that it remains to be seen whether Rust will make a huge dent there; is memory-safety the killer-app feature that makes people want to use Rust? Do enough people feel that they Need To Use Rust to make it stick? I'm interested to see how that plays out.) What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. Generics may not make a huge deal for you because there were no generics to use in those other languages. And Go is quite a bit faster than any of the aforementioned interpreted languages.
- sanderjd 9y ago
  > Generics may not make a huge deal for you because there were no generics to use in those other languages. While this is technically true, in practice it is a good deal easier to create generic data types in those languages because you don't have to switch back and forth between type-world and no-type-world.
  - peterevans 9y ago
    Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade. If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages. (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)
    - candiodari 9y ago
shalabhc 9y ago
"Programming in the large" is mentioned a few times in the article but we're still thinking programming one OS process at a time, fiddling with low level data structures - is this really 'in the large'?
- chewxy 9y ago
  programming in the large in the sense of many people being involved in a large program
deleted 9y ago
[deleted]
dang 9y ago
Linearly more discussions at https://news.ycombinator.com/item?id=4158865 https://news.ycombinator.com/item?id=4158865 (2012) and https://news.ycombinator.com/item?id=6417319 https://news.ycombinator.com/item?id=6417319 (2013).
emtel 9y ago
Rob Pike's confusion about why C++ programmers didn't want to move to go is partially explained by his focus on a particular problem domain at the time Go was being developed. Google in those days was primarily concerned with writing highly concurrent request processing software, and at that time the vast majority of that software was written in C++. Writing highly concurrent C++ in the days before the language had things like lambdas, std::function, std::future, etc was definitely gross. In practice, a lot of the concurrent C++ code from that time period took on the callback-hell flavor of node.js code, but without the concise nature of JS. It was gross. Go is obviously a superior language to C++ for writing concurrent programs in every way except possibly when you need to achieve maximum possible throughput (as in google's search clusters) or minimum possible latency (are HFT shops switching to go? I honestly don't know). However, outside of a few companies that have huge capacity problems, people weren't writing concurrent request serving programs in C++. They were using Python, Java, etc., and later, Node.js. So its no surprise that people flocked to Go from those languages and not C++, because there wasn't a huge population of C++ programmers in this problem domain looking for a better language in the first place. The other C++ programmers were down the hall, working on Chrome and Android (which has a ton of C/C++, despite Java being the primary app development language). The reason they didn't, can't, and won't switch is that managed languages like Go are not well suited to highly resource constrained environments like phones, or browsers that are supposed to run on win XP machines. (To say nothing of games). The advantage of C++ is not, as Pike pompously suggests, that C++ programmers have too much fun playing around with templates and other navel-gazing pursuits. The advantage is that it is a high-level language that lets you do what you need to do with very, very close to the minimum possible resource usage. And there are programming environments where that really matters, and those environments are never going away.
- segmondy 9y ago
  I don't think I will say that's the advantage of C++, but rather the perceive advantage of C++. Anytime I've met a great C++ programmer, they start off by ratting of a list of C++ features they don't use.
  - Retra 9y ago
alexandercrohde 9y ago
I guess I don't get it. I agree the abstract idea that a simpler solution is usually preferable. But I don't see how this translates for a language like C++ or Go. I understand the backlash against "magic," but this more a concern of "spooky action at a distance" rather than overhead. Could somebody who understands the sentiment help articulate what type of solutions can be more easily expressed in Go than in say Scala (short of performance-centric cases? Or is this solely about performance-centric cases?).
- Veedrac 9y ago
  The claim isn't that it helps specific things, but that the more detail work you have to do, the less attention you can pay in the large. This is why, for example, Go has the proverb "a little copying is better than a little dependency"; you make a downpayment in the small to make your architecture cleaner. This is something C++ makes exceedingly difficult (Linus Torvald's famous rant is half on this topic). This is also something Scala doesn't do well at, opting to provide a lot of features that make bits of code "prettier" at the cost of being able to see what is being built.
mark-r 9y ago
Is it coincidence that this is up on the front page at the same time as "C++ Core Guidelines" (rules for modern C++) and I started reading this just after glancing at that? The churn and complexity introduced into C++ in the name of simplicity is simply mind-boggling.
xg15 9y ago
I'm one of the people who never understand the absence of generics in Go and, to be honest, I don't find his reasons here very convincing. > Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. [...] What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types. Does he suggest we write containers from scratch every time we need them? There is a lot of nontrivial logic, which I'd prefer not to have to get right again every time. (Not to mention that would feel very much the opposite than "programming in the large") > But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. [... long rant why types are for mediocre people and interfaces are awesome... ] I very much agree that interfaces are awesome and composition is way more useful than inheritance, but what does that have to do with generics? If you have a function that takes a list of things and returns another list of the same things in sorted order, wouldn't you still want to have a way to keep track that the returned list contains the same things as the list you passed to it? That seems independent of whether the things are specified through types or interfaces. Languages primitives for containers are a good idea, but the way Go eventually implemented that (hardwiring the few most-used containers into the language and making it really cumbersome to use custom containers) seems very unsatisfactory.

145 points by korethr 9y ago

> C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. For the first time, I think I'm motivated to learn Go. My big beef with C++ is there's no simple mode. Every single decision ever made in the syntax and libraries is geared for only the most complicated, high performance needed situations. My problem is that 90% of my C++ code doesn't need performance at all, and could be Python for all I care. To be fair, some of the modern changes are bringing some simplicity back. But, it still feels like wading through mud to write what should be easy things like file i/o, compared to Python or JavaScript. Using hashes and mixing hashes with other containers is so verbose and nit-picky in C++ compared to today's scripting languages that I just long to mix languages most of the time I'm writing general C++.

mynegation 9y ago
There is easy mode. It is called C. I am not trying to be flippant. A lot of people started in C++, writing essentially C code and then going to classes, inheritance, templates, wider usage of standard library and boost, little by little.
- dahart 9y ago
  I’d agree with that, and I’ve done lots of object oriented C. But fwiw, that’s not quite what I meant. You can’t get away from pointers in C, and easy mode should be as pointerless / loopless / functional as possible, like what STL is doing now but simpler and even less verbose. Arduino style C is super fun though...
- bitwize 9y ago
  But you're not supposed to program that way in C++ at all. Ask a veteran C++ programmer, and they'll tell you that buck n00bs should start out using the STL, smart pointers, and generic algorithms, make sparing use of inheritance, and never touch bare pointers.
  - TheOtherHobbes 9y ago
    This former buck noob took about three months to get to that exact place, because C++ is literally a messy archaeology of random CS ideas, and the guiding philosophy seems to “shovel these funky features in, maybe someone will use them.” Beginner books meanwhile will be five, ten, or fifteen years out of date, and reliably give you a correspondingly wrong view of current best practices. At this point C++ is almost an oral tradition. You need someone who knows what they’re doing to tell you which books to read and which parts of the language to ignore. It’s horrendously difficult to learn if you do the usual thing and try to self-teach - and needlessly so, because the core of the language isn’t that complex.
- eadmund 9y ago
  C's not really easy mode, either. When I look at all the Unix utilities written in C, I want to weep, because it made things like buffer flows & other security flaws such attractive nuisances. C is easier than C++, certainly, but it's still a pretty rotten language to actually write code in. And I write that as someone whose second language was C, and who loved C with a passion, for many many years. I didn't realise how much I was fighting the language, and I didn't realise how much in any C program the trees of incredibly verbose C-isms obscured the forest of what I was actually trying to do.
gowld 9y ago
If you don't need performance, just use Java where everything works fine and is easy to understand.
kamaal 9y ago
>>Every single decision ever made in the syntax and libraries is geared for only the most complicated, high performance needed situations. This. The very first C++ code base I worked on was a monolith pile which had some thing like 50 features. There fore when you assemble something like that into a monolith your abstraction hunger kicks in and you run into all these crazy inheritance or template based work. These days people don't seem to write stuff as such huge monoliths. And Microservices architecture has become quite a thing now. Absence of many features in Go feel more like a positive than a negative. You get to eliminate a lot of complexity by default.

RcouF1uZ4gsC 9y ago

A counterpoint is that more can be simpler when it allows better abstraction. For example, calculus is more complicated that arithmetic and algebra. However, calculus can unify and show relations between different algebraic representations. For example, when I learned physics in middle school, I thought that remembering delta position = velocity * time but struggled with delta position = initial velocity * time + 1/2 (acceleration * time^2) When, I learned about derivatives and integrals, the formulas all made sense. In my opinion Go suffers from the ability to abstract which is most represented in its lack of generics. Instead, of being able to represent operations in a generic way, you are forced to cut and paste, and cannot express the relationship accurately, much as how I considered the relationship between acceleration and position to be opaque before I understood calculus.

barrkel 9y ago
That formula makes sense when you draw a velocity vs time graph and realise the area under the curve is the distance travelled. With linear acceleration, the area is a rectangle with a triangle on top, and everything starts becoming clear, even without calculus.
- kbwt 9y ago
  You can also visualize the meaning of d/dx x^n = n x^(n-1) geometrically: There are n faces being extruded which contribute a volume of x^(n-1) dx each.

vinkelhake 9y ago

> C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. Yeah, because it cannot possibly be that many C++ programmers saw Go as step down. Pike thought that C++ programmers would flock to Go in large numbers. That didn't happen, which means that Pike didn't really understand what motivated these C++ programmers. I don't think this summary gets that much closer to the truth.

AceJohnny2 9y ago
> Yeah, because it cannot possibly be that many C++ programmers saw Go as step down. You just paraphrased his point.
- vinkelhake 9y ago
  I realize that it might sound like that. But I would paraphrase his point like this: "C++ programmers spent a ton of time learning C++ so they're not going to switch to a language that isn't C++" Which is basically saying that none of the design decisions that went in to Go matter to C++ programmers because at the end of the day, Go isn't C++. Which in turn is pretty damn uncharitable towards C++ programmers. A lot of technical criticism was offered, but it's easier to ignore that and focus on something you cannot change.
  - RcouF1uZ4gsC 9y ago
    What is interesting is that Rust has seen a lot of interest from C++ programmers. Many C++ programmers like the fact that it takes their informal rules of safe memory/thread management (use RAII, don't use raw pointers, don't use mutable shared state, be careful of iterator invalidation in containers) and formalizes them in the type system so the compiler can check them. In addition, Rust has some nice features like pattern matching, algebraic data types, and Traits that are not yet available in C++. Go on the other hand, was not as compelling to C++ programmers.

WesternStar 9y ago

So what are the best examples of large programs written in go?

chewxy 9y ago
kubernetes, docker
btym 9y ago
etcd, kubernetes, docker, rkt, grafana, cockroachdb, elastic beats
agumonkey 9y ago
not sure if it's large but some pentesting framework went from ruby to go. devs seem to like the language enough to rewrite it all, also, performance benefits have inherent value for non small handling of lots of network events.
jbarham 9y ago
NSQ: http://nsq.io/ http://nsq.io/
executesorder66 9y ago
To add to the other comments: syncthing is another project that I use all the time, and it is written in Go.

peterevans 9y ago

Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old. Obviously, Go has not replaced C++ usage. And, these days, I would see Rust as the more likely step from C++. (Although, I still feel that it remains to be seen whether Rust will make a huge dent there; is memory-safety the killer-app feature that makes people want to use Rust? Do enough people feel that they Need To Use Rust to make it stick? I'm interested to see how that plays out.) What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. Generics may not make a huge deal for you because there were no generics to use in those other languages. And Go is quite a bit faster than any of the aforementioned interpreted languages.

sanderjd 9y ago
> Generics may not make a huge deal for you because there were no generics to use in those other languages. While this is technically true, in practice it is a good deal easier to create generic data types in those languages because you don't have to switch back and forth between type-world and no-type-world.
- peterevans 9y ago
  Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade. If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages. (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)
  - candiodari 9y ago

shalabhc 9y ago

"Programming in the large" is mentioned a few times in the article but we're still thinking programming one OS process at a time, fiddling with low level data structures - is this really 'in the large'?

chewxy 9y ago
programming in the large in the sense of many people being involved in a large program

deleted 9y ago

[deleted]

dang 9y ago

Linearly more discussions at https://news.ycombinator.com/item?id=4158865 https://news.ycombinator.com/item?id=4158865 (2012) and https://news.ycombinator.com/item?id=6417319 https://news.ycombinator.com/item?id=6417319 (2013).

emtel 9y ago

Rob Pike's confusion about why C++ programmers didn't want to move to go is partially explained by his focus on a particular problem domain at the time Go was being developed. Google in those days was primarily concerned with writing highly concurrent request processing software, and at that time the vast majority of that software was written in C++. Writing highly concurrent C++ in the days before the language had things like lambdas, std::function, std::future, etc was definitely gross. In practice, a lot of the concurrent C++ code from that time period took on the callback-hell flavor of node.js code, but without the concise nature of JS. It was gross. Go is obviously a superior language to C++ for writing concurrent programs in every way except possibly when you need to achieve maximum possible throughput (as in google's search clusters) or minimum possible latency (are HFT shops switching to go? I honestly don't know). However, outside of a few companies that have huge capacity problems, people weren't writing concurrent request serving programs in C++. They were using Python, Java, etc., and later, Node.js. So its no surprise that people flocked to Go from those languages and not C++, because there wasn't a huge population of C++ programmers in this problem domain looking for a better language in the first place. The other C++ programmers were down the hall, working on Chrome and Android (which has a ton of C/C++, despite Java being the primary app development language). The reason they didn't, can't, and won't switch is that managed languages like Go are not well suited to highly resource constrained environments like phones, or browsers that are supposed to run on win XP machines. (To say nothing of games). The advantage of C++ is not, as Pike pompously suggests, that C++ programmers have too much fun playing around with templates and other navel-gazing pursuits. The advantage is that it is a high-level language that lets you do what you need to do with very, very close to the minimum possible resource usage. And there are programming environments where that really matters, and those environments are never going away.

segmondy 9y ago
I don't think I will say that's the advantage of C++, but rather the perceive advantage of C++. Anytime I've met a great C++ programmer, they start off by ratting of a list of C++ features they don't use.
- Retra 9y ago

alexandercrohde 9y ago

I guess I don't get it. I agree the abstract idea that a simpler solution is usually preferable. But I don't see how this translates for a language like C++ or Go. I understand the backlash against "magic," but this more a concern of "spooky action at a distance" rather than overhead. Could somebody who understands the sentiment help articulate what type of solutions can be more easily expressed in Go than in say Scala (short of performance-centric cases? Or is this solely about performance-centric cases?).

Veedrac 9y ago
The claim isn't that it helps specific things, but that the more detail work you have to do, the less attention you can pay in the large. This is why, for example, Go has the proverb "a little copying is better than a little dependency"; you make a downpayment in the small to make your architecture cleaner. This is something C++ makes exceedingly difficult (Linus Torvald's famous rant is half on this topic). This is also something Scala doesn't do well at, opting to provide a lot of features that make bits of code "prettier" at the cost of being able to see what is being built.

mark-r 9y ago

Is it coincidence that this is up on the front page at the same time as "C++ Core Guidelines" (rules for modern C++) and I started reading this just after glancing at that? The churn and complexity introduced into C++ in the name of simplicity is simply mind-boggling.

xg15 9y ago

I'm one of the people who never understand the absence of generics in Go and, to be honest, I don't find his reasons here very convincing. > Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. [...] What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types. Does he suggest we write containers from scratch every time we need them? There is a lot of nontrivial logic, which I'd prefer not to have to get right again every time. (Not to mention that would feel very much the opposite than "programming in the large") > But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. [... long rant why types are for mediocre people and interfaces are awesome... ] I very much agree that interfaces are awesome and composition is way more useful than inheritance, but what does that have to do with generics? If you have a function that takes a list of things and returns another list of the same things in sorted order, wouldn't you still want to have a way to keep track that the returned list contains the same things as the list you passed to it? That seems independent of whether the things are specified through types or interfaces. Languages primitives for containers are a good idea, but the way Go eventually implemented that (hardwiring the few most-used containers into the language and making it really cumbersome to use custom containers) seems very unsatisfactory.