2 ms·

Go: the only place in the known universe where you can find generics described as complex. Even though modern VB-programmers manage to deal with them just fine

Go: the only place in the known universe where you can find generics described as complex. Even though modern VB-programmers manage to deal with them just fine. So pardon my French, but what's the fucking issue? var typesafeListOfInts = new List<int>(); How is that hard?

pjmlp 9y ago
> Even though modern VB-programmers manage to deal with them just fine. Ironic, no?
tonyedgecombe 9y ago
Simple for Go developers is different to simple for the developers of Go.
majewsky 9y ago
The point is not List<int>. The point is that the primary intention of Go is to push developers to write the most readable (and hence, maintainable) code possible. No one argues that List<int> will not make the code more readable (and in fact, Go has some very limited generics for lists, maps and channels for these usecases). The problem is that once you give people parametrized types, they're going to parametrize the shit out of them, leading to byzantine messes such as the C++ standard library or Boost. And that's not saying that something like Boost isn't an accomplishment in itself. But it's beyond hard to read, and when your language allows to write code like that, it's bound to appear in your codebase as well, and make maintaining it much harder than it needs to be.
- josteink 9y ago
  > The point is that the primary intention of Go is to push developers to write the most readable (and hence, maintainable) code possible. Lack of parameterized types leads directly to code-duplication. How is duplicate code more maintainable? > The problem is that once you give people parametrized types, they're going to parametrize the shit out of them, leading to byzantine messes such as the C++ standard library or Boost. An extraordinary claim with no backing what so ever. Just because C++ turned out terrible doesn't mean everything else has to. Look to C# and Java. They're doing just fine. Also: how is littering your code with "interface { }" any less Byzantine than simply using "T"?

pjmlp 9y ago

> Even though modern VB-programmers manage to deal with them just fine. Ironic, no?

tonyedgecombe 9y ago

Simple for Go developers is different to simple for the developers of Go.

majewsky 9y ago

The point is not List<int>. The point is that the primary intention of Go is to push developers to write the most readable (and hence, maintainable) code possible. No one argues that List<int> will not make the code more readable (and in fact, Go has some very limited generics for lists, maps and channels for these usecases). The problem is that once you give people parametrized types, they're going to parametrize the shit out of them, leading to byzantine messes such as the C++ standard library or Boost. And that's not saying that something like Boost isn't an accomplishment in itself. But it's beyond hard to read, and when your language allows to write code like that, it's bound to appear in your codebase as well, and make maintaining it much harder than it needs to be.

josteink 9y ago
> The point is that the primary intention of Go is to push developers to write the most readable (and hence, maintainable) code possible. Lack of parameterized types leads directly to code-duplication. How is duplicate code more maintainable? > The problem is that once you give people parametrized types, they're going to parametrize the shit out of them, leading to byzantine messes such as the C++ standard library or Boost. An extraordinary claim with no backing what so ever. Just because C++ turned out terrible doesn't mean everything else has to. Look to C# and Java. They're doing just fine. Also: how is littering your code with "interface { }" any less Byzantine than simply using "T"?