41–50 of 116 posts
I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…
Earlier quoted context omitted.
I’m so conflicted about this comment because I have made nearly identical comments in the past. I think I’m going to have to change my stance on this point, however. There have been so many occasions that something about Go bothered me, and I then later discovered was a prerequisite to leveraging a much simpler programming model, that I am humbled by how much more I had to learn about programming. And I have to admit…
I feel like you're saying the criticism has to turn out right or wrong. I don't feel that's the case. A criticism is just an opinion (based on facts or not). Ignoring them will lead one way, addressing them another. Some people will like either one of them. I think criticism from people who stopped using X is a valid opinion even if it's ignored and if other people are happy it was ignored. You can't please everyone.
This was also the point I was driving at. I do respect the opinions of other developers outside of the Go community as well but as you said, you cannot please everyone. When many of the loudest critics were those who seemed to miss the point of Go or at least we're disinterested in the goals of Go, it got quite irritating to constantly read how "Go is terrible" when clearly it is a perfectly decent language for a great many developers. It's the same thing with the roadmaps, those who criticised it the most were often the developers who werent Go developers and thus didn't depend on the assurances Go offers.
Earlier quoted context omitted.
It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust... Also I see stuff like they should just use "perfectly fine existing para…
As you say " It seems most inspired by CLU". Do you happen to know by chance when CLU was created?
Note that Stroustrup proposed C++ concepts in 2003, and they still don't exist in C++, but they might be standardized by 2020.
Also note that CLU also didn't implement compile time specialization at all which is one of their core design requirements (for performance).
I don't think this is the particular prior art most of the "generics are easy" people are referring to, anyway.
It's maybe accurate to say that the Go team could have fairly easily done Java-style parameterized types (implemented via boxing everything like Java) and they chose not to do that. They chose not to do that mainly for performance reasons (and the hit would probably be worse in Go than Java since it's more value type oriented and doesn't have a JIT).
A lot of people here seem to value expressiveness above everything, but I think it's unsurprising that that Go didn't want to make those performance compromises, since it's trying to be an alternative to Java and C++ at Google-scale.
It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generi...
It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.
Earlier quoted context omitted.
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…
The Go team should have considered generics for Go 1.0 during the 0.x phase. It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like d…
It's not that they don't known how to write complicated programs under the hood and keep it simple outside.
They want to keep the programming language simple even under the hood where ever possible.
Consider implementing a feature in hurry just because many people were asking, one needs to maintain them for the rest of their life even if they hate it so much, because of backward compatibility.
It can also be the root cause for many problems.
If generics make language complicated, then it's better they don't implement it in the first place.
Earlier quoted context omitted.
Consider this function signature: func SomeAdditionFunction(arg1 int, arg2 int) { fmt.Println("Sum:", arg1 + arg2) } This function will only accept a pair of integers. In order to perform addition on floats or int64s or any other number type, you would need a separate function. Go has the concept of an empty interface (interface{}) which can accept any type. But this is not really a generic because you have to assert…
> In a language like Java, I could write this function to accept any type for which the + operator is valid, and it would still be type safe at compile time. I would not need to assert the types like I did above. Really? No. Not in Java. static void someAdditionFunction(T arg1, T arg2) { System.out.println("Sum:", arg1 + arg2); } "error: bad operand types for binary operator '+'"
Earlier quoted context omitted.
It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.
Not necessarily, specialisation is only argubly required for unboxed types. Java actually implements "Generics" without any specialisation at all, it boxes all the primitive types (rather controversially).
Earlier quoted context omitted.
Not necessarily, specialisation is only argubly required for unboxed types. Java actually implements "Generics" without any specialisation at all, it boxes all the primitive types (rather controversially).
And that has a baggage of problems. The best way is what C# does, which incidentally is also what Go does with maps: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
I actually quite like the Haskell approach of having a "Specialisation" annotation. I believe Scala has this too.
Earlier quoted context omitted.
As you say " It seems most inspired by CLU". Do you happen to know by chance when CLU was created?
To quote the entire sentence, "It seems most inspired by CLU and a proposed future C++ feature". Note that Stroustrup proposed C++ concepts in 2003, and they still don't exist in C++, but they might be standardized by 2020. Also note that CLU also didn't implement compile time specialization at all which is one of their core design requirements (for performance). I don't think this is the particular prior art most of…
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
https://go.googlesource.com/proposal/+/master/design/go2draf...
As for being an alternative to Java and C++ at Google-scale, all their major projects, with exception of Kubernetes, are mostly based on Java and C++.
I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…
Certainly I've seen my share of bizarre C++ template shenanigans (bad) but I've also been able to reuse other people's really well written container classes rather than roll my own, all with strong type safety (good).
Everyone will make their own decisions about generics. Personally I find the risk of "bad generics magic" to be more tolerable than "endless shitty workarounds for not having generics".