

What Go Might Be Like With Generics - sentiental
http://play.golang.org/p/SL7mMdtDiM

======
Sir_Cmpwn
Is the only argument that Go users can come up with against generics is that
they don't like the syntax? The pretentious nature of the Go community really
puts me off from the language, especially when combined with some of the
pretentious designs of Go itself.

~~~
skybrian
No, the argument is that it's unclear how to fit it into the language.

Typically, generics are implemented using either code generation (causing code
bloat) or type erasure (which requires boxing the type). They're not satisfied
with either.

~~~
groovy2shoes
The "code generation = code bloat" argument really fails when you consider
that the code generated for a generic function is code that _would be written
by hand_ in the absence of generics.

Compare:

    
    
        map f [1, 2, 3]
        map g [1.0, 2.0, 3.0]
    

Versus:

    
    
        integer_map f [1, 2, 3]
        double_map  g [1.0, 2.0, 3.0]
    

In _both_ cases, you wind up with specialized versions of map (one for
Integers and one for Doubles). The benefit of the generic version is that the
programmer must only implement map once, and the compiler handles specializing
it for various types. Without generics, the programmer has to write the
specialized version for every type he needs the function for. This creates
more tedium for the programmer, and does _not_ reduce bloat in any way.

 _Caveat lector_ : Though my examples above are written in Haskell, I don't
have enough knowledge of GHC internals to know whether it performs
specialization this way. Nonetheless, it could be a reasonable approach for
Go.

~~~
burntsushi
It seems like you disagree with Russ Cox.[1] Unfortunately, I'm not familiar
enough with compilers to reconcile the disagreement. Any thoughts?

[1] - [http://research.swtch.com/generic](http://research.swtch.com/generic)

~~~
groovy2shoes
In this regard, C++ templates suffer from two problems. First, C++ templates
are far more general than just generic types (in fact, they're Turing
complete). Second, and the cause of lots of redundancy, is that C++ has no
module system. C++ has no module system, and instead relies on the linker to
provide functionality that could reasonably be provided at compile time given
a sufficient module system. I'd say that generics in Go could avoid both of
these problems: first by being _just_ generics, and second by leveraging the
module system.

Yes, generics will increase compile times. I seriously doubt it will increase
compile times by an integer multiple, and most people probably won't even
notice.

I'm not entirely sure what's going on that is causing the instruction cache to
be underutilized, but it seems to me that the only way to avoid it is to also
avoid abstraction in general. As usual, there's a tradeoff between performance
and maintainability -- that's nothing new. Pick the appropriate abstractions
for your use case.

Russ Cox is wrong in this case because his sample consists of one language:
C++. Go is not C++, so it's a mistake to assume it will suffer from the same
problems.

To get an idea of how generics could be reasonably implemented, take the Clay
programming language as an example:
[http://claylabs.com/clay/](http://claylabs.com/clay/)

------
f2f
is this trying to solve a particular problem or just pandering to the "... but
generics!" crowd of trolls?

because it doesn't look like it's solving anything, it feels positively ugly,
and there's no way we'll every shut those people up no matter how hard we try.
there's no generics solution that will do that.

thankfully go's authors don't usually favour the internet's opinion on these
matters, or we'd be dealing with something even uglier now.

~~~
girvo
People who want generics, to solve real problems, in Go are _trolls_?

Gosh that word has lost all meaning at this point.

~~~
f2f
<T>. they know who they are.

------
rollo
Eventually those who need static typing and parametric polymorphism will
switch to Haskell anyway, where both are done in a much better way, both
syntactically and implementation wise.

------
bvaldivielso
It is undeniable that generics are a quite demanded feature for golang.

We'll see how the language evolves, but I can't see them coming for a "long"
time.

~~~
MetaCosm
I fully support language specialization -- that is kinda the point, it all
ends up bits in the end. Rust is a completely different animal than Go yet I
think both are awesome!

The idea that all languages have to cater to all people is silly. Generics are
ALWAYS a trade-off. None is hard for developers, C++ style is terrible for
compile (tons of code-gen, macro crap, duplication, de-duplication stages),
and Java style (box-box-box-box) is slow at runtime.

The misunderstanding that generics are free and there lack of inclusion was an
oversight rather than a choice is misguided. The Go team aren't fresh faced
neophytes, they move with purpose.

Additionally -- if you want lots of features, there are LOTS of ways great
languages for you! Leave the small, crazy cadre of people who don't mind C,
think Lua is awesome and think Go is great to their (own) devices, we will be
OK.

~~~
p_random
you're awesome! you totally get the idea, people if the language does not fit
your needs move on!!!! I mean seriously making all the fuss about generics
even though that Go is being used in major projects (Cloudflare, UK.gov) yet
we see more people arguing that is not right.

I'm glad Rob Pike and Co. don't give a rats a __about such opinions.

------
chimeracoder
I have been writing Go daily at work for about a year and a half. It is now my
primary language, and my default choice for any new projects, the way Python
used to be. Before that, I come from a background in functional programming
(and still find functional programming to be my favorite paradigm).

It seems to me that there are two disjoint sets of people: those who write Go
regularly, and those who complain about generics in Go.

Of course, you can interpret this either way you wish!

1) Perhaps those latter people would like Go despite its lack of generics if
they only bothered to get familiar with idiomatic Go.

2) Perhaps the lack of generics is precisely what prevents them from writing
Go on a daily basis.

But as someone who actually does write Go on a daily basis, and has for a year
and a half, I can honestly say that I've only ever missed them a handful of
times. And I say this as a functional programmer who is used to being able to
call "map" everywhere.

In fact, if I had to prioritize the things that I wish I could change about
Go, generics would not be in the top three - not even in the top five[0].
They're just really something that I don't miss anymore.

[0] I could tell you what they are, but that'd be making it too easy - give Go
a shot, long enough to realize you really don't need generics as much as you
think you do, and then you'll probably have a good idea of the good, bad, and
ugly when it comes to Go.

~~~
ekidd
I've written several non-trivial Go programs, the most recent of which was a
server that solved substitution ciphers (for use in subtitle OCR).

I tried to write nice idiomatic Go code. And I'm usually pretty good at
adapting my brain to strange languages—I've positively enjoyed Haskell,
constraint programming in Mozart, distributed functional programming in
Elixir, and quite a few other strange things. (To be fair, I never did get
comfortable in Prolog.)

And try as I might, every time I write a couple thousand lines of Go, I walk
away in frustration. I love so much about the language, but my actual code
keeps disappearing under the weight of error handlers, and stupid little
iteration/transformation functions that I have to write over and over again
thanks to the lack of generics. (Sometimes I get lucky, and an interface fits
well.)

This means that every time I wander down a wrong path (and it's possible to
wander down quite a few when messing with OCR algorithms), I end up having to
tear up more code than I'd like. It's not fun.

Every time I say this, Go programmers say something like, _give Go a shot,
long enough to realize you really don 't need generics as much as you think
you do._ But after three serious attempts, it's clear that the programs in my
head were never meant to be implemented in Go. Which is too bad: It's a nice
language in so many ways.

~~~
MetaCosm
I have OCR in production live written in pure Go. It does OCR on small
specific portions of images to get keywords out to be put into a DB (1B+ page
scans). We use tesseract for full page scans (when needed, when our OCR
fails). But Go was so easy to write, and so fast to get live for small page
partials that we wrote it in a few weeks (idea to live, just implementing well
known algorithms) to avoid having to deal with tesseract overhead in the
average case.

I am curious about specifically where you got bound up -- and how we managed
to via ignorance or blind luck avoid these rough patches. Additionally, I am
not 100% sure I understand why you refactor cycle is so brutal. That generally
is one of the things I enjoy about Go, lightspeed refactor / dev / test
cycles.

Good thing no one is asking you to use Go, Haskell is always around (and
Elixir, I guess... I am too used to Erlang syntax, Elixir feels like an ill
fitting glove) and we need lots of great languages -- and they SHOULD feel
different and some shouldn't be a great fit for you.

------
fiorix
<T>errible to my eyes.

------
mseepgood
tl;dr: <T>

~~~
rogpeppe1
How about this instead?
[http://play.golang.org/p/hED7faR0q_](http://play.golang.org/p/hED7faR0q_)

------
embwbam
I use generics every day in typescript. I'm waiting to use go until it has
them.

------
reality_czech
I'm more interested in what Go might be like without whiners.

