6 ms·

The Stockholm syndrome shown by Go users in things like this is just incredible.

by veeti 11y ago

pbreit 11y ago
What do you mean? It sounded sensible to me.
zeveb 11y ago
I think I agree. There are a lot of great things about Go, but (currently) library versioning is not one of them. This doesn't contradict much of what the author writes: it really is true that two different versions of one library are actually two different libraries; it really is true that sometimes copy-and-paste is better than generalising (when the cost of being general obscures the meaning of the code itself); it really is true that many libraries should just specify and implement an API, then stop. The issue with libraries in versions in Go could probably be resolved with a more flexible import syntax. It'd be sweet to be able to write 'import foo.invalid/bar@94d0ef312881e694ded9ff38e33a2c07fb398eb8' and know that I'd always either get the exact version that I specified. It'd be even cooler to have some way to specify 'I want the latest version of library X which offers the exact API I'm using'; in principal this would be possible by calculating some deterministic ordering of the used, exposed API and hashing that, but the details would be tricky (as an example, consider a case where Foo() and Bar() still exist, with the same signatures, but in version 2.0 Bar() can only run properly if Baz() has been called previously—there's no way in Go to express that sort of contract to the compiler.
- deleted 11y ago
  [deleted]
  - TheDong 11y ago
    You'll already have to recompile because go is statically linked. The current state of the art is just vendoring dependencies (see godeps) which means they never get updated ever. Security updates don't happen now, and version pinning by vendoring is a hack, so it would be better to at least have version pinning built in so I can delete a few million lines of (vendored) code from my repository and instead just use a better import path. I assure you that that will be easier than dealing with the hell of vendoring tools and hacks go has now. And yes, the semver way to do it is great and is actually done well in some ecosystems. npm does a really good job of encouraging users to use semver and as a result you can just say "I want the latest 1.1.x release" or "1.x.x". The hardest problem there is to get people to version things. Your next point, that you don't want to recompile all go programs, is where I'll again point out go is statically linked. The authors of the language designed it so that no, you can't just update a go library in one place and build once. You have to build everything that depends on it again. You have to hope there were no breaking changes or you have to backport patches. Go does not handle this and is designed so as to be actively hostile to security. And yeah, the idea that semantic changes are backwards incompatible is a developer call, but you need a programmatic way to express it.... hence semver. In conclusion, having that sort of import-path thing would be awesome not because it solves any of the things you complain about (it doesn't) but because it's a step in the right direction. Any change is good change when your package management is "eh, fuck it" like Go's is now. If you look at all other good package managers (e.g. npm, rubygems, crate, etc) you can specify a repository and specific commit because there are plenty of valid cases for that, even when you have other options. No one is saying Go shouldn't have those other options in the future too here, just that having this option is a step in the right direction.
    - deleted 11y ago
      [deleted]
      - ominous_prime 11y ago
        > I haven't studied Go. Your telling me every file is statically linked? How does it use the OS APIs? OS APIs are accessed through syscalls, you don't usually need to link to anything. The exceptions to static binaries have been to use the host resolver when necessary, the user db on linux, and looking up certificates on osx; none of which are directly available through syscalls.
- dradtke 11y ago
  Honestly, with the release of Go 1.5, I've taken to using "go get" once to download the library, copy it over into the vendor folder, remove its .git folder, and commit the whole thing to source control. It's easier than messing with version numbers or commit hashes, and more stable than always using the latest master.
  - cakeface 11y ago
    I really like this approach and it reminds me of the approach that Google takes with their versioning. Everything in one giant source repository. It has a nice effect where every change to a library requires a commit which can trigger a build. There are no hidden updates.
    - vinceguidry 11y ago
      It puts you in the driver's seat of dependency managing, but now you have to be a lot more careful to actually update them when the time comes. If you tend to put something into production and leave it there for months / years, coming back to do maintenance will be a real chore. With Ruby I can 'bundle update', run the tests, and have reasonable certainty that everything's working. If I took over a Ruby project with vendored gems I'd mark them all for replacement for standard Bundler-managed gems at first opportunity. Vendored code has a bad tendency to become 'unmaintained code' otherwise. Just because it works and is stable doesn't mean it doesn't have security vulns.
aikah 11y ago
> The Stockholm syndrome shown by Go users in things like this is just incredible. Well, the problem is that Go is a bait/switch . It has enough goodness to make someone enthusiastic about it at first place. And then when one finds out that the language has major issues , one has two way to deal with things : denial or giving up on Go. Go is a niche language , its "community" will always be very protective of what Go is no matter how much flaws it has, because this community isn't really in control of the language anyway. This is a top/down governance, with the Google team at the top, and there is no debate what soever. There used to be but as I said earlier people that are not satisfied with Go have been shut down in the mailing list (or by silly processes imposed by the go team when it comes to contribution or feature suggestion ) and moved on.

The Stockholm syndrome shown by Go users in things like this is just incredible.

by veeti 11y ago

The Stockholm syndrome shown by Go users in things like this is just incredible.

pbreit 11y ago

What do you mean? It sounded sensible to me.

zeveb 11y ago

I think I agree. There are a lot of great things about Go, but (currently) library versioning is not one of them. This doesn't contradict much of what the author writes: it really is true that two different versions of one library are actually two different libraries; it really is true that sometimes copy-and-paste is better than generalising (when the cost of being general obscures the meaning of the code itself); it really is true that many libraries should just specify and implement an API, then stop. The issue with libraries in versions in Go could probably be resolved with a more flexible import syntax. It'd be sweet to be able to write 'import foo.invalid/bar@94d0ef312881e694ded9ff38e33a2c07fb398eb8' and know that I'd always either get the exact version that I specified. It'd be even cooler to have some way to specify 'I want the latest version of library X which offers the exact API I'm using'; in principal this would be possible by calculating some deterministic ordering of the used, exposed API and hashing that, but the details would be tricky (as an example, consider a case where Foo() and Bar() still exist, with the same signatures, but in version 2.0 Bar() can only run properly if Baz() has been called previously—there's no way in Go to express that sort of contract to the compiler.

deleted 11y ago
[deleted]
- TheDong 11y ago
  You'll already have to recompile because go is statically linked. The current state of the art is just vendoring dependencies (see godeps) which means they never get updated ever. Security updates don't happen now, and version pinning by vendoring is a hack, so it would be better to at least have version pinning built in so I can delete a few million lines of (vendored) code from my repository and instead just use a better import path. I assure you that that will be easier than dealing with the hell of vendoring tools and hacks go has now. And yes, the semver way to do it is great and is actually done well in some ecosystems. npm does a really good job of encouraging users to use semver and as a result you can just say "I want the latest 1.1.x release" or "1.x.x". The hardest problem there is to get people to version things. Your next point, that you don't want to recompile all go programs, is where I'll again point out go is statically linked. The authors of the language designed it so that no, you can't just update a go library in one place and build once. You have to build everything that depends on it again. You have to hope there were no breaking changes or you have to backport patches. Go does not handle this and is designed so as to be actively hostile to security. And yeah, the idea that semantic changes are backwards incompatible is a developer call, but you need a programmatic way to express it.... hence semver. In conclusion, having that sort of import-path thing would be awesome not because it solves any of the things you complain about (it doesn't) but because it's a step in the right direction. Any change is good change when your package management is "eh, fuck it" like Go's is now. If you look at all other good package managers (e.g. npm, rubygems, crate, etc) you can specify a repository and specific commit because there are plenty of valid cases for that, even when you have other options. No one is saying Go shouldn't have those other options in the future too here, just that having this option is a step in the right direction.
  - deleted 11y ago
    [deleted]
    - ominous_prime 11y ago
      > I haven't studied Go. Your telling me every file is statically linked? How does it use the OS APIs? OS APIs are accessed through syscalls, you don't usually need to link to anything. The exceptions to static binaries have been to use the host resolver when necessary, the user db on linux, and looking up certificates on osx; none of which are directly available through syscalls.
dradtke 11y ago
Honestly, with the release of Go 1.5, I've taken to using "go get" once to download the library, copy it over into the vendor folder, remove its .git folder, and commit the whole thing to source control. It's easier than messing with version numbers or commit hashes, and more stable than always using the latest master.
- cakeface 11y ago
  I really like this approach and it reminds me of the approach that Google takes with their versioning. Everything in one giant source repository. It has a nice effect where every change to a library requires a commit which can trigger a build. There are no hidden updates.
  - vinceguidry 11y ago
    It puts you in the driver's seat of dependency managing, but now you have to be a lot more careful to actually update them when the time comes. If you tend to put something into production and leave it there for months / years, coming back to do maintenance will be a real chore. With Ruby I can 'bundle update', run the tests, and have reasonable certainty that everything's working. If I took over a Ruby project with vendored gems I'd mark them all for replacement for standard Bundler-managed gems at first opportunity. Vendored code has a bad tendency to become 'unmaintained code' otherwise. Just because it works and is stable doesn't mean it doesn't have security vulns.

aikah 11y ago

> The Stockholm syndrome shown by Go users in things like this is just incredible. Well, the problem is that Go is a bait/switch . It has enough goodness to make someone enthusiastic about it at first place. And then when one finds out that the language has major issues , one has two way to deal with things : denial or giving up on Go. Go is a niche language , its "community" will always be very protective of what Go is no matter how much flaws it has, because this community isn't really in control of the language anyway. This is a top/down governance, with the Google team at the top, and there is no debate what soever. There used to be but as I said earlier people that are not satisfied with Go have been shut down in the mailing list (or by silly processes imposed by the go team when it comes to contribution or feature suggestion ) and moved on.