3 ms·

One area in which Go lacks is its static type system. Until recently, it was practically straight out of the '70s. Static type systems are a mechanism for outla

One area in which Go lacks is its static type system. Until recently, it was practically straight out of the '70s. Static type systems are a mechanism for outlawing the compilation of programs that are known to be problematic at the expense of outlawing comparatively few good programs — a worthwhile trade-off for a language meant to be used in industry, especially when writing complicated code. It's a shame because they absolutely could have built a better type system on the backs of all the advancements of the past half-century, but deliberately chose not to due to what I can only see as being the perspective of people who had only previously used obnoxious static type system (e.g., Java's) and decided "well we don't want that, and 'that' means types, so let's provide as inexpressive a type system as possible."

Jabbles 4y ago
Are you responding to the parent's post and suggesting that this is something to do with Go's success, or are you simply complaining?
- DonaldPShimoda 4y ago
  Ah, you're absolutely right. I rewrote some parts of my comment a few times and accidentally removed the bit that actually connected it haha. My point was that Go seems to have managed to be successful (for some reasonable definitions of "successful") despite at least one large deficiency. In fact, it is the same deficiency for which Java's success can be said to be surprising, though Java had ~20 years fewer history to draw upon. (Java is relevant because it's what the parent comment was comparing Go to.) It is disappointing to me that Go had a really good position to provide a new language in a specific niche, but they squandered at least one significant aspect of the language design due to (in my opinion) a lack of knowledge in the relevant area. This despite being designed by "experts at the top of their field", as the parent comment noted.
  - wahern 4y ago
    > they squandered at least one significant aspect of the language design due to (in my opinion) a lack of knowledge in the relevant area. Why do you believe the reason was lack of knowledge?
  - AnimalMuppet 4y ago
    One of HN's guidelines is "charitable assumption". It specifically is required toward other posters. But you might extend that charity to Go's creators. They actually were experts at the top of their field. Assuming a lack of knowledge is both uncharitable and, frankly, arrogant. It would be better to assume that they made choices other than the ones you would have made, and did so with eyes wide open and full knowledge.
  - dgb23 4y ago
    You can safely assume that there was no such thing as lack of knowledge about type systems and language design.
everybodyknows 4y ago
This has bitten me many times. In particular: Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. An expression a.b in some unfamiliar code may denote either a struct field access, or a pointer dereference followed by struct field access. We must read surrounding code (or lean on an IDE) to know which is meant. There was a lot to be said for C's -> operator, however unaesthetic it may appear to the eye.
- k0k0r0 4y ago
  About that slice indexing problem I wrote a bug-report for the language specification like two years ago. The language specification itself is not clear about what types can be used as indices. Accepting int32 and similiar could be regarded as a feature of the compiler. The problem was recognized (like a year later), but then claimed to be fixed and simply ignored. Immediately, I wrote a follow-up issue providing a concrete example how the spec could be improved. No response to that, yet. Now another year has passed.
  - morelisp 4y ago
    What's wrong with "the index x must be an untyped constant or its core type must be an integer"? ("Integer" in turn being defined by enumeration in the "Numeric types" section.)
- morelisp 4y ago
  > Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. What actually-used language did this in the 70s? What other major languages offer this today? I know it's useful, but dunking on Go for features only C++ (and Rust?) have is offensively far from GP's claim.
morelisp 4y ago
Wow, I’ve never heard this bullshit before.
lenkite 4y ago
More type theory heaviness === grand compile time. There is a natural correlation. Go chooses dev efficiency here over comprehensive type checking.
- DonaldPShimoda 4y ago
  I think minimizing compile time is a weird metric to prioritize. It's essentially asking "Would I rather guarantee my program is more correct or save a few seconds each time I compile?" I would also point out that not forbidding bugs that would be caught by a type-checker will decrease efficiency. You just won't realize it when it happens. Lastly, the impact on compile time doesn't have to be so great to be problematic. Plenty of languages with more expressive type systems have reasonable compile times. Some do not, I agree, but I'm not asking Go to leap to the forefront of type theory... I just think they could've done better.
  - morelisp 4y ago
    > Would I rather guarantee my program is more correct or save a few seconds each time I compile? Iterating faster is also a way to improve the odds your program is correct.
    - DonaldPShimoda 4y ago
      There is no inherent link between "number of successful compilations" and "program correctness". There is an inherent link between "the program type-checks" and "program correctness", because a successful type-check specifically means that a certain subset of syntactically valid programs have been thrown out due to being potentially problematic.
- pjmlp 4y ago
  Not really, have a go at it with Delphi, Nim or D, for example.
pjmlp 4y ago
The wrong corner of the 70's, given that CLU and ML were born in the 70's.

Jabbles 4y ago

Are you responding to the parent's post and suggesting that this is something to do with Go's success, or are you simply complaining?

DonaldPShimoda 4y ago
Ah, you're absolutely right. I rewrote some parts of my comment a few times and accidentally removed the bit that actually connected it haha. My point was that Go seems to have managed to be successful (for some reasonable definitions of "successful") despite at least one large deficiency. In fact, it is the same deficiency for which Java's success can be said to be surprising, though Java had ~20 years fewer history to draw upon. (Java is relevant because it's what the parent comment was comparing Go to.) It is disappointing to me that Go had a really good position to provide a new language in a specific niche, but they squandered at least one significant aspect of the language design due to (in my opinion) a lack of knowledge in the relevant area. This despite being designed by "experts at the top of their field", as the parent comment noted.
- wahern 4y ago
  > they squandered at least one significant aspect of the language design due to (in my opinion) a lack of knowledge in the relevant area. Why do you believe the reason was lack of knowledge?
- AnimalMuppet 4y ago
  One of HN's guidelines is "charitable assumption". It specifically is required toward other posters. But you might extend that charity to Go's creators. They actually were experts at the top of their field. Assuming a lack of knowledge is both uncharitable and, frankly, arrogant. It would be better to assume that they made choices other than the ones you would have made, and did so with eyes wide open and full knowledge.
- dgb23 4y ago
  You can safely assume that there was no such thing as lack of knowledge about type systems and language design.

everybodyknows 4y ago

This has bitten me many times. In particular: Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. An expression a.b in some unfamiliar code may denote either a struct field access, or a pointer dereference followed by struct field access. We must read surrounding code (or lean on an IDE) to know which is meant. There was a lot to be said for C's -> operator, however unaesthetic it may appear to the eye.

k0k0r0 4y ago
About that slice indexing problem I wrote a bug-report for the language specification like two years ago. The language specification itself is not clear about what types can be used as indices. Accepting int32 and similiar could be regarded as a feature of the compiler. The problem was recognized (like a year later), but then claimed to be fixed and simply ignored. Immediately, I wrote a follow-up issue providing a concrete example how the spec could be improved. No response to that, yet. Now another year has passed.
- morelisp 4y ago
  What's wrong with "the index x must be an untyped constant or its core type must be an integer"? ("Integer" in turn being defined by enumeration in the "Numeric types" section.)
morelisp 4y ago
> Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. What actually-used language did this in the 70s? What other major languages offer this today? I know it's useful, but dunking on Go for features only C++ (and Rust?) have is offensively far from GP's claim.

morelisp 4y ago

Wow, I’ve never heard this bullshit before.

lenkite 4y ago

More type theory heaviness === grand compile time. There is a natural correlation. Go chooses dev efficiency here over comprehensive type checking.

DonaldPShimoda 4y ago
I think minimizing compile time is a weird metric to prioritize. It's essentially asking "Would I rather guarantee my program is more correct or save a few seconds each time I compile?" I would also point out that not forbidding bugs that would be caught by a type-checker will decrease efficiency. You just won't realize it when it happens. Lastly, the impact on compile time doesn't have to be so great to be problematic. Plenty of languages with more expressive type systems have reasonable compile times. Some do not, I agree, but I'm not asking Go to leap to the forefront of type theory... I just think they could've done better.
- morelisp 4y ago
  > Would I rather guarantee my program is more correct or save a few seconds each time I compile? Iterating faster is also a way to improve the odds your program is correct.
  - DonaldPShimoda 4y ago
    There is no inherent link between "number of successful compilations" and "program correctness". There is an inherent link between "the program type-checks" and "program correctness", because a successful type-check specifically means that a certain subset of syntactically valid programs have been thrown out due to being potentially problematic.
pjmlp 4y ago
Not really, have a go at it with Delphi, Nim or D, for example.

pjmlp 4y ago

The wrong corner of the 70's, given that CLU and ML were born in the 70's.