4 ms·

I think the author was actually referring to the fact that it makes the written software using Go more complex to understand and maintain. Quoting: "...efforts

by grok2 9y ago

I think the author was actually referring to the fact that it makes the written software using Go more complex to understand and maintain. Quoting: "...efforts to add templated types and immutability to the language would unlock the ability to write more complex, less readable software. Indeed, the addition of these features would have a knock on effect that would profoundly alter the way error handling, collections, and concurrency are implemented."

i_don_t_know 9y ago
It's not clear to me how templated types and immutability inevitably lead to more complex and less readable software. Can you or someone else explain?
- catnaroek 9y ago
  Templates have a very complex semantics, because they are checked at instantiation time and can be specialized anywhere. Fortunately, parametric polymorphism and templates have nothing to do with each other. :-)
- grok2 9y ago
  I think it's perhaps a reference to the original intent of Go at Google. They want new joinees to be quickly productive and also be able to write problem free software (and maybe maintain a lot of old software in addition to writing new software). Having more advanced language features is perhaps not conducive to this. Features like templates do take a bit more effort to grok and also take a bit more effort to understand the flow of code when maintaining software.
  - deleted 9y ago
    [deleted]
- taeric 9y ago
  Anecdotally, there seems to be a giant rush to get everything covered in generics when people first start learning them. So, what could have been a short section of code that did its job well, is now a larger portion of code that doesn't quite do what anyone wants and you can find yourself just doing a dance with the generic types. I do not know of any studies that explore this concept at large. I would be interested in them.
- rst 9y ago
  Well, you've got two choices about how you want usage of user-implemented generic container types to look: 1) there are no parameters on the container types, every usage involves a cast to or from 'void*', 'interface{}', or the equivalent, and usage is effectively not type-checked. 2) there are parameters on the container types, subsequent usage isn't cluttered up with uninformative type-casts, and the types get checked by the compiler. These lead to the same code at runtime (or can, in a Java-style implementation of generics); however, the Go maintainers seem to act as if the first is more maintainable and less error-prone. That seems ... odd, to some of us. (There are other possible implementations of generics, of course. In fact, another post by the same author, [1], lists "everything is boxed" as a bad outcome that he'd like to avoid, in favor of specialized implementations for containers of, say, characters. But scenario 1, the Go status quo, effectively requires that everything be boxed when using a generic container type written the only way the language allows you to write them. Scenario 2 at least potentially gives the compiler other options. But the Go status quo doesn't avoid the "everything is boxed" bad outcome. Instead it mandates it -- with additional compile-time clutter.) [1] https://research.swtch.com/generic https://research.swtch.com/generic
- douche 9y ago
  As a primarily .NET developer, I think I can count on two hands the number of times that I've needed to actually write my own generic types. Generic functions are maybe slightly more common, but still pretty rare. However, if I had a penny for every time I've taken advantage of the generic collections built into the standard library, instead of using the old shitty, type-unsafe ArrayList or HashTable collections, I wouldn't have to work for the rest of my life. .Net generics are more limited than full C++ style templates, or maybe I've been lucky enough to never encounter any code where people have gone overboard with them, but that seems to be a pretty sweet spot.

by grok2 9y ago

i_don_t_know 9y ago

It's not clear to me how templated types and immutability inevitably lead to more complex and less readable software. Can you or someone else explain?

catnaroek 9y ago
Templates have a very complex semantics, because they are checked at instantiation time and can be specialized anywhere. Fortunately, parametric polymorphism and templates have nothing to do with each other. :-)
grok2 9y ago
I think it's perhaps a reference to the original intent of Go at Google. They want new joinees to be quickly productive and also be able to write problem free software (and maybe maintain a lot of old software in addition to writing new software). Having more advanced language features is perhaps not conducive to this. Features like templates do take a bit more effort to grok and also take a bit more effort to understand the flow of code when maintaining software.
- deleted 9y ago
  [deleted]
taeric 9y ago
Anecdotally, there seems to be a giant rush to get everything covered in generics when people first start learning them. So, what could have been a short section of code that did its job well, is now a larger portion of code that doesn't quite do what anyone wants and you can find yourself just doing a dance with the generic types. I do not know of any studies that explore this concept at large. I would be interested in them.
rst 9y ago
Well, you've got two choices about how you want usage of user-implemented generic container types to look: 1) there are no parameters on the container types, every usage involves a cast to or from 'void*', 'interface{}', or the equivalent, and usage is effectively not type-checked. 2) there are parameters on the container types, subsequent usage isn't cluttered up with uninformative type-casts, and the types get checked by the compiler. These lead to the same code at runtime (or can, in a Java-style implementation of generics); however, the Go maintainers seem to act as if the first is more maintainable and less error-prone. That seems ... odd, to some of us. (There are other possible implementations of generics, of course. In fact, another post by the same author, [1], lists "everything is boxed" as a bad outcome that he'd like to avoid, in favor of specialized implementations for containers of, say, characters. But scenario 1, the Go status quo, effectively requires that everything be boxed when using a generic container type written the only way the language allows you to write them. Scenario 2 at least potentially gives the compiler other options. But the Go status quo doesn't avoid the "everything is boxed" bad outcome. Instead it mandates it -- with additional compile-time clutter.) [1] https://research.swtch.com/generic https://research.swtch.com/generic
douche 9y ago
As a primarily .NET developer, I think I can count on two hands the number of times that I've needed to actually write my own generic types. Generic functions are maybe slightly more common, but still pretty rare. However, if I had a penny for every time I've taken advantage of the generic collections built into the standard library, instead of using the old shitty, type-unsafe ArrayList or HashTable collections, I wouldn't have to work for the rest of my life. .Net generics are more limited than full C++ style templates, or maybe I've been lucky enough to never encounter any code where people have gone overboard with them, but that seems to be a pretty sweet spot.