1. 13
  1. 16

    Seeing more and more of these “Go rants”, regardless of whether the author hates, loves, uses, avoid, wants to convince you to stop using Go or not, I would like to remind people to consider that Go is not a language that can be neatly sorted into the existing categories, being either imperative, object oriented, functional or whatever. The divide wasn’t clear to begin with, but Go certainly isn’t the stabilising force in the debate. The reason why this is relevant, is that this isn’t necessarily just a different floor – one can’t just program go like Java or C++ – actually one can(!), and that is kind of the problem. The ability exists, which leads to the pitfall being exploited, to the mental harm of the programmer.

    In my opinion, this is quite an ironic twist, but one that probably couldn’t be avoided, since Go is quite well known for being an opinionated language, where Rob Pike the language designers got to choose more about what good style and good practice is, than you as a developer get to choose (this is also sometimes taken as the basis for a vulgar argument against Go, which I personally very much disagree with, I think stuff like go fmt are some of the best things about the language).

    Go requires a different kind of thinking, when it comes to conceptualizing and solving program. It’s not just a different form. Again, despite not falling perfectly into pre-existing categories, it doesn’t just create a new one, but I belive, it brings into question the whole relm within which we categorize. And I guess this is part of the reason people are so divided. Those who dislike it, be it corporate pragmatists, or academic purists, both have to adjust and change their patterns and frames of thought, which might disgruntle them for different reasons, but I belive that if people have the right attitudes (the go proverbs do a good job at summarizing these) and want to solve the right problems, one can overcome this frankly silly dispute (use the right tool for the right task still is true), for the better.

    1. 6

      Go is quite well known for being an opinionated language, where the language designers got to choose more about what good style and good practice is, than you as a developer get to choose

      Except that declaration by fiat doesn’t make it so. It may be the official style and the official practice, but that doesn’t make it some absolute good. There were recommendations made about how to write Java by the Java folks as well – not everybody followed them because, not unreasonably, not everybody agrees on these sorts of things.

      Go requires a different kind of thinking … it brings into question the whole relm within which we categorize. Those who dislike it, be it corporate pragmatists, or academic purists, both have to adjust and change their patterns and frames of thought, which might disgruntle them for different reasons … one can overcome this frankly silly dispute …

      This highlights one of the most frustrating parts about Go for me personally. It’s not a religious experience; it’s basically C with garbage collection and M:N threading, and nearly a decade of punting on useful management of modules of software.

      It’s not that I don’t understand; that if I don’t agree I must be some kind of pantomime villain. Go represents a set of design decisions and trade-offs that, in my experience as a software engineer, don’t align with the way I think we should be building software.

      If you happen to like it, that’s great – but let’s not oversell this as some major breakthrough, some software engineering messiah. It’s just not, or at least, not any more than anything anybody else is doing.

      1. 2

        It may be the official style and the official practice, but that doesn’t make it some absolute good. 

        Of course not – my point was that within the Go community, these were set up by the Go team, not as recommendations, but as quasi rules. And for the most part, they were lucky/smart enough to have made reasonable choices. Sure, they might not be perfect, but asking for perfection is the wrong question, which again, I see the Go designers as correctly recognising.

        it’s basically C with garbage collection and M:N threading, and nearly a decade of punting on useful management of modules of software.

        My point is that if you try to describe go this way, you will end up misinterpreting Go. There are many more subtle features and idoms (since a language is not only it’s syntax, but aso it’s “culture”, ie. the standard library, the available packages, the naming, …) which make Go interesting. Small interfaces, errors as values, nil values with meaning, … The way you phrased it, all these things fall away, while they are important when actually using the language.

        If you happen to like it, that’s great – but let’s not oversell this as some major breakthrough, some software engineering messiah.

        You’re right, I might have over-phrased it, my bad. Again, what I am trying to say, to put it more subtly, is that Go (at least to me) signifies a shift in languags, which doesn’t fit within the existing coordinates of language theory, which isn’t something that has never happend before, of course, but should remind the developer to actually learn the language in a richer sense, rather than forcefully trying to apply general OOP or FP ideas onto it, not that Go isn’t doing anything wrong, and it must not be criticised.

      2. [Comment from banned user removed]

        1. 1

          That’s a neat little “defense” of your favourite programming language - just remove the goalposts altogether!

          I never claimed that Go was my “favourite programming language”, I just think that all of this is a silly thing to argue about, so I wanted to offer some points to make more sense of the debate. And there is no reason to be so arogant, as you seem to be, about something like this.

          Gosh, since there’s no apples-to-apples way to compare Go to other programming languages, who’s to say whether it’s better or worse than any of them!

          Read my other comment if this is how you understood my point. All I’m saying is that if you’re (to use your analogy) you want to make an apple pie out of onions, you’ll have a hard time – use the language in the way it was designed to be used, if you want to get something out of it. Sure, when this is actually done, which from my experane of Go criticism is not so often the case, you can civily debate what language or toolkit would be more adequat for a specific scenario, that’s uncontroversial.

          Oh it’s a vulgar argument against Go, huh? That sounds bad. It must be an invalid argument too, then!

          What? All I’m saying is that if you complain that Go doesn’t let me place my brackets on the next line, like I want to, so it’s a overall bad language!, that you haven’t really made any point beyond vaguely whining about the fact that you can’t do something meaningless in the way you want to, but the point remains: who cares? Enforcing one style, for example, makes it easier for others to read your code, for VCS to maintain it and it prevents you from trying to be “smart” when you should be clear. One can debate all of this, yes, but it’s all just preferences.

          It requires a different way of writing code too, since it lacks many of the facilities other programming languages have!

          Yes, no doubt. Go comes from a background and a culture that prefers minimalism and clarity over being a swiss knife. I personally do so to, for example when using AWK as compared to perl. But why should this be necessarily bad? This is exactly one of the things Go wants to do, but if you expect Go to be C++ or Java, you’ll necessarily (I argue) have a bad experiance.

      3. 13

        I think people confuse the problem space go addresses. If you’re using C to write network services, go is very attractive because it’s a tad higher level than C, and has garbage collection(!). If you’re writing a web service where incumbent languages/frameworks are: python/django, ruby/rails, java/spring, c#/.net mvc (or whatever), etc, then go is not such a slam dunk, great choice.

        I don’t believe the go developers have made this point strongly enough. But they have been steadfast in maintaining this divide, and developed a fair bit of animosity from the go user base. As indicated by the vitriol these discussions always generate.

        1. 1

          If you’re writing a web service where incumbent languages/frameworks are: python/django, ruby/rails, java/spring, c#/.net mvc (or whatever), etc, then go is not such a slam dunk, great choice.

          FWIW I think Go does an okay job of marketing itself to people who already have a web service written in Rails or Django or something, receive a lot of traffic to it, are using horizontal scaling to keep up with the demand, and need to make their AWS bills smaller.

        2. 7

          If your super-smart-self is now screaming USE STATIC BUILDS!!!! all over (statically compile libraries in order to at least have them -inside- the binary), just don’t. If you compile everything statically with a given version of glibc the binary will not work on systems with a different glibc.

          Why not link against musl, which is “Designed from the ground up for static linking…”? I believe that’s the strategy Rust uses.

          1. 14

            Even this article is enough to conclude that Go is not “Amazing”.

            “Please Don’t Attack Me For Listing Some Things About Go That Really Suck”

            1. 4

              I disagree strongly with the documentation complaint, the Go documentation is usually a pretty good balance of being api documentation code and providing examples.

              1. 4

                I left a comment on the blog: (his reply was surprisingly hostile…)

                Check out https://github.com/ungerik/pkgreflect for a way to reflect packages.

                Go leaves many of these problems to be solved at build time rather than at runtime.

                Your point about generics is actually about inheritance. You might be the first person I’ve seen defend classical inheritance with virtual methods.

                Virtual methods turn out to cause a lot of problems, the primary problem being they’re slow, which is why c# decided to make virtual opt-in instead of the default.

                But from a language design perspective inheritance often ends up making very confusing code because where something is implemented can be hard to track down and developers will tend to make assumptions about how something is implemented which later binds your hands as the implementor of the base class.

                In general in OO code you should hide everything by default and use virtual with great care. It’s this realization which drives the reasoning behind discarding the concept entirely. It’s just not all that useful in practice.

                I also think getting rid of the ternary operator was good, it leads to easier to understand code, for a very slight cost in verbosity. (surprisingly slight… Rob Pike once said developers think a newline is 100x more expensive than any other character)

                Also I like git imports. It makes it really easy to find docs and the original source code. Distribution of code is a separate issue from its name and a centralized packaging system is a liability.

                1. 2

                  I really really really hope go 2.0 will have generics or some other that will finally allow some “proper” ORM solutions (like sqlalchemy). That would be awesome.

                  1. 3

                    you can get pretty far with standard golang reflection. we’ve built a couple more expressive orm’s internally; generics isn’t what is holding things back. what would really make orm’s more expressive in golang is something like .net/c#’s expression trees.

                    1. 1

                      It seems that everyone builds their own ORM in golang instead of adding features to existing solutions :) Makes me wonder why this is the case.