

The Evolution of Go - beliu
https://sourcegraph.com/blog/live/gophercon2015/123645585015

======
coldtea
> _Generics is the single biggest language feature absent in Go. It’s often
> missed by newcomers to Go. But it’s more of a type-system mechanism. It’s
> unclear if it’s an essential language feature._

Oh, it's clear by now. Though "essential" is a weasel word -- in a way nothing
is essential in the sense you can do it all with assembler too.

> _Generics are incredibly complex in both semantics and implementation. There
> are considerable trade-offs to consider, such as do you want a larger binary
> vs. slower binary vs. larger source code._

Unless I use them, I get none of those downsides. And when I need them, I now
have to implement support for my types manually, which results in larger
source code anyway.

And "larger source code" hasn't been a problem since 1980.

> _Language features without competition: goroutines, interfaces, defer (now
> in Swift)_

Those have been around in several other languages... Hardly "without
competition".

> _Tools without competition: fast compiler_

It's fast because it's not doing much. And there are several compilers that
are fast too.

~~~
4ydx
Yes and they made a conscious decision to not include so much in the language
in order to make the compiler fast so your criticism is rather odd. They made
a choice. It results in a faster compiler. And yet your comment comes across
as if this is somehow unfounded praise. Nonetheless we have all come to love
your "get-off-my-lawn" sort of approach to criticising golang at this point, I
suppose :)

~~~
coldtea
> _Yes and they made a conscious decision to not include so much in the
> language in order to make the compiler fast so your criticism is rather odd.
> They made a choice. It results in a faster compiler._

The null compiler (which produces nothing) is even faster, but 1000s of orders
of magnitude.

As you can see I'm not in favor of the choices they made to make the compiler
fast.

It's not much of a feat -- it's like writing a 8-bit era like game, and
bragging that it gets 2000 fps performance.

First, after 60 fps it's dimminishing returns anyway, and second, yes, but at
what cost?

------
panamafrank
The thing about Go is that there isn't all that much to talk about, any
mention of it induces a "channels are awesome" comment or a "there's no
generics :'(" conversational nadir.

I think eventually it'll be complete, with only the occasional maintenance
patch.

------
vanessa98
He had me at "It’s unclear if it’s [generics] an essential language feature"

~~~
AnimalMuppet
I wonder if "generics + traits" (where C++ is trying to go) is essentially the
same as "no generics + interfaces" (Go's version of the same thing, maybe?)

Edit: On reflection, "traits" is probably the wrong word. C++ has a word for
this, but I'm drawing a blank at the moment.

~~~
coldtea
>* I wonder if "generics + traits" (where C++ is trying to go) is essentially
the same as "no generics + interfaces" (Go's version of the same thing,
maybe?)*

It's the same end result, but without the speed and the type checking of
proper Generics.

(Assuming you mean "empty interfaces" (interface{}). Else, regular interfaces
are not the same thing as Generics.

> _On reflection, "traits" is probably the wrong word. C++ has a word for
> this, but I'm drawing a blank at the moment._

Templates?

~~~
AnimalMuppet
No. Concepts? It's a way of saying "for your type T to use this template, T
must inherit from X, or support these operations, or some other restriction".
It lets you have a template that takes a type T, but not just any type T will
do. For example, if you have a templated sort function, the restriction might
be that T must have a < operator.

Now, in Go, you don't have generics. But you can have a sort function that
takes a type (interface) that means "something that has a less-than function",
and because of the way Go does OO, anything that has that function works.

This doesn't get Go to the point of having templates that will take any type
whatsoever (unless you use empty interfaces).

I feel like I'm still using the wrong word in one or two places. But I hope
this is more clear than my previous comment.

~~~
coldtea
> _No. Concepts? It 's a way of saying "for your type T to use this template,
> T must inherit from X, or support these operations, or some other
> restriction". It lets you have a template that takes a type T, but not just
> any type T will do. For example, if you have a templated sort function, the
> restriction might be that T must have a < operator._

Yeah, that would be Concepts. IIRC, C++ doesn't have them landed yet.

> _Now, in Go, you don 't have generics. But you can have a sort function that
> takes a type (interface) that means "something that has a less-than
> function", and because of the way Go does OO, anything that has that
> function works._

Yeah, you can have that. But the benefit of generics is that the "things that
fit that function" are auto-generated.

~~~
AnimalMuppet
> Yeah, that would be Concepts. IIRC, C++ doesn't have them landed yet.

I also believe that C++ doesn't have them yet.

> But the benefit of generics is that the "things that fit that function" are
> auto-generated.

But because of the way that Go interfaces are in essence duck typed, "things
that fit that function" are also auto-generated, other than having to specify
the interface that must be satisfied. To me, this seems like no more work than
specifying the C++ concept. (Or am I still missing something?)

~~~
coldtea
> _But because of the way that Go interfaces are in essence duck typed,
> "things that fit that function" are also auto-generated, other than having
> to specify the interface that must be satisfied. To me, this seems like no
> more work than specifying the C++ concept. (Or am I still missing
> something?)_

No, you have to write their code (concrete implementation for a new type)
manually.

The only thing that's automatic is that the new implementation is "registered"
as compatible with the interface without you having to explicitly declare it
(e.g. not like Java that needs you to write "extends IFoo").

~~~
AnimalMuppet
Sorry, I'm not _trying_ to be dense, but:

> No, you have to write their code (concrete implementation for a new type)
> manually.

Say we're talking about a sort function. Are you saying that I have to write
both sort(Foo) and sort(Bar), rather than simply writing
sort(SomeInterfaceSharedByFooAndBar)?

I presume you're not just saying that I have to write the code for Foo and
Bar; I don't know of anything that will save me from that.

------
throwaway999666
> As a graduate student, he studied with Niklaus Sweet, creator of Pascal.

Niklaus _Sweet_ , fucking seriously?

~~~
dang
Everyone makes mistakes. Please don't be uncivil on HN.

