1. 28
  1.  

  2. 50

    This isn’t a particularity interesting read - it doesn’t say anything that hasn’t been said a thousands times already by more informed sources, and seems to be based on some very subjective measures, and some (objectively) wrong claims.

    On formatting:

    According to my opinion, a programming language should let a developer use his or her style. A heavy influence on the programmer’s style is okay, but a fanactic, religious-like enforcement is inacceptable.

    That’s a great opinion to have if you never work with anyone else, but it doesn’t work at scale, which is one of the key design principals for Go.

    On broken package management: Go does have issues with package management - it’s very much a weak spot. Vendoring is the official workaround, and whilst it’s not perfect, it does work.

    On the lack of inheritance, the author doesn’t seem to mention type composition which is one of my favourite features of Go and frankly sounds like the solution to the very vague issue they’re describing. I’ve always found composition to be much more powerful than inheritance so I’m not sure what the author’s issue is here.

    I’m not going to bother addressing generics.

    This is also the first time I’ve ever heard anyone call Go’s built in HTTP package “lacking” because it doesn’t come with helper functions for a REST library…? Go’s standard library is excellent, and the HTTP package is one of the best parts of it.

    1. 10

      The HTTP library complaint really threw me too, because it seems to imply that other languages have more features in their standard HTTP libraries. In Python or Ruby if you wanted to write a similar web server as what you could with Go’s (basically just simple routes that do things) you’d have to grab a package like Flask or Sinatra, because the base language doesn’t support things like that.

      It just seems like a complaint because the author wanted to complain. If you’re pointing out something bad in about the core libraries, and then comparing it to a third-party library in another language, you’re not making a fair comparison.

      1. 6

        On broken package management: Go does have issues with package management - it’s very much a weak spot. Vendoring is the official workaround, and whilst it’s not perfect, it does work.

        I am using a combination of GNU make and goland/dep for every new Go project and I and my coworkers are pretty happy with it. Here is the project template I use if anyone is interested. To summarize, go dep and other tools like gopm and glide make package management pretty easy, thus it is not a real issue anymore.

        1. 5

          I’m not saying you’re wrong, but there is real value in having one blessed package / dependency management system that everyone in an ecosystem uses. That’s one of my biggest complaints with the JavaScript community, there are 10 different tools to solve every problem and they change regularly.

          1. 4

            dep is, or will be, that blessed tool.

        2. 3

          Among other things, he doesn’t mention what he’s using instead, which doubtless has tradeoffs of its own.

          1. 5

            I feel like the OP is a significantly better read than your reply. You assert that it’s all been said before, but then later say that the post makes surprising and novel claims. You decry subjective measures, but your entire reply has no meaningful backup for any of its arguments. You state that there’s objectively wrong claims (in an opinion post about programming!), but then don’t say what they are. You refuse to even address an argument the guy makes. Frankly, your post is awful.

            1. 15

              I feel like the OP is a significantly better read than your reply.

              One is a comment, the other is a blog article. I feel like the Financial Times is a significantly better read than your reply but making that comparison would be absurd.

              You assert that it’s all been said before, but then later say that the post makes surprising and novel claims.

              Of the valid criticisms of Go in the post (package management, lack of generics), there are literally thousands of well written and well informed articles describing the issues and possible solutions, the vast majority of them are better reads and more informative. These are very well known issues to anyone who has ever read about Go.

              The complaint about code formatting is made regularly and dismissed by the vast majority of people, “Go can’t do X because it lacks inheritance” is wrong and occurs frequently enough to have a section in the official Go FAQ. Perhaps I should have written “Of the things the article doesn’t get entirely wrong, it says nothing which hasn’t been said a thousands times before”?

              You decry subjective measures, but your entire reply has no meaningful backup for any of its arguments.

              I’m not going to re-write what has been written thousands of times before on matters that have been discussed to death and which I can add nothing original. I could tear into almost everything written in the post, but I have better things to do (unlike you, perhaps?)

              You state that there’s objectively wrong claims

              The post claims: “Go forces me to maintain the same code in three different places.” because it lacks inheritance. This is objectively wrong. The author doesn’t seem to know about type composition, which as I said, would likely solve the issue he was describing.

              The post claims: “The Go compiler is repressively enforcing a mix of Google’s C++ and Python style guidelines.” and proceeded to give examples of syntax errors which occur because the compiler has rules about where you put newlines. You can style Go however you want: you can can have (brackets) around if statements, you can end lines with semicolons, but it doesn’t need either of these things. You can do whatever you want if you follow the syntax, which isn’t that strict:

              package main
              
              func main() {
                      if(1 + 1 == 2) { println("hello");
                      } else if 1+5 == 6 {
                              println("goodbye")
                      } else {
                              println("string" +
                             "concatenation") }
              }
              

              That’s valid Go code. You’ll note, for example, the new line between concatenated strings, something the post claims isn’t allowed.

              Most editors will run go fmt because it provides a consistent format for all Go code and is required by most Go projects before they will accept code. To claim that the compiler “repressively enforces” Google’s C++ and Python style guide because it uses newlines as part of the language syntax is wrong.

              Frankly, your post is awful.

              I’m glad you enjoyed it, but frankly I couldn’t care less what you thought of it. Perhaps you could trying adding to the discussion next time rather than simply criticising my response? There are a million ways you could have made the same points without framing it as an attack on my post, yet that’s all you did. Frankly, I find your attitude to be awful, but I wouldn’t have wasted time on it if it hadn’t been aimed at me.

          2. 19

            A fine enough opinion piece, but misinformed on a few points of fact…

            The Go compiler is repressively enforcing a mix of Google’s C++ and Python style guidelines

            No, it isn’t. It enforces the Go lexical parsing rules.

            [Vendoring dependencies] is an anti pattern of using a VCS.

            No, it isn’t. It’s one of several dependency management strategies, and it’s the only way to ensure truly reproducible builds.

            Interfaces help to solve the problem with methods of objects, but not with data members.

            It seems as though the author did not discover embedding?

            I prefer to model similar behaviour of objects by using class hierachies. . . . According to my opinion, a programming language should let a developer use his or her style.

            The author is in the small and shrinking minority with these opinions. Thank goodness for that! The sooner we can put to bed the true antipatterns of deep class hierarchies and “code as art” faffery, the better.

            1. 8

              Writing web stuff in Go just doesn’t seem like the best fit. It seems that people want to use Go as the next step from rails/django. But most (yes there are plenty of cases where it might be a good idea) of the time the extra performance gained by using Go isn’t even relative/ to the task at hand, the people in this camp most of the time would benefit from re-writing or optimizing their existing code base in their current language. It doesn’t mean Go is a bad language, it just means its not suitable for X task.

              There is a massive trend at the moment for people to have “one programming language to rule them all”. Its like expecting a mechanic to undo every bolt of a car with one tool, its probably achievable, but its not the correct approach. My approach is always, what do I need to do? Can I do this with X language that I normally use, will using this language limit any performance/functionality if yes, will using another language solve this problem? And go from there. Sure we could do all web development in Haskell, but is that really a good idea?

              1. 2

                Sure we could do all web development in Haskell, but is that really a good idea?

                Haha I clicked here from Twitter! “Yes. Yes, it is.”

                1. 1

                  He has taken it a bit out of context, sure Haskell is great for some web tasks, but if you have a fresh environment and need to serve 1 static html file, its a pointless exercise. This just adds to my original post saying how some people have an idea they want to use one “super” language for all tasks, which although would give cleaner/more standardized code, its not really the best development practice.

              2. 6

                For example, my SAP analysis web interface uses three different product group structures, as the required amount of details varies between user stories. Go forces me to maintain the same code in three different places.

                I would really like to see an example of this, if anyone has one. I can think of a bunch of alternative ways to structure “similar but different” code paths and I’m curious why they didn’t work for this author.

                1. 2

                  Yea, I usually count myself among Go’s detractors but this point even befuddled me. I think Go has it’s share of code-reuse issues but it seems like this particular issue would be easily solved by embedding data members or a better use of interfaces.

                2. 3

                  So I’m not a Go guy, but I’ve been following it from the sidelines because I’m a huge fan of Rob Pike and his work and the language itself appeals to me.

                  One of the reasons why I like C is that the differences between C11 and C89 are fairly minimal. I regularly work with C code that’s from before 1989 and it still generally compiles with only a few minor changes.

                  So watching from the sidelines with Go I’m worried that Go 2 is going to be just an enormous change, to the point that there’s no reason to learn Go 1.

                  Anyone with Go experience and insight into Go 2 have anything to assuage my fears?

                  1. 6

                    They said something like “we can afford somewhere between two and five breaking changes in go 2, and we’ll have tooling to assist the upgrade.”

                    1. 3

                      From the official blog:

                      Go 2 must bring along all those developers. We must ask them to unlearn old habits and learn new ones only when the reward is great.

                      Maybe we can do two or three, certainly not more than five.

                      I’m focusing today on possible major changes, such as additional support for error handling, or introducing immutable or read-only values, or adding some form of generics, or other important topics not yet suggested.

                    2. 3

                      I write a lot of Go at my current job.

                      While I have my qualms with the language (generics pls) I wouldn’t be worried at all about Go 1 knowledge being irrelevant for Go 2. The language probably won’t change too much. It’s very clear that they aren’t starting over and instead taking a practical look at what Go 1 doesn’t handle well and finding solutions for that. If anything, those solutions may make you appreciate Go 2 even more.