1. 9

  2. 9

    Since when is showing off a project spam?

    1. 5

      Thanks for your support, I was definitely a little disappointed when I posted this and it was immediately downvoted as spam. I chose to post this to lobste.rs instead of news.yc hoping for a less toxic environment.

      1. 4

        I have a suspicion that someone has declared a holy war on go and is downvoting all of the popular links in the Go tag. Seriously, even the “Toward Go 1.3” announcement has a low quality downvote. What the hell?

        1. 1

          It’s several different users downvoting, which sounds to me as if it’s from new(er) users who aren’t familiar with filtering.

          1. 4

            But this sort of behavior seems to be specific to the go tag. Posts about other topics don’t seem to get downvoted as often. I hope that you are right and this isn’t malicious, but it still seems odd to me. If you are right, and it’s because of new users who aren’t familiar with the tagging system, perhaps we could have it so that the first time they go to downvote, a message shows up telling them to consider filtering instead of downvoting.

        2. 3

          Not sure, that’s pretty ridiculous. I think that downvotes should be public information.

          1. 4

            Moderators can see downvoter usernames to detect problems but I feel like showing them to everyone would be a bit invasive.

        3. 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