4 ms·

> I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stabl

> I feel like the general attitude of software developers is: if it isn’t changing and being updated it’s dying. I think we should start putting weight on stable unchanging software. I agree with this. However, the key is to stop once you've implemented the right set of features. Minimalism is about implementing the minimum necessary and no less. I firmly believe that generics are in the right set of features for a statically-typed programming language. The problem is that Go has already implemented some features which clearly aren't in the right set of features--such as `go generate`--which already allow you to implement a crappy version of generics. So now you're starting to move toward the problem that C++ and (to a lesser extent) JavaScript have, which is that there are 5 different ways to do the same thing, which don't necessarily interoperate well with each other. If go were being implemented from scratch, it would be better to have generics and not `go generate`, but given the language already has `go generate`, there's certainly some downside to adding generics. It's not a simple choice.

pjmlp 6y ago
The irony of go generate is that a similar approach was taken by C++ compilers back in the early days. To give a proper example, Borland C++ 1.0 for MS-DOS had BIDS, so their own collections library with safe strings and vectors, as it happened with all major C++ vendors back in the day. Well BIDS 1.0 used pre-processor tricks to generate the desired code, basically you would define the desired types and then include the data structure you cared about, and do this multiple times. Eventually templates came into the picture and BIDS 2.0 shipped with a template version, based on the ongoing discussions at ISO. We are talking about 1990 here. As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away.
- kerkeslager 6y ago
  The basic problem I see with Go is that its users are ignorant of how other languages have solved (or failed to solve) problems. > As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away. Well, that's somewhat true, but there are two ways to adapt while avoiding the problem of having 5 slightly different and incompatible ways to do the same thing: 1. Pick a good set of language features up front and stick to them, devoting further development efforts to a strong standard library rather than language features. Example: Erlang. 2. Break reverse compatibility and remove things. Example: Python.
  - pjmlp 6y ago
    Agreed, although from the point of view of languages as software products, Erlang seems to be around just to support Elixir, and Python took an heavy bill by going that way.
throw_m239339 6y ago
"go generate" is an half assed macro feature that shouldn't even part of any modern language. Even C has better macro... And it has absolutely nothing to do with genericity, your argument is a fallacy. If Go really wanted to be open, then Go designers should just have created a virtual machine and let everybody code their own language on top. Go right now is just basically C with garbage collection. Only C developers love that, and Go designers are well aware that it is an hindrace to adoption in enterprise. The pressure to change seldom comes from the community at large, but Google itself and big corps using Go.
- kerkeslager 6y ago
  > "go generate" is an half assed macro feature that shouldn't even part of any modern language. Agreed. > And it has absolutely nothing to do with genericity, your argument is a fallacy. In arguments against adding generics, it's been cited numerous times that you can achieve similar code reuse via macros. It's been a while since I looked at the awfulness of `go generate` so I'm not going to attempt to demonstrate the equivalency with that syntax, but here's how you'd achieve something similar to genericity with macros in C: Instead of: T swap<T>(T* left, T* right) { T temp = left; *left = *right; *right = temp; } ... int a = 1, b = 2; char c = 'c', d = 'd'; swap<int>(&a, &b); swap<char>(&c, &d); You do: #declare_swap_function(T) T swap_ ## T(T* left, T* right) {\ T temp = left;\ *left = *right;\ *right = temp;\ } ... declare_swap_function(int); declare_swap_function(char); ... int a = 1, b = 2; char c = 'c', d = 'd'; swap_int(&a, &b); swap_char(&c, &d); So, macros do have something to do with genericity. Macros are certainly a crappy way to achieve genericity, however, especially since the original reason go didn't include generics was to compile in a single pass, and adding a preprocessor adds another pass. It's clear you were ignorant here. That's fine--I don't expect you to know everything. But I think it's reasonable to expect that if you don't know what someone is talking about, you approach the conversation with some humility and ask questions before accusing someone of a logical fallacy. Ignorance is fine, arrogance isn't.
mseepgood 6y ago
> such as `go generate`--which already allow you to implement a crappy version of generics The design document for "go generate" listed many motivating use cases, and not one of them was generics. The raison d'être for "go generate" is not to simulate generics. Some people just saw the character sequence "gener..." and made it about generics.

pjmlp 6y ago

The irony of go generate is that a similar approach was taken by C++ compilers back in the early days. To give a proper example, Borland C++ 1.0 for MS-DOS had BIDS, so their own collections library with safe strings and vectors, as it happened with all major C++ vendors back in the day. Well BIDS 1.0 used pre-processor tricks to generate the desired code, basically you would define the desired types and then include the data structure you cared about, and do this multiple times. Eventually templates came into the picture and BIDS 2.0 shipped with a template version, based on the ongoing discussions at ISO. We are talking about 1990 here. As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away.

kerkeslager 6y ago
The basic problem I see with Go is that its users are ignorant of how other languages have solved (or failed to solve) problems. > As for the 5 different ways, that is the sin of the languages that start small as a counter movement without understanding that the others are complex not because it is fun to make them complex, rather because languages are products like anything else in software, and either they adapt to their customer base or they fade away. Well, that's somewhat true, but there are two ways to adapt while avoiding the problem of having 5 slightly different and incompatible ways to do the same thing: 1. Pick a good set of language features up front and stick to them, devoting further development efforts to a strong standard library rather than language features. Example: Erlang. 2. Break reverse compatibility and remove things. Example: Python.
- pjmlp 6y ago
  Agreed, although from the point of view of languages as software products, Erlang seems to be around just to support Elixir, and Python took an heavy bill by going that way.

throw_m239339 6y ago

"go generate" is an half assed macro feature that shouldn't even part of any modern language. Even C has better macro... And it has absolutely nothing to do with genericity, your argument is a fallacy. If Go really wanted to be open, then Go designers should just have created a virtual machine and let everybody code their own language on top. Go right now is just basically C with garbage collection. Only C developers love that, and Go designers are well aware that it is an hindrace to adoption in enterprise. The pressure to change seldom comes from the community at large, but Google itself and big corps using Go.

kerkeslager 6y ago
> "go generate" is an half assed macro feature that shouldn't even part of any modern language. Agreed. > And it has absolutely nothing to do with genericity, your argument is a fallacy. In arguments against adding generics, it's been cited numerous times that you can achieve similar code reuse via macros. It's been a while since I looked at the awfulness of `go generate` so I'm not going to attempt to demonstrate the equivalency with that syntax, but here's how you'd achieve something similar to genericity with macros in C: Instead of: T swap<T>(T* left, T* right) { T temp = left; *left = *right; *right = temp; } ... int a = 1, b = 2; char c = 'c', d = 'd'; swap<int>(&a, &b); swap<char>(&c, &d); You do: #declare_swap_function(T) T swap_ ## T(T* left, T* right) {\ T temp = left;\ *left = *right;\ *right = temp;\ } ... declare_swap_function(int); declare_swap_function(char); ... int a = 1, b = 2; char c = 'c', d = 'd'; swap_int(&a, &b); swap_char(&c, &d); So, macros do have something to do with genericity. Macros are certainly a crappy way to achieve genericity, however, especially since the original reason go didn't include generics was to compile in a single pass, and adding a preprocessor adds another pass. It's clear you were ignorant here. That's fine--I don't expect you to know everything. But I think it's reasonable to expect that if you don't know what someone is talking about, you approach the conversation with some humility and ask questions before accusing someone of a logical fallacy. Ignorance is fine, arrogance isn't.

mseepgood 6y ago

> such as `go generate`--which already allow you to implement a crappy version of generics The design document for "go generate" listed many motivating use cases, and not one of them was generics. The raison d'être for "go generate" is not to simulate generics. Some people just saw the character sequence "gener..." and made it about generics.