1. 4

    I don’t see the utility of this for me so it would be really useful if it included a list of problems it solves. I don’t think I’ve ever manually changed my GOPATH and I’ve been working with Go continuously for 2 years. Occasionally I symlink a directrory within my gopath to a more convenient project location, but normally I just work on source directly within GOPATH, e.g. $GOPATH/github.com/iand/salience

    1. 2

      Understandable, I started building this when I had more complicated needs – basically needing more control over the GOPATH, especially with issues around versioning of dependencies. I don’t really feature it well in the README, but it also allows you to easily switch between Go versions, in case you have applications that haven’t been moved to 1.2 yet, though at this point I can’t imagine there is much of a need for this. Maybe once there are a few more Go versions out in the world, this will be more helpful

      1. 2

        in case you have applications that haven’t been moved to 1.2 yet,

        Can you give some examples of these? All Go 1.x code is forwards-compatible (and all libraries are statically linked), so this should really never be an issue unless you’re relying on the internal assembly instructions to be unchanged, which is very rare.

        Unless you’re developing the compilers themselves, I can’t think of a reason that using even tip (the development version) should be problematic, or at least just using the most recent stable version for all projects.

        1. 1

          I can give a couple of examples. Recent Go versions support cryptographic stuff that isn’t supported in earlier versions, and sometimes it’s nice to test it on other versions to remind me what’s supported.

          Specifically, there are certain TLS ciphers that aren’t supported in older versions, and GCM has only recently been implemented.

          1. 1

            That’s circular, though - those people should be updating to the most recent version of Go. This is not true in other realms (e.g. Ruby and Python - Ruby/Rails in particular is notorious for supporting multiple development lines simultaneously).

            But in Go, once 1.(n) has been released, 1.(n-1) should for the most part be considered deprecated or obsolete.

            1. 2

              Tell that to the package maintainers. On Ubuntu, for example, the packaged version was 1.1.2 the last time I checked. It’s a pain, but it’s not something I have control over.

              1. 1

                those people should be updating to the most recent version of Go

                I totally agree with this, and in a perfect world this would happen. Since we don’t live in a perfect world, I like to know that if I have an old application that does something funky in newer versions of Go, I could easily switch back and forth between Go versions.

                In my comment a couple levels up, I mention that this feature is not specifically needed at this point, but it wasn’t hard to add in, so I put in it :)

                1. 1

                  I like to know that if I have an old application that does something funky in newer versions of Go

                  I would also like to know that, so I could report it to the Go team as a bug in the compiler! Seriously, though, the Go team makes a very concerted effort to ensure that the compiler will be backwards-compatible with existing codebases.

                  I apologize if it sounds like I’m giving you a hard time about this - I’m not trying to diminish the work that you’ve done. Instead, look at the flip-side:

                  The Go team has gone to great trouble to ensure that tools like these are not needed. The mindset is that these sorts of tools are band-aids that underscore deeper problems in the language and build system (the way they do in Python). Go doesn’t have these deeper problems, so it’s disconcerting to see band-aids invented for problems that don’t exist.

                  (Of course, if you think that a problem does exist, that’s a separate discussion, in which case you should alert the Go core team, because this is something they care a lot about.)

                  1. 2

                    I would expect that if there was anything that an application depended on a past version of Go for, it would be something in the standard library, not a compiler issue

      1. 14

        It’s interesting to note that a lot of what comprises many style guides (take a look at PEP 8, for example) is made unnecessary by Go’s “gofmt” tool.

        “gofmt” is easily my favorite part about Go - it ensures a somewhat consistent style for all Go code I read, whether or not I wrote it. This makes it much easier for me to interact with others' codebases.

        1. 2

          Contrast with Urwid, which imposes it’s own (inflexible) paradigm. Having used it on a project, I can say that if you don’t want to use Urwid in the exact manner that it’s authors intended, you’re in for a struggle.

          Blessings seems to really grok what it means to be Pythonic: elegance and simplicity, but not at the expense of power.

          1. 1

            On the other hand, do you think we’d have been able to use blessings for ncnyt? Given that it was a hackathon project (~20 hours) having cookie-cutter widgets to manipulate probably simplified a lot of the development, even if the model is very rigid.