1. 13
  1.  

  2. 9

    while the standard libraries don’t look excessive either.

    Honestly, if you want the killer golang feature, this is it. The standard library is comprehensive for the wheelhouse golang use cases, and you don’t have to build much to get going. Anything you do end up building usually are convenience packages for standard library primitives.

    1. 6

      It’s hard to overemphasize your excellent point. I build a quite complex background job server in Go and my dependency graph is tiny compared to most any other programming ecosystem:

              github.com/BurntSushi/toml v0.3.1
              github.com/benbjohnson/ego v0.4.0 // indirect
              github.com/go-bindata/go-bindata v3.1.2+incompatible // indirect
              github.com/go-redis/redis v6.15.7+incompatible
              github.com/justinas/nosurf v1.1.0
              github.com/stretchr/testify v1.3.0
      

      TOML, Redis, some web and test utilities. That’s it, everything else is stdlib. This saves me a huge amount of maintenance work by avoiding dependent version upgrades.

      1. 2

        I am not familiar with the Go ecosystem, but I remember noodling around with Python in 2006 or so. Back then, people were saying, “isn’t it great how much stuff is in stdlib?”. These days, I have heard that the stdlib is where libraries “go to die” (everyone moves onto more idiomatic libs developed as the ecosystem matures, and the stdlib stuff never gets fixed due to lack of interest and/or backwards-compat concerns).

        What are your thoughts on this dynamic? Is it an inevitable part of a language’s lifecycle if it attempts a batteries-included stdlib (particularly because things that enter stdlib early get pinned down before language idioms stabilise)? Has Go avoided this problem, or just not hit it yet?

        1. 1

          Go has avoided this problem (mostly!) by being very conservative about what APIs go into the stdlib.

          There are still a few mistakes that made it in, but this is largely achieved by taking people with 40+ years experience and giving them enough time and space to apply their judgement carefully.

    2. 7

      From the OP: “… it’s mostly C with concurrency, seamless M:N threading, garbage collection, fast compilation, namespaces, multiple return values, packages, a mostly sane build system, no C preprocessor, minimal object-oriented support, interfaces, anonymous functions, and closures. Those aren’t trivialities; they’re all rather great things.”

      1. 4

        haha you cited my piece :)

        and from all I’ve seen, they are sensible packages - not leftpad-style idiocy.

        oh stick around and I promise you’ll find some absolutely dreadful Go packages ^_^

        I’ve yet to encounter a single 3rd-party uber-package that is effectively a requirement for doing any “real” work in the language

        after eight years of programming Go there’s basically only one package I find completely indispensable and it’s github.com/spf13/cobra. It has some peculiar design choices but it’s very comprehensive; it’s the one thing I use in every Go project that I write.

        I’m not a fan of its oppositions to exceptions as a normal error-handling mechanism.

        that comes with time. The error handling I’ve grown quite fond of after all these years. My Go programs have very well defined error paths; much more so than my code written in any other language.

        The lack of generics or sum types continues to be annoying. Dealing with timeouts and cancellation is still tedious, and context poisoning in the APIs is a bit frustrating. But overall I’m still happy after eight years of using the language.

        1. 0

          Anyone who tells me I should write in a C-like language without goto can go take a flying leap.

          Serious question: when would you want to do this? I’ve worked with Go for about a year and never used goto once, and find it hard to imagine any use of it I wouldn’t want to replace with another construct.

          1. 4

            I believe examining the C output of a program like Yacc would give difficult-to-substitute goto examples: realizing deterministic rendering of what was a nondeterministic finite automaton.

            1. 3

              Parsing is the main example I’m aware of where goto is important.

              1. 3

                Goto is close to a processor’s branch instruction, and that’s useful sometimes for performance.

                e.g. you’ve manually unrolled a loop and want to jump to a different part of it dependent on blah.

                If goto isn’t there then you either have to do something more abstract and hope the compiler works it out or drop straight down to assembly (which may be far too tedious).

                I didn’t believe in goto either, but I’ve seen some high performance Julia code that made me appreciate it.

                1. 0

                  Agreed. defer lets you omit the goto uses that are common in C.