TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Taking Go modules for a spin

229 pointsby 101kmalmost 7 years ago

8 comments

hellcowalmost 7 years ago
I&#x27;ve been using go modules in my company for several months now. Everything has &quot;just worked.&quot; It&#x27;s at least 1 order of magnitude faster than dep.<p>It&#x27;s worth noting that go modules use a novel dependency resolution algorithm which is extremely simple to reason about&#x2F;implement, fast, and produces more reliable builds than npm&#x2F;bundler&#x2F;cargo. That&#x27;s why I was excited about it, anyway. It removes the ever-present NP-complete assumptions in this space, so from a computer science perspective it&#x27;s extremely interesting.
评论 #17536151 未加载
评论 #17535608 未加载
ainar-galmost 7 years ago
I am eagerly awaiting the arrival of the module system, but please note, that it&#x27;s still experimental, so not all fun and rainbows. As of now, the Go issue tracker still has 53 open issues with the &quot;modules&quot; label[1], and Go 1.11 should ship around August. The system works well for most cases, but there are still rough edges, especially around vendoring, undocumented or not-so-well documented behaviours, and features which may or may not be &quot;in the scope&quot; for the module system.<p>Overall, I am trying to be optimistic about the future of Go dependency management, but I am not planning to switch the projects I work on in my company from dep to Go modules until most of those rough edges are either smoothed, or officially recognised as &quot;works as intended&quot;, with viable workarounds.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues?q=is%3Aissue+is%3Aopen+label%3Amodules" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues?q=is%3Aissue+is%3Aopen+l...</a>
评论 #17535183 未加载
chipacaalmost 7 years ago
Given it&#x27;s 18.04, you could&#x27;ve `snap install go --channel=edge` to get go from master.<p>(all praise mwhudson for maintaining the Go snaps -- `snap info go` for the whole story).
评论 #17535300 未加载
评论 #17536036 未加载
azhenleyalmost 7 years ago
I recently started to learn Go and everything has gone smoothly... except the bizarre, unfriendly GOPATH and forced project structure.<p>It was not fun when VS Code (with the Go plugin) would automatically remove my imports every time I saved the file because it couldn’t find it.
评论 #17535628 未加载
评论 #17535613 未加载
bsaulalmost 7 years ago
I haven’t followed the history of the feature, but could anyone explain why we had to wait until version 11 to be able to build a project from any location we wanted ? I’m having a hard time believing it’s purely for technical reasons, but then i don’t understand either what has changed that makes it a desirable feature now rather than before.
评论 #17535238 未加载
评论 #17535287 未加载
评论 #17535321 未加载
dilapalmost 7 years ago
Huh, vendor&#x2F; won&#x27;t be honored unless you&#x27;re in GOPATH? Anyone know any more about this? Seems like an odd choice.
评论 #17536408 未加载
irq-1almost 7 years ago
Go is forever changing the pathing and configuration. Even here we have:<p>&gt; Very nice, go build ignored the vendor&#x2F; folder in this repository (because we’re outside $GOPATH)<p>and<p>&gt; Oddly these are stored in $HOME&#x2F;go&#x2F;src&#x2F;mod not the $GOCACHE variable that was added in Go 1.10<p>Maybe Go 2.0 will be stable.
评论 #17536205 未加载
deadprogramalmost 7 years ago
Thanks, Dave!