1. 4
  1.  

  2. 9

    First of all, I hate angle brackets, so that’s why I use square ones.

    Not sure that’s actually a great reason to be different from every other language in the same family.

    1. 3

      Angle brackets need shift, square brackets don’t. Some languages like Scala use square brackets. I miss them when I’m writing Rust.

      1. 5

        This is a very anglo-centric way of thinking about a design issue, no? I use a French Canadian keyboard layout, and I need to use shift for angle brackets and AltGr for square brackets.

        1. 1

          Most programming languages are written in English, which is very unfortunate, now that I think about it.

          1. 1

            I don’t really think it’s unfortunate. Compared to other fields we are lucky that it uses the (current) “world language”. We don’t have to deal with French, Ancient Greek, Latin, etc.

            Also having programming languages written in a random natural language means that they will have a hard time gaining popularity and probably means that the already stuffed, missing out on important things[1] study of computer science would require classes in natural languages.

            However, I agree that everything involving Alt Gr is horrible and a reason why programmers and system administrators sometimes get English language keyboards. Examples of characters requiring Alt Gr for many people are:

            @ [ ] { } | \ ~
            

            So if you care about these (based on German keyboards), you might want to avoid excessive use. There is also shift, but that’s way easier and probably very hard to entirely avoid.

            [1] I think computer science needs something along the lines of history class as mistakes get repeated or hacks that have been overcome get introduced into new designs. But that’s off topic, so not going to elaborate on this.

            1. 1

              I don’t really think it’s unfortunate. Compared to other fields we are lucky that it uses the (current) “world language”. We don’t have to deal with French, Ancient Greek, Latin, etc.

              It’s unfortunate for the French and Greek, not for us.

      2. 2

        While not identified in the OP, there is actually a good reason for it.

        See the first point on https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md#a-note-on-syntax

        1. 2

          This is Go we’re talking about. They’re intentionally needlessly different on many fronts already.

        2. 8

          The syntax discussion is the least interesting part of the whole feature. The post does nothing to raise properties of the semantics, which are far more important, and more interesting.

          1. 9

            Yet another “Go needs generics because Go does not have generics” post that is shallow on analysis, pro and con. The actual Go 2 process will be much more in depth. I see no need to address this topic until then unless someone takes the time to go deeper than every other post over the last several years.

            1. 1

              Does go 2 process has already some kind of result appart the blog post announcing it?

            2. 3

              There was a pretty detailed set of four proposals, and why none of them really work, discussed last year by the Go team. I think the bar at this point is to be able to argue that either a new proposal is superior in a way that lets it sidestep those problems, or else that there is a good reason the original rejection of those proposals was misguided.

              1. [Comment removed by author]

                1. 1

                  Reminds me of the assembler guy that told me years ago that it was all anyone needed to program.

                  1. 1

                    I disagree on this comparison - if you meant it as such.

                    Many people who switched to Go used either languages with support for generics or dynamic languages. It’s also not a form of caring too much about performance, memory usage, etc. It’s actually one less thing to remember.

                    So it’s more like “Why doesn’t everyone use Java, JavaScript, Ruby or Perl” for example (all of them having a very big feature set).

                    Since Go is rather new it’s certainly not a “the old thing is good enough” or “I don’t want to learn something new” kind of thinking.

                    That said. I am not really opposed to generics in general, even though I was surprised how well programming in Go works, even without generics. I frequently read that others have a similar experience, where in the beginning it seems like a language without support for generics will probably something that’s hard to deal with in the long run when used to them, however it doesn’t take too long until the initial “How do I do generics? There are none?!” turns into more of a “Why did I ever need generics?”.

                    Of course that’s not a full truth and there certainly are cases where generics would be very nice to have. However, these cases end up being very rare in reality, when you use Go in an idiomatic way.