6 ms·

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and

by ryeguy 8y ago

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large chunk of the community coming from dynamically typed languages. In which case they're just have a negative reaction to unfamiliarity.

ramenmeal 8y ago
I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.
- bmon 8y ago
  If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed. This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.
  - atilaneves 8y ago
    If you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/ https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.
- ryeguy 8y ago
  But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.
  - stcredzero 8y ago
    If the choice is between badly implemented generics, and having the problem manifested as userland code, I'll take the latter. I've actually had to debug C++ production code produced by the confluence of templates that had no source code of it's own. At least with boilerplate, you can simply see what's going on right there.
erikpukinskis 8y ago
Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most code is not that, and will be handed off to novices over and over for fixes. So, it’s a question of whether you cater to the advanced developer who can capably handle a vast toolset, or do you commit as a community to more rudimentary tools, in order to reap the rewards of systemic simplicity. There is no right answer. I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level. Go, EZ-Go, C, EZ-C, etc I am writing all of my code in EZ-JS
- closeparen 8y ago
  It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.
  - themihai 8y ago
    >> It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. That's not the case anymore. We have C++ which has generics and "fixed" C's lack of complexity for sure...Now for some 'weird' reasons some people still use C. Wonder why ?
    - wbl 8y ago
      Compare C++ to Standard ML. Simplicity is compatible with generics.
    - pjmlp 8y ago
      It is not the case since 1993, when CFront was dropped. In certain domains like UNIX like OSes, I don't see C ever going away, due to the infrastructure, symbiotic relation with the OS that gave it birth, and the culture.
IshKebab 8y ago
It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comments/5nifpm/they_said_rust_error_messages_with_generics_are/ https://www.reddit.com/r/rust/comments/5nifpm/they_said_rust... That's what people don't want.
- int_19h 8y ago
  Any sufficiently advanced type system can be used for compile-time metaprogramming - that's just an inevitable side effect of a type system expressive enough to capture all the more convoluted (but still plenty common) cases without hacks like interface{}.
- johncolanduoni 8y ago
  That's not compile time metaprogramming at all, it's just series of wrapped closures. It's basically the sequence of function call names preceding that call backwards, with different capitalization.
- deleted 8y ago
  [deleted]
- majewsky 8y ago
  The big difference between C++ and Rust is that, when you scroll down in this Reddit thread, it shows that the Rust guys have a clear path for fixing this issue, whereas there is no fix for this in C++ (that I'm aware of).
- glangdale 8y ago
  Ha ha, "10 line error". [ Puts on Monty Python voice] "What I wouldn't give for a 10 line error..." Incautious use of the template mechanism - or just a minor typo - has given me couple screenfuls in the past.
Anaminus 8y ago
For me at least, the reluctance comes from the new proposal process not having yet proved itself for large backwards-incompatible features. I want to be assured that a Go with generics is a Go with a really well-integrated feature, and not some grafted mutant appendage whose only real purpose is to appease the greater community. It's great that they're trying out the process on smaller, more simple proposals. My hope is that this system will either produce really good features, or reveal that there are simply no satisfying solutions.
libria 8y ago
I'm of 2 minds. I come from a Java background so I've personally wanted generics. ORM's are 1 use case that comes to mind. But. There are many modern languages that already have generics. Why can't Go be that one that doesn't cave in and remains powerful in its niche and perhaps may never be the preferred tool in other areas? Why must it be useful for web development, microservices, DAL, etc.? Any implementation of generics in Go will come with complexity tradeoffs. I feel like the community learns more about languages and software engineering when we maintain language diversity and see the pros and cons of each approach in practice. I want generics for selfish reasons, but would also like to see how a modern strongly-typed language solves problems without it.
- idle_zealot 8y ago
  As someone who quite likes generics, I'd love to see how a modern strongly-typed language solves problems without them. And I think that's what the Go community and developers have been trying to do up until now. It looks like they're giving up. I'm not sure whether we'll ever find another way to tackle composition/scalability as effectively as generics do, but such a technique would be fascinating to see.
cdoxsey 8y ago
Although ultimately I do want generics in Go I am afraid they will make the language more difficult to use and understand. Generics in c++, c#, scala, java, etc all tend toward being very complex and change the way programs are written. The focus moves towards a taxonomy of types and developers (myself included) sometimes get stuck on difficult type problems. There's something about trying to preserve type safety which sets the bar extremely high for bypassing the type system when there's not an easy solution and before you know it you've wasted 2 or 3 days writing code which doesn't actually do anything but placate the compiler. And often that type-safe concoction you create is almost indecipherable when you come back to it later. For example here's a project I worked on recently which cached a concrete version of a generated method using generics: https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/Datadog.Trace.ClrProfiler.Managed/DynamicMethodBuilder.cs#L28 https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/... Used like this: var originalMethod = DynamicMethodBuilder<Func<object, byte[][], object, object, bool, T>> .GetOrCreateMethodCallDelegate( redisNativeClient.GetType(), "SendReceive", methodGenericArguments: new[] { typeof(T) }); At least for me that was really hard to figure out how to do and I still have to squint to see what the heck its doing. The non-generic version wasn't type-safe and it wasn't as fast, but it sure was a lot easier to read and understand. And to give some sense of the complexity involved, Rob Pike mentioned in his talk that the proposal spec for adding generics to Go is longer than the spec for the entire language. I think the complexity is worth it, but I just hope we can be cautious about how and where generics get used in real-world code, otherwise we'll end up with gobbledy-gook that only experts can decipher... and that would be really sad, because the promise of Go was a language normal engineers could be productive with.
- delhanty 8y ago
  >Generics in c++, c#, scala, java They're not all the same though are they. C++/CLI had both compile-time generics (templates) from C++, and run-time generics from the CLR. And they could be complementary at times. For compile-time generics, Dlang are a lot more sane that C++, having had the benefit of coming later, and dumping C compatability. Similarly, CLR (C#, ...) generics had the benefit of being designed having seen Java first, so IIRC they're baked into the CLR. CKR generics were derived from work done at MS Research Cambridge, and I seem to remember Don Syme (F# creator) being rather proud of them. Disclosure: I was contracting at MSR Cambridge back in 2007. Anyway, the golang designers will be aware of these implementations, so hopefully they'll come up with a nice design.
kminehart 8y ago
I'll answer from my perspective. I don't hate generics. I see the value of generics, especially after having worked with Go for so long; I've had to do some mental gymnastics to get around not having proper generic collections. That being said, I'm not excited about seeing generics in other people's code. The added complexity doesn't really solve problems I have anymore. That being said, I'm actually way less excited about overloading. I think generics and function overloading is going to make me think "where the hell is this coming from?" a lot more often and then I'm going to need to load it up in my IDE, or vim with way too many plugins, and start following definitions.
icholy 8y ago
Coming up with a complex solution is much easier than finding a simple one. Go forces you to find those simple solutions. There are places where generics are the only solution, but they also enable lazy design.

by ryeguy 8y ago

ramenmeal 8y ago

I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.

bmon 8y ago
If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed. This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.
- atilaneves 8y ago
  If you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/ https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.
ryeguy 8y ago
But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.
- stcredzero 8y ago
  If the choice is between badly implemented generics, and having the problem manifested as userland code, I'll take the latter. I've actually had to debug C++ production code produced by the confluence of templates that had no source code of it's own. At least with boilerplate, you can simply see what's going on right there.

erikpukinskis 8y ago

Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most code is not that, and will be handed off to novices over and over for fixes. So, it’s a question of whether you cater to the advanced developer who can capably handle a vast toolset, or do you commit as a community to more rudimentary tools, in order to reap the rewards of systemic simplicity. There is no right answer. I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level. Go, EZ-Go, C, EZ-C, etc I am writing all of my code in EZ-JS

closeparen 8y ago
It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.
- themihai 8y ago
  >> It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. That's not the case anymore. We have C++ which has generics and "fixed" C's lack of complexity for sure...Now for some 'weird' reasons some people still use C. Wonder why ?
  - wbl 8y ago
    Compare C++ to Standard ML. Simplicity is compatible with generics.
  - pjmlp 8y ago
    It is not the case since 1993, when CFront was dropped. In certain domains like UNIX like OSes, I don't see C ever going away, due to the infrastructure, symbiotic relation with the OS that gave it birth, and the culture.

IshKebab 8y ago

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comments/5nifpm/they_said_rust_error_messages_with_generics_are/ https://www.reddit.com/r/rust/comments/5nifpm/they_said_rust... That's what people don't want.

int_19h 8y ago
Any sufficiently advanced type system can be used for compile-time metaprogramming - that's just an inevitable side effect of a type system expressive enough to capture all the more convoluted (but still plenty common) cases without hacks like interface{}.
johncolanduoni 8y ago
That's not compile time metaprogramming at all, it's just series of wrapped closures. It's basically the sequence of function call names preceding that call backwards, with different capitalization.
deleted 8y ago
[deleted]
majewsky 8y ago
The big difference between C++ and Rust is that, when you scroll down in this Reddit thread, it shows that the Rust guys have a clear path for fixing this issue, whereas there is no fix for this in C++ (that I'm aware of).
glangdale 8y ago
Ha ha, "10 line error". [ Puts on Monty Python voice] "What I wouldn't give for a 10 line error..." Incautious use of the template mechanism - or just a minor typo - has given me couple screenfuls in the past.

Anaminus 8y ago

For me at least, the reluctance comes from the new proposal process not having yet proved itself for large backwards-incompatible features. I want to be assured that a Go with generics is a Go with a really well-integrated feature, and not some grafted mutant appendage whose only real purpose is to appease the greater community. It's great that they're trying out the process on smaller, more simple proposals. My hope is that this system will either produce really good features, or reveal that there are simply no satisfying solutions.

libria 8y ago

I'm of 2 minds. I come from a Java background so I've personally wanted generics. ORM's are 1 use case that comes to mind. But. There are many modern languages that already have generics. Why can't Go be that one that doesn't cave in and remains powerful in its niche and perhaps may never be the preferred tool in other areas? Why must it be useful for web development, microservices, DAL, etc.? Any implementation of generics in Go will come with complexity tradeoffs. I feel like the community learns more about languages and software engineering when we maintain language diversity and see the pros and cons of each approach in practice. I want generics for selfish reasons, but would also like to see how a modern strongly-typed language solves problems without it.

idle_zealot 8y ago
As someone who quite likes generics, I'd love to see how a modern strongly-typed language solves problems without them. And I think that's what the Go community and developers have been trying to do up until now. It looks like they're giving up. I'm not sure whether we'll ever find another way to tackle composition/scalability as effectively as generics do, but such a technique would be fascinating to see.

cdoxsey 8y ago

Although ultimately I do want generics in Go I am afraid they will make the language more difficult to use and understand. Generics in c++, c#, scala, java, etc all tend toward being very complex and change the way programs are written. The focus moves towards a taxonomy of types and developers (myself included) sometimes get stuck on difficult type problems. There's something about trying to preserve type safety which sets the bar extremely high for bypassing the type system when there's not an easy solution and before you know it you've wasted 2 or 3 days writing code which doesn't actually do anything but placate the compiler. And often that type-safe concoction you create is almost indecipherable when you come back to it later. For example here's a project I worked on recently which cached a concrete version of a generated method using generics: https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/Datadog.Trace.ClrProfiler.Managed/DynamicMethodBuilder.cs#L28 https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/... Used like this: var originalMethod = DynamicMethodBuilder<Func<object, byte[][], object, object, bool, T>> .GetOrCreateMethodCallDelegate( redisNativeClient.GetType(), "SendReceive", methodGenericArguments: new[] { typeof(T) }); At least for me that was really hard to figure out how to do and I still have to squint to see what the heck its doing. The non-generic version wasn't type-safe and it wasn't as fast, but it sure was a lot easier to read and understand. And to give some sense of the complexity involved, Rob Pike mentioned in his talk that the proposal spec for adding generics to Go is longer than the spec for the entire language. I think the complexity is worth it, but I just hope we can be cautious about how and where generics get used in real-world code, otherwise we'll end up with gobbledy-gook that only experts can decipher... and that would be really sad, because the promise of Go was a language normal engineers could be productive with.

delhanty 8y ago
>Generics in c++, c#, scala, java They're not all the same though are they. C++/CLI had both compile-time generics (templates) from C++, and run-time generics from the CLR. And they could be complementary at times. For compile-time generics, Dlang are a lot more sane that C++, having had the benefit of coming later, and dumping C compatability. Similarly, CLR (C#, ...) generics had the benefit of being designed having seen Java first, so IIRC they're baked into the CLR. CKR generics were derived from work done at MS Research Cambridge, and I seem to remember Don Syme (F# creator) being rather proud of them. Disclosure: I was contracting at MSR Cambridge back in 2007. Anyway, the golang designers will be aware of these implementations, so hopefully they'll come up with a nice design.

kminehart 8y ago

I'll answer from my perspective. I don't hate generics. I see the value of generics, especially after having worked with Go for so long; I've had to do some mental gymnastics to get around not having proper generic collections. That being said, I'm not excited about seeing generics in other people's code. The added complexity doesn't really solve problems I have anymore. That being said, I'm actually way less excited about overloading. I think generics and function overloading is going to make me think "where the hell is this coming from?" a lot more often and then I'm going to need to load it up in my IDE, or vim with way too many plugins, and start following definitions.

icholy 8y ago

Coming up with a complex solution is much easier than finding a simple one. Go forces you to find those simple solutions. There are places where generics are the only solution, but they also enable lazy design.