3 ms·

"not bad" is a weird bar to cross for a language that: 1. decided generics is not needed 2. went on for a decade 3. implemented a version of it tha

by moelf 4y ago

"not bad" is a weird bar to cross for a language that: 1. decided generics is not needed 2. went on for a decade 3. implemented a version of it that is not performance-sensitive 3.5. $$ by google

deleted 4y ago
[deleted]
google234123 4y ago
Not sure how 3.5 follows.
- Beltalowda 4y ago
  And 1. is demonstrably false as has been stated a million times already.
  - erik_seaberg 4y ago
    If they had launched without supporting odd numbers, nobody would be saying “they always intended to add that later” in their defense.
  - tsimionescu 4y ago
    They demonstrably decided generics are not needed for Go at release, or for the following 5+ years, I don't know how that could be seen as false. If they had thought generics are required for Go, they wouldn't have released the language before they had them. What is often claimed instead, and is indeed false, is that they believed generics should not exist in Go. This is a position that many Go proponents take, but the designers of the language never did.
kgeist 4y ago
>decided generics is not needed >went on for a decade The FAQ on the official site already back in 2013 (I couldn't find an earlier snapshot on webarchive) stated they were open to adding generics but weren't sure how to properly design/implement them without overcomplicating the language, citing also other priorities. >implemented a version of it that is not performance-sensitive It's less performant than the ideal but it's a tradeoff to avoid exponential code bloat found in C++. In our large C++ project which extensively used templated boost.signals the code bloat from using templates alone added a whopping 200 MB of machine code which we were able to shed off by switching to our in-house library. IIRC C# uses an approach similar to Go to share generated code with some type-specific conditions at runtime (at least Mono I remember shared generic code for all reference types)
YesThatTom2 4y ago
The Go authors have never said #1: they said their waiting to decide how to best do it, and they want experience with the language to determine what problem needs to be solved before solving it #3: they’ve clearly said that they’re doing “get it right before you make it fast”.

by moelf 4y ago

"not bad" is a weird bar to cross for a language that: 1. decided generics is not needed 2. went on for a decade 3. implemented a version of it that is not performance-sensitive 3.5. $$ by google

deleted 4y ago

[deleted]

google234123 4y ago

Not sure how 3.5 follows.

Beltalowda 4y ago
And 1. is demonstrably false as has been stated a million times already.
- erik_seaberg 4y ago
  If they had launched without supporting odd numbers, nobody would be saying “they always intended to add that later” in their defense.
- tsimionescu 4y ago
  They demonstrably decided generics are not needed for Go at release, or for the following 5+ years, I don't know how that could be seen as false. If they had thought generics are required for Go, they wouldn't have released the language before they had them. What is often claimed instead, and is indeed false, is that they believed generics should not exist in Go. This is a position that many Go proponents take, but the designers of the language never did.

kgeist 4y ago

>decided generics is not needed >went on for a decade The FAQ on the official site already back in 2013 (I couldn't find an earlier snapshot on webarchive) stated they were open to adding generics but weren't sure how to properly design/implement them without overcomplicating the language, citing also other priorities. >implemented a version of it that is not performance-sensitive It's less performant than the ideal but it's a tradeoff to avoid exponential code bloat found in C++. In our large C++ project which extensively used templated boost.signals the code bloat from using templates alone added a whopping 200 MB of machine code which we were able to shed off by switching to our in-house library. IIRC C# uses an approach similar to Go to share generated code with some type-specific conditions at runtime (at least Mono I remember shared generic code for all reference types)

YesThatTom2 4y ago

The Go authors have never said #1: they said their waiting to decide how to best do it, and they want experience with the language to determine what problem needs to be solved before solving it #3: they’ve clearly said that they’re doing “get it right before you make it fast”.