Re:Golang heap corruption during garbage collection
by mwcampbell on Tuesday June 04, 2013 @02:19PM
(#5821173)
At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.
[ Parent
| on HN ]
Re:Golang heap corruption during garbage collection
by nknighthb on Wednesday June 05, 2013 @11:15AM
(#5826145)
Google's internal developers operate in a vastly different world from the one most of us are used to, always building from the head of a single, massive Perforce repository.
When your world enforces the assumption that the latest version of a dependency is stable and compatible, 'go get' is a perfectly reasonable solution.
Re:Golang heap corruption during garbage collection
by wtbob on Wednesday June 05, 2013 @12:45PM
(#5826764)
> At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.
That's how 'go get' works.
Re:Golang heap corruption during garbage collection
by TylerE on Wednesday June 05, 2013 @02:42PM
(#5827649)
No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.
Re:Golang heap corruption during garbage collection
by wtbob on Wednesday June 05, 2013 @04:28PM
(#5828366)
> No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.
You get the dependency at a version control level, at a known-good version (because you pulled from the master branch) at the time you pulled, and after that it's up to you to update it.