5 ms·

> C doesn't have them and is arguably the most successful language in history. I'm not sure "C didn't have it" is a good litmus test for determining the value

> C doesn't have them and is arguably the most successful language in history. I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason. > Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. Conversely, proponents of generics would argue that not having them creates complexity for software developers who have to come up with alternative design patterns where generics would be a better fit. > Personally, the proposal I was most excited about was to make ints be arbitrary precision by default. Why would you want that? C doesn't have it... ;)

gautamcgoel 6y ago
Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the benefits of generics are outweighed by the cost of their complexity.
- CarelessExpert 6y ago
  First: I ninja-edited my comment after the fact with a thought that occurred to me after I posted, so apologies there. Anyway, yeah, no argument there at all. I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part of its overall design ethos. But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.
  - loopz 6y ago
    Well, then you also know he just didn't see any good implementations of generics, yet. Let's hope this gets good!
- cies 6y ago
  Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics. What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.
  - Cyph0n 6y ago
    Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language. If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?
    - piinbinary 6y ago
      And a separate copy of `append` for every possible type :)
    - cies 6y ago
      Exactly. It was IMHO pretty authoritarian to say "you dont need generics" and then use it yourself in the standard lib. But then Go is not a public place: it's private domain of Google. I decided long time ago I dont want to learn a private tool without being paid.
matheusmoreira 6y ago
> I'm not sure "C didn't have it" is a good litmus test for determining the value of features It can be a good test. One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces. Adding features to languages almost always increases the complexity of these binary interfaces. Eventually they become so complicated that nothing will ever interoperate with software written in these languages. The increased language complexity reduces the reusability of software produced in that language. C++ had this problem and Rust is following in its footsteps. Rust libraries are really only reused within the Rust ecosystem. Those that are meant to be universally reusable will no doubt offer a simple ABI that lacks all the benefits of the Rust language.
- pjmlp 6y ago
  UNIX ABI.

gautamcgoel 6y ago

Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the benefits of generics are outweighed by the cost of their complexity.

CarelessExpert 6y ago
First: I ninja-edited my comment after the fact with a thought that occurred to me after I posted, so apologies there. Anyway, yeah, no argument there at all. I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part of its overall design ethos. But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.
- loopz 6y ago
  Well, then you also know he just didn't see any good implementations of generics, yet. Let's hope this gets good!
cies 6y ago
Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics. What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.
- Cyph0n 6y ago
  Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language. If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?
  - piinbinary 6y ago
    And a separate copy of `append` for every possible type :)
  - cies 6y ago
    Exactly. It was IMHO pretty authoritarian to say "you dont need generics" and then use it yourself in the standard lib. But then Go is not a public place: it's private domain of Google. I decided long time ago I dont want to learn a private tool without being paid.

matheusmoreira 6y ago

> I'm not sure "C didn't have it" is a good litmus test for determining the value of features It can be a good test. One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces. Adding features to languages almost always increases the complexity of these binary interfaces. Eventually they become so complicated that nothing will ever interoperate with software written in these languages. The increased language complexity reduces the reusability of software produced in that language. C++ had this problem and Rust is following in its footsteps. Rust libraries are really only reused within the Rust ecosystem. Those that are meant to be universally reusable will no doubt offer a simple ABI that lacks all the benefits of the Rust language.

pjmlp 6y ago
UNIX ABI.