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.
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.
>* 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.
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.
>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.
> 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?)
>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").
> 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.
>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.
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 :)
>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?
15 comments
[ 2.7 ms ] story [ 40.7 ms ] threadNiklaus Sweet, fucking seriously?
I think eventually it'll be complete, with only the occasional maintenance patch.
Edit: On reflection, "traits" is probably the wrong word. C++ has a word for this, but I'm drawing a blank at the moment.
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?
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.
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.
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?)
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").
> 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.
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.
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?