1. 18
  1. 9

    I find the answers to the question “What language critical functions do you need that are not available in Go?” weird. Most of these seem to be convenience features (with the exception of Null Safety). I have the feeling this is because people want to force an existing style of programming onto a different language, instead of learning how to write idiomatic code in Go itself.

    1. 5

      I’m not sure. You can get far without generics (and I hope we’ll continue to write primarily without them), but I don’t see, say, data structures, as unidiomatic.

      Better error handling could or could not mean it’s idiomatic. For instance personally I’d be very fine with allowing one line if-statements. One line functions are allowed, so why not one line error check? You might disagree, but I would not consider that unidiomatic despite the loss of indentation.

      Stronger type system is something that’s pushed for in every language I’ve seen, and I’m not surprised to find it here too. I actually find that to be the biggest weakness of Go. Out of all the languages I use, Go has the weakest type system.

      1. 2

        I think you’re right, better error handling and stronger type safety are probably seen in the same way as null safety.

      2. 4

        Another possibility, and I’m not saying this is a majority of the responses or anything, is that people now have large systems written in Go that need maintenance and moving away from what is considered “idiomatic” Go is, for them, just pragmatism.

        I worked for a company that had a lot of Go code and most of the developers had pretty much decided they didn’t like Go because of the experiences they’d had writing and maintaining that software. Most new stuff was being written in Java and Kotlin instead, but the Go code still needed to be maintained. I could see those folks asking for new features that they feel will help ease their maintenance burden (whether they will or not, who knows).

        That being said, are those really the people the Go team should be listening to? Probably not. But I don’t know how to tell who is who.

        1. 1

          How is it pragmatic? I’m genuinely curious what this would mean, as I haven’t had that much experience with large Go code-bases yet.

          1. 3

            It’s pragmatic to want to change a language if you don’t like working in that language but you also can’t NOT work in that language (because you’ve got legacy code to maintain). That’s all I meant. My first sentence was a little unclear, in retrospect.

            1. 2

              Go is refactoring-hostile. Java is refactoring-friendly. In my opinion.