
“Go’s design is a disservice to intelligent programmers” - apta
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
======
carbocation
My summary of the author's points: no generics, inexpressive, no good package
manager, procedural.

Of these, caring about the fact that it is procedural seems pure opinion.
Lacking a package manager is not really a language issue (PHP's package
manager, for example, is not coupled to the core language).

So, we are left with the lack of generics and the lack of expressivity. I'm
not deep enough in the weeds to be able to argue pro/con for generics
intelligently right now, so I will concede that as a concern that has been
raised by many.

The lack of expressivity seems to be an inexorable consequence of the goal of
simplicity, so I'm sympathetic. That said, it seems to be a tradeoff
acknowledged by Go's authors, not an oversight.

Overall, these points don't convince me of the author's thesis (or, at least,
they don't seem to justify the title's degree of inflammation).

~~~
AlexandrB
I thought the "sum" example was pretty damning. Bug count scales with code
length so writing tons of boilerplate code to work around language limitations
means you're introducing bugs.

~~~
carbocation
I believe that the purpose of `go generate` is to lessen the risk of this type
of thing by handling the repetitive code generation for you, but I do agree
that it's a limitation. If done by `go generate`, it's an additional procedure
that you have to learn; if done by hand, it's a bug risk.

~~~
meowface
Code generation is a giant spiked mallet for a nail which can easily be
screwed with a small screwdriver. It has its uses, especially for generating
schemas (like what Protobuf and Capnproto do), but for generating actual
function implementations it's kind of absurd. `go generate` is a nice tool but
it's not even remotely a solution to the no-generics problem.

Of course, the problem is that for the compiler implementation, those traits
are completely reversed (adding generics at this point is like hitting the
compiler with a mallet); and that happens to be Go's primary excuse for lack
of generics/templating/macros/anything sane. I think dev ease-of-use matters a
lot more than core dev ease-of-use though. Even if the compiler must grow in
complexity and average compile time, the benefits to devs are worth it.

~~~
NateDad
No one has ever said that the compiler implementation would be too hard, and
that's why there's no generics in go. People need to stop saying that, because
it's bullshit.

~~~
meowface
From the Go FAQ ([https://golang.org/doc/faq](https://golang.org/doc/faq)):

>Generics are convenient but they come at a cost in complexity in the type
system and run-time. We haven't yet found a design that gives value
proportionate to the complexity, although we continue to think about it.

Not hard as in "can't do it", but hard as in too hard to implement without
adding the ever feared "complexity".

For the record, I like Go and its philosophy, but I think, above all other
issues with the language, the lack of generics is a huge weakness and will
eventually be looked back on as a mistake. Not just for not having them before
1.0, but also for waiting as long as they did for adding them, assuming they
ever do add them.

~~~
NateDad
The type system is a concern about the complexity for the users of Go, not for
the compiler developers.

~~~
meowface
How exactly? Ignoring issues of backwards compatibility for the moment, I
don't think Java's introduction of generics added a ton of complexity for
developers, and I don't see why Go would either. In Java's case it seemed like
the complexity was definitely on the compiler side, due to their type erasure
approach.

I admit I'm not an expert in programming language design though, so I may be
completely wrong about both Java and Go.

------
barsonme
His Go is a little disingenuous. This
([https://gist.github.com/EricLagerg/105431503d32f18d239b](https://gist.github.com/EricLagerg/105431503d32f18d239b))
is almost as short as his D code, and functions the same.

~~~
jff
It's almost as if, like most people who write articles complaining about Go's
lack of "expressiveness" and generics, he took a cursory look at the language,
wrote some naive examples that supported his point, and squeezed out a blog
post.

~~~
waps
If the code was equivalent you might have a point. Unfortunately it is not
(tokenizing/line scanning vs. copying). One has a shortcut in Go, the other
does not.

Would you say that Go is not excessively verbose in non-trivial use cases ? I
recently had to sort a struct list in a program. Added lines of code for
sorting a single list once : 30. What the ...

~~~
okbake
I'm curious about the specifics of your problem. I couldn't imagine sorting a
list of structs (by one of the fields I presume) would be too terribly
different in Go than in other langauges. Heres an example of insertion sort on
a basic type:
[https://play.golang.org/p/SPoiNRVl2B](https://play.golang.org/p/SPoiNRVl2B)

You can use the standard library sort methods by making your type implement
the sort interface. Heres an example taken from the example in the sort docs:
[https://play.golang.org/p/oeRIhHi1Ei](https://play.golang.org/p/oeRIhHi1Ei)

~~~
he_the_great
I see you've grabbed some examples to show the simplicity. Having to write the
insertion sort algorithm to sort your basic types is not simple.

Having to tell the standard library how to swap data in a slice and to obtain
a slices length is simple... why doesn't the standard library know how to work
with basic types? This way I don't end up writing by accident:

    
    
        func (a ByAge) Swap(i, j int)      { a[i], a[j] = a[j], a[j] }

------
ereyes01
If I wasn't already a Go programmer, reading this would make me more
interested in Go than not.

Simplicity is deceivingly challenging, and quite different from simple-
mindedness, which seems to be what the author is accusing Go of being.

Keeping code simple, elegant, and consistent is IMHO one of the most valuable
principles a team can adhere to. Simple is not necessarily shorter, as short
can often be subtle and sneaky rather than simple. Complex power tools can be
fun to the inquiring mind, but the ultimate consumers of your product almost
never appreciate how you built it, but almost always appreciate the final
outcome.

A wise man once said: “Everyone knows that debugging is twice as hard as
writing a program in the first place. So if you're as clever as you can be
when you write it, how will you ever debug it?” - Brian Kernighan

~~~
meowface
There's also the argument that your chance of writing buggy code increases
with each additional line you write.

Highly _readable_ code helps reduce bugs. But if that code is also so
simplistic that it necessitates a lot of verbosity, you definitely increase
the chance of introducing some stupid bug. Thankfully, as a compiled language,
Go can find a decent portion of the silly stupid bugs where in a more
expressive language like Python they might go hidden for longer, but it's
still a big tradeoff you're making.

~~~
NateDad
Go is not significantly more verbose than python except in a couple trivial
cases (list comprehensions become a 3 line loop). Across even a moderately
sized program, this will most likely not even amount for a statistically
significant difference.

~~~
meowface
As a professional Python developer and amateur Go dabbler, I very vehemently
disagree.

Without access to list/dict/set comprehensions, or libraries like itertools,
or a lightweight lambda syntax or something like Ruby's blocks,
transformations on collections will always be considerably more tedious and
verbose.

Various functions have "bring-your-own-buffer" calling conventions, which will
often double or triple the number of lines required for those function calls.

No tuple unpacking, no ability for functional programming (Python's isn't that
amazing but with functools and some of the builtins, you can get pretty far),
no operators for string formatting or anything but absolute barebones
operations.

Combine that with what Go lacks even compared to languages like Java (no
inheritance [which is usually an anti-pattern but does decrease verbosity when
used properly], no generics, no deep type/class reflection) and it's hard to
say that Go isn't a verbose language.

No statically typed language is going to be as terse or expressive as Python
can be.

~~~
NateDad
Can you explain how tuples are significantly different from multiple returns
in real programs? You can do

    
    
        func foo() (string, int, bool) {
            return "one", 2, true
        }
    
        func bar(s string, i int, b bool) {}
    
        bar(foo())

~~~
meowface
When dealing with function calls, they're roughly the same.

But how about things like:

    
    
        g = some_input() # A list with 3 elements
        a, b, c = g
    

Or in Python 3+:

    
    
        lst = [1, 2, 3, 4]
        head, *tail = lst # 1, [2, 3, 4]
        *init, last = lst # [1, 2, 3], 4
        a, *b, c = lst # 1, [2, 3], 4

~~~
NateDad
You can do that in go with just a few more characters:

    
    
        g := some_input() // A list with 3 elements
        a, b, c := g[0], g[1], g[2]
    

I'll grant you, having to specify the indices is slightly more verbose, but
it's also a lot more clear... because what happens when g has more or less
than 3 elements? In Go it's clear, more is ok, less will get you a panic.

    
    
        lst := []int{1, 2, 3, 4}
        head, tail := lst[0], lst[1:]
        init, last := lst[:len(lst)-1], lst[len(lst)-1]
        a, b, c := lst[0], lst[1:3], lst[4]
    

Again, I don't think the magic unpacking is really helping that much... doing
it the same way you'd do anything else in Go is slightly more verbose, but
it's also not some new syntax you have to figure out either.

------
nemo1618
IMO, the author's "copy data to stdout" example betrays a lack of language
understanding. Here's a more idiomatic version:
[http://play.golang.org/p/ZWatRuj3Q_](http://play.golang.org/p/ZWatRuj3Q_)

~~~
zoips
Kind of code golfing it:
[http://play.golang.org/p/s53zQrE0ei](http://play.golang.org/p/s53zQrE0ei)

~~~
sounds
That's definitely shorter, but I would hope that isn't considered the most
shining example of non-obfuscated code. :)

(For code golf, though, it's just fine.)

~~~
NateDad
It's actually very simple code, if you're at all familiar with go. That's
probably what I would have written just by sitting down at the computer to do
so for work.

------
staunch
You shouldn't be offended that Rob Pike thinks he's a much more advanced
programmer than your average programmer.

He is.

Whatever his motivations, he created a very productive language. As it turns
out, even advanced programmers benefit from having a simple language when it
comes to getting practical work done.

~~~
Someone1234
> As it turns out, even advanced programmers benefit from having a simple
> language when it comes to getting practical work done.

I'm making this point quite tongue in cheek however...

By that logic why do programmers hate Visual Basic so much? At least VB6 was
very much a "simple language" relative to other things around at the time
(less so with VB.net/C#).

A lot of the arguments people are making here (less is more essentially, and
clear syntax wins over complexity even at the cost of efficiency) then VB6
should be something we're modelling modern languages off of, but it is not...

PS - Remember I am not being literal here. VB6 had some issues both then and
now. I am not really comparing Go to VB6, I am comparing the arguments made in
support of Go to arguments that could be made in support of VB6.

~~~
PopsiclePete
There's a difference between being "simple" and "brain-dead". C, for example,
is _very_ simple, simpler than Go, even, but you can't compare it to VB6
either. Your comparison is disingenuous at best.

Simplicity is a _good_ thing. It's a _virtue_. It's part of what made UNIX a
success. It's not something to shun or avoid.

Adding features adds complexity and complexity is not free.

Notice how the industry _still_ has't jumped ship whole-sale to Haskell?

~~~
the_why_of_y
Where did you get the idea that Haskell is a complex language? The core
language is just 6 or 7 different expressions, everything else is syntactic
sugar - it is in fact much simpler than C.

One of the reasons it's not widely adopted is that the features that
programmers take for granted, like built-in syntax for mutable variables, are
_missing_ , i.e. it's too simple.

------
10098
I tried Go. It didn't really impress me, to be honest. I get that they're
trying to build a nice, coherent language and, but they do that by simply
avoiding doing all the things that are hard. I don't see any compelling
reasons to choose Go over, for example, Java.

~~~
NateDad
Go uses a lot less memory than java in general (generally due to having real
value types and usable pointers). Go has clean multi-threaded code baked into
the language. Go requires no external runtime, so you never have to worry
about what version of the runtime is on a machine. The implicit interfaces
make it easier to keep separation of concerns, and prevent your code from
turning into spaghetti.

------
jacquesm
Languages should be criticized by those that have spent sufficient time in
them to be able to _really_ see their shortcomings. Having a little bit of
experience in a language is not an automatic qualification for writing blog
posts about what's amiss, for that you need more than just surface
familiarity.

~~~
he_the_great
Seems to me the replies made to the "fake" problems are very telling about
what is a problem.

For example, Go is praised for being a simple language that everyone can learn
quickly, yet when someone shows what they picked up "that isn't how you do
it."

I get that it is one thing to get something done, and another to learn an
idiomatic approach. But when the sort package is hailed as the example for
both why Go doesn't need generics and Go does need generics, I think it is
safe to say that even the language creators don't know how to use Go.

------
east2west
This topic periodically flares and provokes so much emotion it is almost
unseemly. The two camps are so diametrically opposed that I think other
factors are at play here. Programmers who cannot or don't want to understand
some of more advanced/esoteric features of expressive languages like C++ or
Rust insist on the virtue of simple languages because it guarantees job
opportunities for them. Their slogan is group power; quantity has a quality of
its own. Interestingly, communists have similar slogans, who are mainly
intellectuals self assured to govern/manage the mass and be handsomely
compensated. I never realized the common interest between the top and middle,
or how corporate the communism is. The other camp is equally vehement because
their livelihood is at stake. If all their time and effort will not make them
better/more productive programmers, the upper limit to their compensation is
drastically lowered, not to speak of damage to their self-image and statue
among peers. They are the liberal individualists who insist that there is no
limit to what one individual can achieve or make. There is no need to debate
this further. Everybody WILL not change their mind. Go will go far, just look
at Java.

~~~
robwilliams
>Go will go far, just look at Java.

How did you reach this conclusion? I also don't understand the odd comparison
to communism. Who's the communist in this scenario?

------
transfire
I have to agree about the generics, and agree a bit about error handling too.

Also, I wasn't impressed by the speed. I wrote a program in Ruby, Go and
Elixir and expected Go to win, but is was 1x, 5x, 20x respectively, and I
could never figure out why there was such a discrepancy.

Even so, if they added generics and improved performance, I would be very
inclined to use it. It is surprisingly comfortable to code in.

~~~
isaiahg
I would wager it was human error.

------
intortus
Just because you're intelligent doesn't mean you should spend all that
intelligence trying to figure out other people's messes. Simplicity and
explicitness are paramount when collaborating.

~~~
AlexandrB
> Simplicity and explicitness are paramount when collaborating.

So is succinctness (most people can't speed read code). The examples he gives
make Go look anything but succinct.

~~~
intortus
At a certain point succinctness does more harm than good. Go captures nearly
all of the sense of python's early values
([https://www.python.org/dev/peps/pep-0020/](https://www.python.org/dev/peps/pep-0020/)),
without requiring all that much more in the way of boilerplate. So you have to
if-check an error value here and there, no big deal. You should be handling
errors anyway.

If Haskell's succinctness level is 1, then I would rate python's at 2, go's at
4, and java's at 20.

~~~
sheepmullet
Nonsense. On moderate-large codebases Go is not 5x more expressive/succinct
than Java. Maybe 1.5x if you are lucky.

~~~
MetaCosm
Please point me to the large codebase your ported from Java to Go -- if you
don't have actual data, just two people making up idiotic numbers let me get
involved.

Go is 185175% better than Java and 8165% better than Haskell -- or making up
numbers just makes us all look like goddamn idiots.

------
smt88
I'd be really curious to know what this guy thinks of Rust.

~~~
nemo44x
I'm a bit curious too - he seems to hate the idea a programming language
thinks the developer is an idiot.

Rust, for how perfect it really is, treats developers as humans. You must be
smart if you can use it - but it doesn't trust you to have any idea what's
really going on when a program gets large. This is a good thing IMO.

Honestly, anyone who thinks Rust is trash is just wrong. I can get the
argument that there just will never be enough people who can use Rust but
having learned Go and then Rust - I have to say Rust is the most well designed
programming language ever. I can't believe what's in it and it's far and away
the most advanced programming language ever. It's hard to compile but when it
does you have a good chance it's right.

~~~
kibwen
I heartily disagree that you have to be smart to use Rust. I'm a ho-hum CRUD
web programmer with enterprise credentials and versed in dynamic languages,
and I was able to pick up Rust quite easily as my first systems programming
language ever. The hardest part isn't even learning the language, the hardest
part is figuring out the essential differences that separate the systems
programming domains and the high-level dynamic domains.

~~~
smt88
That's a great endorsement. I was going to do my next experimental app in Go,
but this really makes me want to use Rust.

------
deedubaya
The author is basically saying that you'll be better off banging your head
against a wall trying to figure out a more complicated language than to pick
up golang quickly an start building something.

News flash! Not everyone is a brilliant developer. And that's okay!

News flash! Not ever developer has extensive programming experience and can
pick up new concepts quickly. And that's okay!

Go is too simple for you? Drink a big glass of shut the hell up and go write a
program in brainfuck or something.

Intelligent programmers aren't dependent on the language they use to become
better developers. There is no disservice in being able to build something
quickly.

~~~
sheepmullet
Most of the negative reactions to Go aren't really to do with the language
itself. They are more general feelings of frustration with our industry.

Part of the reason Go is so popular is because we place such a low value on
education, training, and long term productivity, and a high value on getting
things done quickly. In general our industry is focused on the short term, is
fad driven, and is more than willing to turn on our own.

Go is a language created to win in this kind of environment. And because
people hate the environment... they focus their animosity on the tools that
are successful in our environment.

~~~
15155
> more than willing to turn on our own

This "it's so simple!" nonsense is an exemplification of that.

By reducing everyone (even good programmers) to the lowest common denominator,
talent is far more commoditized and pluggable. You can throw away Programmer A
because Programmer B is "as good as it can get for

------
farresito
Man, I've lately seen so many posts criticizing Go. They must have done
something pretty well with it. It's sad that I see more posts criticizing Go
than posts talking positively about it.

~~~
nemo44x
I hear you and I have been a fan of Go for awhile. But, it hasn't really done
anything new, especially in regards to programming language theory over the
last 30 odd years. It feels like another "developers, developers, developers"
play and when you see ultra modern languages like Rust, you sort of get the
feeling Go is half baked and without purpose.

~~~
farresito
I completely understand most people's complains about Go. I think most
programmers that have used Go understand that it doesn't offer anything new,
besides very easy concurrency and a few other things. Still, I think it has a
place, and it seems a few large companies are using it with success, and, at
the end of the day, if people find it practical, then way to go.

------
zzzcpan
Author's examples are really exaggerated, but there is definitely some truth.
Bufio and flag packages are not that good. And "idiomatic" Go is full of poor
abstractions. More often than not it feels like some things are written by OO
programmers and are unnecessary hard. Like people don't know there are
function literals in Go and they are free to abstract away state changes,
instead of creating objects and spreading them all over the place.

~~~
rogpeppe1
I'd like to hear more details of your issues here. What's not good about the
bufio package? What do you mean by "poor abstractions"? What's wrong with
creating a single purpose local type rather than using a function literal?

------
evmar
It's pretty funny how this post is on the front page adjacent to a post
profiling one of the Go authors that opens with mentioning his masters/PhD
from Harvard/MIT.

~~~
EugeneOZ
And for more contrast, author of critique article can only brag "past few
months I’ve been using Go to implement a proof of concept program in my spare
time". I really hate articles from noobs who thinks they have a right to
criticize something without being proficient in it. And not only about Go. At
least HN comments are interesting.

------
sheepmullet
It's the difference between simple and easy. Go is very easy for existing
developers to learn because it is basically a cut down subset of what they
already know.

Which makes Go a great option.... if you use it properly. It means you don't
need to worry about a programmers language history when you hire even if you
need them to be productive right away.

It means you can hire the smartest developers, regardless of whether they have
been doing embedded work, or spas in js, or large enterprise application dev
in java, etc.

~~~
15155
In other words: reduce everyone to the lowest common denominator.

~~~
Gigablah
But I'm a special snowflake! This won't do!

~~~
sheepmullet
Of course a lot of good developers won't like it because it is a change that
makes them worse off.

If you are a good Haskell/D/Lisp developer then switching to Go will probably
halve your productivity over the long term.

There are a lot of benefits to using Go but lets not pretend there aren't any
downsides.

------
djhworld
The author is trolling or has some weird superiority complex, don't rise to
it.

------
PopsiclePete
Ahhhh, he's a D programmer. That explains most of it. D programmers are only
slightly behind C++ programmers in their universal hatred for Go. Rubyists can
learn to love Go, Pythonistas can learn to love Go, NodeJs people even, but D
programmers, man, it's like just the mere _existence_ of Go is an assault on
their very souls.

If D and C++ programmers hate Go, it's doing something right.

~~~
Grue3
No, it just means there is nothing in Go that would cause a D or C++
programmer to switch to it. The feature set of D and C++ is a superset of Go
feature set.

This "they laughed at Einstein, so I must be right too" mentality is pure
fanboyism.

~~~
dvirsky
As a (mostly ex) C++ oriented engineer, there is a hell of a lot that would
make me prefer Go to C++ for a lot of tasks. A language is not about its
features, it's about how it facilitates what you need to get done.

------
keithba
"So Rob Pike is basically saying that the developers at Google aren’t very
good so they’ve developed a dumbed down language so they can get things done."

I read the Pike quote very differently. When Pike says: "The key point here is
our programmers are Googlers, they’re not researchers." I thought he meant
programmers today use google to assist them in programming.

~~~
jalfresi
"The key point here is our programmers are Googlers, they’re not researchers."

I took that to mean "Our programmers are building products, not thinking about
building programming languages"

~~~
AnimalMuppet
It may go even further than that. Google has to produce multi-million line
programs and maintain them for a decade or two. That's not a problem that most
programming language researchers face. If researchers think about that, they
usually do so in the abstract, rather than from a position of personal
experience.

One place this shows up: Build times. Turning a 45-minute build into a
10-second build, times 30 programmers, times several builds a day for 10
years... that adds up to a really big difference.

~~~
MetaCosm
It always astounds me when (inexperienced) developers play down build times as
if they simply aren't that big an issue. They are hellish, creativity crushing
monsters.

Also, static binaries -- so the DevOps guys don't hit you with sticks.

I still remember the first go program README.md I shipped. "Umm, get foo to
box, ./foo in a way so that it runs persistently and at startup."

Easy way to get your apps to the front of the line in the deploy queue -- all
the time.

------
oh_sigh
The odds of a single individual being an "intelligent" programmer is much
lower than the odds of a team of all present and future programmers for a
project being intelligent.

~~~
oh_sigh
Uh..yes, I meant much higher, not much lower :(

------
ithkuil
> In my opinion Go has been designed by people who have been using C all their
> lives and don’t want to try anything new. [..] > Another grating issue is
> that because Go is procedural (just like C ‘shock horror’) you start writing
> code in a procedural way which feels archaic and old hat.

Ok, Go is not object oriented, but it has a few features that make it possible
to do some stuff that are very cumbersome if not impossible in C.

\- first class functions and closures

\- you can safely take an address of a local variable and use it after the
function's scope exits (the compiler takes care about promoting variables to
the heap)

\- interfaces allow you write modular code: e.g. you can create your own
Reader and Writer interfaces and the standard library can operate on it.
People are focusing much about generics/templates but it's not that Go
completely lack any way of creating modular and reusable code.

\- pointer/value distinction but having safe pointers by disallowing pointer
arithmetics and instead providing runtime bound checking (slices)

\- garbage collection (this topic actually opens a can of worms of it's own,
regarding the placement of the language on the spectrum)

If you take C and add those features (instead of starting from another
language and removing the features, see Blub Paradox) it's more apparent that
it adds some value.

One could argue that the comparison with C misses the point, given that one of
the main reasons C is still alive and kicking is because of it's ubiquity and
the fact that its calling convention is the de facto standard of modern
operating systems, all of which is defeated by introducing a new language
(with a non-C calling convention!) that doesn't even aim at the level of
control (especially over memory allocation) that C gives.

However that's where Go's cultural roots are. Well, except for the concurrency
parts and other bits that were inspired from other languages, but when talking
about sorting or reducing arrays, that part stems from the C culture.

I have the feeling that one of the reasons Go is so successful, is that there
are many people who would actually like C but recognise what a giant time sink
can be to become proficient and write good quality software in it.

------
leonatan
Good article, but the "would of" ruined it for me. Did you not proof read it
even once to let such a horror through?

------
fiber
The most important point the author is missing is code readability - being
forced to write opinionated code is one thing. Having a chance to read
somebody elses code (or your own code 3 months later) and avoiding eternal
debate on code formatting is priceless. Programming is not about being able to
outsmart others, in particular not in a large-scale project.

~~~
sheepmullet
...every large scale project I've worked on has had a set coding standard and
supplied auto-format tools either as IDE plugins or as part of the checkin
procedure to make it easy to adhere to the standard.

------
NateDad
On my phone, but his examples just show that he's new to Go. He's using like
5x add much code as he needs to.

~~~
wwweston
Possible explanations:

* the author (and everyone else who complains about Go) simply hasn't made any appreciable investment in learning Go

* the language itself doesn't naturally lend itself to most programmers easily finding the most succinct/powerful expressions available, instead providing a grain that favors clarity over other values

* the documentation and tutorials available don't teach programmers how to write succinct and expressive Go

~~~
djhworld
> the language itself doesn't naturally lend itself to most programmers easily
> finding the most succinct/powerful expressions available, instead providing
> a grain that favors clarity over other values

I think that can be said of pretty much all programming languages.

------
east2west
T

------
ukigumo
hey man, don't say anything negative about the G. It goes on your permanent
record!

/s

edit: apparently sarcasm does not go unpunished. ah well.

------
bsaul
I've had a hard time making up my mind with generics vs interface in go, but i
think now that any compelling argument should be made using real world problem
from a real world project.

Nobody is coding the sum of a list of integers for all the various integer
types. People more likely use custom types anyway, and only have to create
operations on those custom types ( except maybe for go language designers
themselves). So there's always a suspicion that somehow there _should_ be a
way to code something clean using interfaces only.

~~~
kd0amg
_People more likely use custom types anyway, and only have to create
operations on those custom types ( except maybe for go language designers
themselves)._

People developing whole applications use custom types. People developing
libraries meant for general use seem to prefer not limiting their stuff to
working with their language's comparatively few built-in types (at least,
that's how things seem to go in languages with generics -- Guava's BloomFilter
should work with any type, even if that type was created well after Guava was
written).

~~~
bsaul
You're right, librairies developers are probably the one that should complain,
and yet go is also famous for having a really extremely convenient standard
lib (such as http), which means it should be possible. They are often built on
top of a tiny set of orthogonal interfaces rather than generic types (see
sort.Interface as an example of something quite low-level).

So that's why i'd like to see real-world problems that illustrate some
concrete examples.

~~~
kd0amg
It's no surprise that an HTTP library doesn't have issues with the lack of
generics -- it shuffles text around. Reusable data structures are the obvious
case for genericity, and I don't see many in the docs. Once you have a higher-
order language (whether via objects or first-class functions), some control
structures become data you might want to use generically. Looking over Java's
stuff also shows some interfaces one might want to parameterize over a type
(e.g., Comparable -- what can you compare this to?, Future -- what type will
we get from it?). Haskell also offers a lot of examples of really exercising
polymorphism (like lenses, but those maybe aren't appropriate for Go).

