Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GVM - the Go version manager

blog.moovweb.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: GVM - the Go version manager

#11

Post by FooBarWidget »

sirclueless wrote: post #8

I actually hope this doesn't take off (or at least, if it does, that it keeps its scope in check). RVM is invasive and moderately broken because of that. And besides, in a very short time, Go is going to commit to API stability with Go 1. And given that, and static typing (even at runtime), and Go's beautiful module system, and the fact that static linking is the norm, all means that worrying about which Go version y…

And yet look at how many people use RVM. Just from user popularity alone it's clear that system package managers, no matter how much they're praised by sysadmin people, are not adequate. There's a clear need for package management that's:

1. cross-platform.

2. allows users access to the latest version of the software immediately.

3. allows installation of multiple versions. API/ABI stability is great but perfect backward compatibility is never possible. E.g. some apps actually rely on bugs in the platform and if you fix them they break; yeah yeah I know the software must be fixed but there may be a ton of reasons why that doesn't happen or at least not happen immediately and there's a clear need among users to be able to install multiple versions of a platform/library.

RPM/DEB theoretically support (2), but in practice distros never do that. Third party packagers that immediately provide the latest versions are most exception to the rule because they need to replicate their effort multiple times over multiple platforms thanks to the lack of support for (1). RPM/DEB don't even try to support (3).

Re: GVM - the Go version manager

#12

Post by masklinn »

marketer wrote: post #4
wglb wrote: post #3

I kind of think of RVM as a necessary bug due to the unmanaged span of Ruby versions. I am not clear why this is really necessary for GO. Why not just use 'go fix'?

For simple projects or toy apps, gofix is just fine. However, some companies are running complex production systems written in GO 0, and the code may have a lot of dependencies and custom build scripts. In this case it's useful to have an easy way to install and pin Go versions. Once Go 1 launches, subsequent releases should be compatible with the Go 1, which reduces the need for something like GVM.

> Once Go 1 launches, subsequent releases should be compatible with the Go 1

Which does not mean that they will be, despite Sun's effort to never formally deprecate (let alone remove) anything and the glacial pace of the language, there have been backwards compatibility issues in the past: reliance on implementation details or under-specified behavior which got changed, reliance on bona-fide bugs which just happened to do what a developer wanted in that case, etc...

Re: GVM - the Go version manager

#13

Post by koko775 »

FooBarWidget wrote: post #11
sirclueless wrote: post #8

I actually hope this doesn't take off (or at least, if it does, that it keeps its scope in check). RVM is invasive and moderately broken because of that. And besides, in a very short time, Go is going to commit to API stability with Go 1. And given that, and static typing (even at runtime), and Go's beautiful module system, and the fact that static linking is the norm, all means that worrying about which Go version y…

And yet look at how many people use RVM. Just from user popularity alone it's clear that system package managers, no matter how much they're praised by sysadmin people, are not adequate. There's a clear need for package management that's: 1. cross-platform. 2. allows users access to the latest version of the software immediately . 3. allows installation of multiple versions. API/ABI stability is great but perfect bac…

Maven.

* Cross-platform.

* Easy access to remote packages as soon as they're posted.

* Versions must specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either.

Also, very decentralized, and it's easy to create a directory locally to hold the dependencies within a project (specify a file:// repository relative to ${project.dir}), or on a per-system-user level (mvn install), or on a per-company/organizational unit basis (self-hosted repos are a cinch).

It's actually a fantastic package management system tailored to Java that works extremely well. Its main problem is that it's also fantastically verbose, and including more and more build plugins can grow exponentially more arcane the greater the number of plugins involved. However, with Go's standardized directory layout among other things (I admit, I haven't done much research into trying Go out), something akin to Maven may actually be a good fit.

Re: GVM - the Go version manager

#14

Post by lautis »

koko775 wrote: post #13
FooBarWidget wrote: post #11

Earlier quoted context omitted.

And yet look at how many people use RVM. Just from user popularity alone it's clear that system package managers, no matter how much they're praised by sysadmin people, are not adequate. There's a clear need for package management that's: 1. cross-platform. 2. allows users access to the latest version of the software immediately . 3. allows installation of multiple versions. API/ABI stability is great but perfect bac…

Maven. * Cross-platform. * Easy access to remote packages as soon as they're posted. * Versions must specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either. Also, very decentralized, and it's easy to create a directory locally to hold the dependencies within a project (specify a file:// reposi…

As a user, i've been occasionally fristrated with the decentralized nature of Maven. The isn't any single repository which would contain all packages (especially rc/beta versions). And in my experience repos and which repos are used to distributed a package tend to change fairly often. More often than not, I have to hunt for new repos when building from scratch.

Maven is also very slow when your project has ~10 repos and you need to download multiple dependencies. Having your own repo might be a necessity.

Re: GVM - the Go version manager

#15

Post by tomjen3 »

koko775 wrote: post #13
FooBarWidget wrote: post #11

Earlier quoted context omitted.

And yet look at how many people use RVM. Just from user popularity alone it's clear that system package managers, no matter how much they're praised by sysadmin people, are not adequate. There's a clear need for package management that's: 1. cross-platform. 2. allows users access to the latest version of the software immediately . 3. allows installation of multiple versions. API/ABI stability is great but perfect bac…

Maven. * Cross-platform. * Easy access to remote packages as soon as they're posted. * Versions must specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either. Also, very decentralized, and it's easy to create a directory locally to hold the dependencies within a project (specify a file:// reposi…

Maven is adequate as a dependency resolution tool, though I always marvel at the insane number of packages it downloads.

That said it should not ever be used as a build system -- ant exist for exactly that reason or you could use Make if you want your builds to go faster.

Re: GVM - the Go version manager

#16

Post by wglb »

masklinn wrote: post #12
marketer wrote: post #4

Earlier quoted context omitted.

For simple projects or toy apps, gofix is just fine. However, some companies are running complex production systems written in GO 0, and the code may have a lot of dependencies and custom build scripts. In this case it's useful to have an easy way to install and pin Go versions. Once Go 1 launches, subsequent releases should be compatible with the Go 1, which reduces the need for something like GVM.

> Once Go 1 launches, subsequent releases should be compatible with the Go 1 Which does not mean that they will be, despite Sun's effort to never formally deprecate (let alone remove) anything and the glacial pace of the language, there have been backwards compatibility issues in the past: reliance on implementation details or under-specified behavior which got changed, reliance on bona-fide bugs which just happened…

I am getting that the GoFolk are building GOLANG with this problem firmly in mind, and may just be expecting to avoid it.

Re: GVM - the Go version manager

#17

Post by masklinn »

wglb wrote: post #16
masklinn wrote: post #12

Earlier quoted context omitted.

> Once Go 1 launches, subsequent releases should be compatible with the Go 1 Which does not mean that they will be, despite Sun's effort to never formally deprecate (let alone remove) anything and the glacial pace of the language, there have been backwards compatibility issues in the past: reliance on implementation details or under-specified behavior which got changed, reliance on bona-fide bugs which just happened…

I am getting that the GoFolk are building GOLANG with this problem firmly in mind, and may just be expecting to avoid it.

You can expect the unexpected not to happen all you want, reality won't care a bit.

In fact, this makes me think of the Douglas Adams quote sitting right above my main display:

"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair"

Re: GVM - the Go version manager

#18

Post by koko775 »

lautis wrote: post #14
koko775 wrote: post #13

Earlier quoted context omitted.

Maven. * Cross-platform. * Easy access to remote packages as soon as they're posted. * Versions must specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either. Also, very decentralized, and it's easy to create a directory locally to hold the dependencies within a project (specify a file:// reposi…

As a user, i've been occasionally fristrated with the decentralized nature of Maven. The isn't any single repository which would contain all packages (especially rc/beta versions). And in my experience repos and which repos are used to distributed a package tend to change fairly often. More often than not, I have to hunt for new repos when building from scratch. Maven is also very slow when your project has ~10 repos…

You can set up Artifactory on a nearby server you own and proxy all of your package requests through it. Works quite well.

Re: GVM - the Go version manager

#19

Post by koko775 »

tomjen3 wrote: post #15
koko775 wrote: post #13

Earlier quoted context omitted.

Maven. * Cross-platform. * Easy access to remote packages as soon as they're posted. * Versions must specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either. Also, very decentralized, and it's easy to create a directory locally to hold the dependencies within a project (specify a file:// reposi…

Maven is adequate as a dependency resolution tool, though I always marvel at the insane number of packages it downloads. That said it should not ever be used as a build system -- ant exist for exactly that reason or you could use Make if you want your builds to go faster.

They take opposite approaches. Maven gives you scaffolding; it's up to you to customize it. Ant gives you practically nothing, but you can do whatever you want. If you want to code on the shoulders of giants then Maven will help you much more than Ant will, IMO.
Post reply on HN