Go 2 is being drafted.
If you haven't heard, there will be a few major language changes coming to Go 2. The Go team has recently submitt...
For further actions, you may consider blocking this person and/or reporting abuse
To be honest I do not see semantic difference between interfaces and generics. The only difference is that generics have always been resolved in compile time, interfaces in run-time.
I'd prefer to extend semantics of standard interfaces that allows to use built-in types as interfaced object and add something like
staticmodificator to interfaces that will say to compiler to resolve/convert functions and stucts in compile time.I always have supposed that issue of generics in Go is that it makes compilation complicated and broke main feature of Go, very fast compilation.
Looking back at this, I realize that I didn't really respond to this properly.
There really aren't many "modifiers" in Go. This is because Go really wants the simplest type system possible. The current type system is extremely straightforward.
Interfaces are resolved at compiletime as well as runtime. For instance, you cannot assign a struct to an interface type if the struct does not implement the interface.
If you want to assert that a struct implements an interface, you can put
var _ = InterfaceType(StructType{})as a package level variable. I personally don't like this practice but it gets the job done.Generics in Go will compile quickly, it is one of their main goals. They believe that generics really won't be used much anyway, because there are very few problems that they really solve. There are also very few features in Go generics because Go's type system is so simple. All of these things together show that compile times in Go should still be extremely short, even with generic types.
Hi... I'm not sure that I told something special about Go generics proposal... Actually I agree with Rob that usefulness of generics is overestimated. Including generics/templates in C++ standard have just opened Pandora's box. Look at implementation of the simpliest template
std::vectorin GCC (man std::vector). It didn't look simple at all. For most of nowadays' programmers it looks at it as at dark evil magics. After all of that C++ cannot be considered as simple programming language.About 'static resolution' of golang's interfaces... You are right. Sure, they are no fully run-time resolved. I just tried to simplify the way to explain my idea. It looks like it was not reach the goal.
Golang compilation is quickly now. But look at
std::vectorimplementation one more time. You should notice how many additional conceptions will be added to make it really generics (batch of traits, additional types and adoption objects). I'm far enough to think that guys from Standard committee of C++ didn't try to simplify all of it. But we have what we have now. So...Anyway the time is the best judge and teacher. Let's look what it will be turned to...
C++ is just a bad implementation of Generics in my opinion. Everyone uses it as an example of a mistake. So I'll fully agree with you on that front.
Also, I agree with Rob too. There really aren't many problems that Generics solve, but there are a few things that they solve that are extremely useful. The nice thing about Go's implementation is it's not meant to be some big complicated system. But yes - we'll see how they turn out.
To be honest I cannot agree that generics in C++ is a bad implementation. I suppose it's just a real price you should pay for this "real generics". Sure, you can move the implementation from STDLIB/STL to under hood of compilator, but it changes nothing. In the same way you can never look at the implementation of STL and consider them as well-done. Most C++ programmers does it in this way.
Look at the examples I have provided. There is no generalized, type-safe way to implement them without generics
Yikes, the syntax is uglier than I had feared.
Parens for everything. Everything looks like a function call.
I guess if you take an ugly language and glob on more features, it can only get uglier.
IMO they should redesign the whole syntax to something more traditional. I’ve heard the argument that they designed the syntax so the compiler would be fast - I’ve always thought that was nonsense. Plenty of compilers with a more traditional syntax are just as fast or faster than Go.
I like the ideas of Go a lot. It’s a shame it has to be so hard to read...
I think that the idea is that it should look like a function call. So calling something like
Sum(int)would be a "function call" that returns afunc ([]int) intI agree that it's a lot of parentheses in the definition, but hopefully type inference is good enough that the parentheses aren't needed much at the call site, if at all.
Looks to me that. No. Like some java crap that distracts what language should do, instead doing it. They should not keep it just simple but micro service simple; rather than including monolith concepts. Maybe looking even more to python direction than Java.
Can they please use <> for types just like Java or C++? These paranthesis are not readable!
The idea behind their parentheses are that it should act like a function - calling
Max(int32)returns afunc(int32, int32) int32. To call this function, one could doMax(int32)(x, y), or with type inference,Max(x, y)will work fine.Then to declare a function that takes type parameters, it should ideally look similar to calling it:
func Max(type T)(i1, i2 T) T.That is the justification for all of the parentheses. I'm not sure if I entirely agree with it, but I'm not against it.