8 ms·

Interesting article. I think that using <> for the type specifiers would possibly be better! For example one could quickly end up with something like: func

by lsllc 6y ago

Interesting article. I think that using <> for the type specifiers would possibly be better! For example one could quickly end up with something like: func (obj *SomeType(Q, Z)) Foo(type K, V comparable)(key K, val V) (*OtherType(Q, V), error) { ... } ... Lots of Infuriating & Silly Parentheses?

monkeyfacebag 6y ago
On <> syntax, this has been discussed quite a bit. () were chosen to avoid ambiguous parsing. Also note that generic methods are not allowed in the current design, only generic functions. The new draft design ( https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des... ) discusses both of these points. I recommend everyone who is interested in this topic read the design spec, ideally before commenting.
- mdlayher 6y ago
  Exactly. Thanks!
- twblalock 6y ago
  On the <> syntax, why not improve the parser? Every language that uses <> for generics has a parser that is able to distinguish between generics and the "less than" operator, and it seems odd that Go developers think it can't be done efficiently.
  - 8192kjshad09- 6y ago
    Go developers like to claim that the reason the Go compiler is fast is because it's "simple to parse". Unfortunately this doesn't make a lot of sense as parsing is typically only 1-5% of the total compile time.
    - sacado2 6y ago
      It's not only about the main compiler. Go has tons of third-party tools (linters mainly) that can parse go code, because it's so easy to write one. Most of them wouldn't exist if parsing was a PITA.
      - Groxx 6y ago
        Those almost universally use the "ast" package provided by the stdlib.
  - monkeyfacebag 6y ago
    In my opinion, the new design doc clearly characterizes this as a design goal of the parser, rather than a hard constraint that cannot be resolved. "Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple." It's totally fair to question the tradeoff - should having a simple parser outweigh the potential ergonomic benefit of <>? I don't know. The forum for this is probably the golang-nuts group.
    - mpoteat 6y ago
      It's all a matter of where you accept the complexity - in the compiler, in the language, or in the downstream applications. In my view it's an obvious choice to choose a more complicated compiler on exchange for simpler downstream applications...
    - nemetroid 6y ago
      The design doc doesn't say "simple", it says "efficient". I think "simpler" would have been a stronger argument. While using <> would make the parser more complex, I have a hard time seeing that making a meaningful performance difference in a compilation context. Maybe if you're parsing a lot of Go without actually compiling it, but that doesn't seem like a use case to optimize for.
  - Sharlin 6y ago
    C++ and Rust require extra disambiguating syntax in some contexts (C++ the `foo.template bar<T>()` syntax, Rust the "superfish operator" `foo.bar::<T>()`. Java works around the problem by awkwardly putting the generic argument list in front of the method name (`foo.<T>bar()`). I don't know about C#.
    - steveklabnik 6y ago
      (teeny tiny note: turbofish, not superfish)
      - Sharlin 6y ago
        Oops :D
    - DougBTX 6y ago
      C# is `foo.bar<T>()`, I’m not sure what compromises that had to make for that to work but from an end-user perspective it works well.
      - oxnrtr 6y ago
        They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree. Basically, unlimited look-ahead.
        lostmsu 6y ago
        Is it somehow a problem?
    - oxnrtr 6y ago
      Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.
      - Sharlin 6y ago
  - qtplatypus 6y ago
    It is not a question of "Improve" but a question of dealing with tradeoffs. The Go parser is built so that at every stage it is totally unambiguous what the parser has to do. This reduces the amount of state that the parser has to carry around and makes the error messages for syntax errors easier to generate. Languages that use <>'s for generics have to look at a larger amount of the code when parsing to work out what to do.
  - apta 6y ago
    The golang approach has been to dumb down the parser, at the expense of making it more complex for users.
    - jatone 6y ago
      there is no complexity tradeoff for users here.
      - apta 6y ago
        Angle brackets are easier to parse for humans.
  - teleforce 6y ago
    The main reason is probably that by omitting <> for generics makes the symbol table unnecessary as part of the compilation stage. Go and D are the two modern languages that are avoiding symbol table like a plague for faster compilation time, i.e. the code should be parseabled without having to look things up in a symbol table .
- lsllc 6y ago
  Ah, right, I missed this: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#methods-may-not-take-additional-type-arguments https://go.googlesource.com/proposal/+/refs/heads/master/des... Hmmm ... not sure how I feel about that. Ok so my original example becomes this: func (obj *SomeType) Foo(type K, V, Q comparable)(key K, val V) (*OtherType(Q, V), error) { ... } Which is only slightly better [without the generic type]. Don't get me wrong, I'm a big fan of Go, but I'm kind of on the fence about generic types. I've made do with casting interfaces and type-casts for many years and I'm OK with it (honestly, glad to not be a C++ or Java programmer anymore).
  - mseepgood 6y ago
    > Ok so my original example becomes this No, you still don't understand. Methods can't have additional type parameters, only functions. This part is not allowed in your "example": (type K, V, Q comparable)
    - lsllc 6y ago
      The doc says: > Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without the type keyword or any constraint. So my original example should have been: func (obj *SomeType(K, V)) Foo(key K, val V) (*OtherType(K, V), error) { ... } (hopefully this is now correct!).
_ph_ 6y ago
I never have been able toi read the syntax with < > well, so I am soo happy they found some syntax based on parens. It is perfectly readable for me.
- nytgop77 6y ago
  After seeing and trying dlang syntax for generics I was hugely disappointed that rust chose angle brackets.
BurningFrog 6y ago
Now that unicode is everywhere I think it's time to use more brackets than [], (), {} and <>. Python is the worst, where dicts and sets both use {} and tuples and "grouping" both use (), each causing real problems. Some of many possibilities: ｟｠«» ⟦⟧ ⟨⟩ ⟪⟫ ⟮⟯ ⟬⟭ ⌈⌉ ⌊⌋ ⦇⦈ ⦉⦊ || Yes, you need a way to type it on non specialized keyboards. An easy way is is to type it as (( or [[ etc, and let the IDE convert it.
- hombre_fatal 6y ago
  To me this is the ultimate "developer chasing shiny" at the expense of everything else. Especially in the context of Go that hasn't even managed to use anything other than parentheses in its func definition syntax. No language has saturated the bracket options that come with the standard US keyboard so much that it's worth bringing in characters that you need additional tooling to type. If (), <>, {}, and [] aren't enough for a language, something has gone very wrong.
  - qtplatypus 6y ago
    While you normally don't regard it as a bracketing we also use "", '' and `` to bracket things. In Perl / / was used to bracket regrexs in C and many C languages /* */ is used to bracket comments.
- asjw 6y ago
  That's a lot of effort for little benefits I can already see a lot of edge cases Most notably font support I like ligatures and ide/editor support for them, but I'm not sure I like this
  - BurningFrog 6y ago
    The benefit is purely readability. You read code 1000x more often than you write it, so a little extra effort for even a small readability benefit is worth it. Most fonts have quite full Unicode support since many years. I'm often disappointed in how reluctant programmers are to use modern technology. The public thinks we're on the cutting edge of advanced technology. If they only knew :)
throw_m239339 6y ago
There is absolutely no way this gets the vocal "conservative" core of the Go community's approval. For better or worse.
- mseepgood 6y ago
  The <> people are the conservatives, because they are afraid to give new things a try. They want every programming language to look the same.
  - DaiPlusPlus 6y ago
    Consistency is important, though. Using C-family syntax makes it easy to get people to dip their toes into something within the spending time to learn a new syntax. Look at modern languages like Rust, Swift, Dart, and Go: they all use C-style syntax. I’m not accusing you of advocating Go’s adopting a different syntax for generics solely to be contrarian - but using angle-brackets for type-parameters and template-parameters is a proven technique with few downsides - and certainly not any that downsides that would be fixed by using any other syntax I’m aware-of.
    - rob74 6y ago
      Well, Go already picks and chooses elements from different languages, e.g. Pascal-style declarations ("x int" instead of "int x") and C-style blocks ("{...}" instead of "begin...end"). So I'm not surprised that when deciding on the syntax for generics they look more at what fits best for Go than at what other languages are doing...
      - DaiPlusPlus 6y ago
        I do prefer TypeScript’s version of Pascal-style declarations now. Though I really don’t like how Go doesn’t have a colon between the name and the type, it makes it harder to scan-through parameter lists when you aren’t using an editor with syntax colouring. (I had to write a lot of Go code in Notepad for a while in 2017 - never again)
sacado2 6y ago
I'm ready to bet that with <>, you'd introduce ambiguity in the grammar, making parsing code (and, as a consequence, writing tools for the language) much more complicated.
ramenmeal 6y ago
I agree, I think from a visual perspective the type declarations blend in with the rest of the type/function signature. I'm curious how quickly I'll get used to it.

by lsllc 6y ago

monkeyfacebag 6y ago

On <> syntax, this has been discussed quite a bit. () were chosen to avoid ambiguous parsing. Also note that generic methods are not allowed in the current design, only generic functions. The new draft design ( https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des... ) discusses both of these points. I recommend everyone who is interested in this topic read the design spec, ideally before commenting.

mdlayher 6y ago
Exactly. Thanks!
twblalock 6y ago
On the <> syntax, why not improve the parser? Every language that uses <> for generics has a parser that is able to distinguish between generics and the "less than" operator, and it seems odd that Go developers think it can't be done efficiently.
- 8192kjshad09- 6y ago
  Go developers like to claim that the reason the Go compiler is fast is because it's "simple to parse". Unfortunately this doesn't make a lot of sense as parsing is typically only 1-5% of the total compile time.
  - sacado2 6y ago
    It's not only about the main compiler. Go has tons of third-party tools (linters mainly) that can parse go code, because it's so easy to write one. Most of them wouldn't exist if parsing was a PITA.
    - Groxx 6y ago
      Those almost universally use the "ast" package provided by the stdlib.
- monkeyfacebag 6y ago
  In my opinion, the new design doc clearly characterizes this as a design goal of the parser, rather than a hard constraint that cannot be resolved. "Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple." It's totally fair to question the tradeoff - should having a simple parser outweigh the potential ergonomic benefit of <>? I don't know. The forum for this is probably the golang-nuts group.
  - mpoteat 6y ago
    It's all a matter of where you accept the complexity - in the compiler, in the language, or in the downstream applications. In my view it's an obvious choice to choose a more complicated compiler on exchange for simpler downstream applications...
  - nemetroid 6y ago
    The design doc doesn't say "simple", it says "efficient". I think "simpler" would have been a stronger argument. While using <> would make the parser more complex, I have a hard time seeing that making a meaningful performance difference in a compilation context. Maybe if you're parsing a lot of Go without actually compiling it, but that doesn't seem like a use case to optimize for.
- Sharlin 6y ago
  C++ and Rust require extra disambiguating syntax in some contexts (C++ the `foo.template bar<T>()` syntax, Rust the "superfish operator" `foo.bar::<T>()`. Java works around the problem by awkwardly putting the generic argument list in front of the method name (`foo.<T>bar()`). I don't know about C#.
  - steveklabnik 6y ago
    (teeny tiny note: turbofish, not superfish)
    - Sharlin 6y ago
      Oops :D
  - DougBTX 6y ago
    C# is `foo.bar<T>()`, I’m not sure what compromises that had to make for that to work but from an end-user perspective it works well.
    - oxnrtr 6y ago
      They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree. Basically, unlimited look-ahead.
      - lostmsu 6y ago
        Is it somehow a problem?
  - oxnrtr 6y ago
    Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.
    - Sharlin 6y ago
- qtplatypus 6y ago
  It is not a question of "Improve" but a question of dealing with tradeoffs. The Go parser is built so that at every stage it is totally unambiguous what the parser has to do. This reduces the amount of state that the parser has to carry around and makes the error messages for syntax errors easier to generate. Languages that use <>'s for generics have to look at a larger amount of the code when parsing to work out what to do.
- apta 6y ago
  The golang approach has been to dumb down the parser, at the expense of making it more complex for users.
  - jatone 6y ago
    there is no complexity tradeoff for users here.
    - apta 6y ago
      Angle brackets are easier to parse for humans.
- teleforce 6y ago
  The main reason is probably that by omitting <> for generics makes the symbol table unnecessary as part of the compilation stage. Go and D are the two modern languages that are avoiding symbol table like a plague for faster compilation time, i.e. the code should be parseabled without having to look things up in a symbol table .
lsllc 6y ago
Ah, right, I missed this: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#methods-may-not-take-additional-type-arguments https://go.googlesource.com/proposal/+/refs/heads/master/des... Hmmm ... not sure how I feel about that. Ok so my original example becomes this: func (obj *SomeType) Foo(type K, V, Q comparable)(key K, val V) (*OtherType(Q, V), error) { ... } Which is only slightly better [without the generic type]. Don't get me wrong, I'm a big fan of Go, but I'm kind of on the fence about generic types. I've made do with casting interfaces and type-casts for many years and I'm OK with it (honestly, glad to not be a C++ or Java programmer anymore).
- mseepgood 6y ago
  > Ok so my original example becomes this No, you still don't understand. Methods can't have additional type parameters, only functions. This part is not allowed in your "example": (type K, V, Q comparable)
  - lsllc 6y ago
    The doc says: > Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without the type keyword or any constraint. So my original example should have been: func (obj *SomeType(K, V)) Foo(key K, val V) (*OtherType(K, V), error) { ... } (hopefully this is now correct!).

_ph_ 6y ago

I never have been able toi read the syntax with < > well, so I am soo happy they found some syntax based on parens. It is perfectly readable for me.

nytgop77 6y ago
After seeing and trying dlang syntax for generics I was hugely disappointed that rust chose angle brackets.

BurningFrog 6y ago

Now that unicode is everywhere I think it's time to use more brackets than [], (), {} and <>. Python is the worst, where dicts and sets both use {} and tuples and "grouping" both use (), each causing real problems. Some of many possibilities: ｟｠«» ⟦⟧ ⟨⟩ ⟪⟫ ⟮⟯ ⟬⟭ ⌈⌉ ⌊⌋ ⦇⦈ ⦉⦊ || Yes, you need a way to type it on non specialized keyboards. An easy way is is to type it as (( or [[ etc, and let the IDE convert it.

hombre_fatal 6y ago
To me this is the ultimate "developer chasing shiny" at the expense of everything else. Especially in the context of Go that hasn't even managed to use anything other than parentheses in its func definition syntax. No language has saturated the bracket options that come with the standard US keyboard so much that it's worth bringing in characters that you need additional tooling to type. If (), <>, {}, and [] aren't enough for a language, something has gone very wrong.
- qtplatypus 6y ago
  While you normally don't regard it as a bracketing we also use "", '' and `` to bracket things. In Perl / / was used to bracket regrexs in C and many C languages /* */ is used to bracket comments.
asjw 6y ago
That's a lot of effort for little benefits I can already see a lot of edge cases Most notably font support I like ligatures and ide/editor support for them, but I'm not sure I like this
- BurningFrog 6y ago
  The benefit is purely readability. You read code 1000x more often than you write it, so a little extra effort for even a small readability benefit is worth it. Most fonts have quite full Unicode support since many years. I'm often disappointed in how reluctant programmers are to use modern technology. The public thinks we're on the cutting edge of advanced technology. If they only knew :)

throw_m239339 6y ago

There is absolutely no way this gets the vocal "conservative" core of the Go community's approval. For better or worse.

mseepgood 6y ago
The <> people are the conservatives, because they are afraid to give new things a try. They want every programming language to look the same.
- DaiPlusPlus 6y ago
  Consistency is important, though. Using C-family syntax makes it easy to get people to dip their toes into something within the spending time to learn a new syntax. Look at modern languages like Rust, Swift, Dart, and Go: they all use C-style syntax. I’m not accusing you of advocating Go’s adopting a different syntax for generics solely to be contrarian - but using angle-brackets for type-parameters and template-parameters is a proven technique with few downsides - and certainly not any that downsides that would be fixed by using any other syntax I’m aware-of.
  - rob74 6y ago
    Well, Go already picks and chooses elements from different languages, e.g. Pascal-style declarations ("x int" instead of "int x") and C-style blocks ("{...}" instead of "begin...end"). So I'm not surprised that when deciding on the syntax for generics they look more at what fits best for Go than at what other languages are doing...
    - DaiPlusPlus 6y ago
      I do prefer TypeScript’s version of Pascal-style declarations now. Though I really don’t like how Go doesn’t have a colon between the name and the type, it makes it harder to scan-through parameter lists when you aren’t using an editor with syntax colouring. (I had to write a lot of Go code in Notepad for a while in 2017 - never again)

sacado2 6y ago

I'm ready to bet that with <>, you'd introduce ambiguity in the grammar, making parsing code (and, as a consequence, writing tools for the language) much more complicated.

ramenmeal 6y ago

I agree, I think from a visual perspective the type declarations blend in with the rest of the type/function signature. I'm curious how quickly I'll get used to it.