What is the current recommendation for dependency management in Go for a new project?
dep was the tool I used. There are a few other solutions but this one was most popular when I last looked.
Go 1.11 Rc1 released
21–29 of 29 posts
Re: Go 1.11 Rc1 released
#22Earlier quoted context omitted.
Or that such tools aren't shipped and part of the standard Go experience. Fortunately that's changing.
ant, maven and gradle are not shipped with the JVM, yet the java community figures out how to do a build system somehow.
in fairness, Java has an excuse that it’s ancient in language terms and expectations were different then.
Go, not so much - it came out in 2012. Pip and CPAN and Gem had been around for years. Go’s lack of a sane packaging solution this far into its lifetime remains a serious weakness of an otherwise solid platform.
Re: Go 1.11 Rc1 released
#23What is the current recommendation for dependency management in Go for a new project?
Go modules are the future but use dep as of now
Re: Go 1.11 Rc1 released
#24What is the current recommendation for dependency management in Go for a new project?
I was using dep but recently switched back to Glide since dep's future is uncertain.
Re: Go 1.11 Rc1 released
#25Earlier quoted context omitted.
Or that such tools aren't shipped and part of the standard Go experience. Fortunately that's changing.
ant, maven and gradle are not shipped with the JVM, yet the java community figures out how to do a build system somehow.
Java doesn't bundle and market a `java get` command that works fine until it suddenly dosn't.
Re: Go 1.11 Rc1 released
#26Earlier quoted context omitted.
ant, maven and gradle are not shipped with the JVM, yet the java community figures out how to do a build system somehow.
Java doesn't bundle and market a `java get` command that works fine until it suddenly dosn't.
The `go get` command was never marketed as a versioned package management tool. `go get` also works just fine if you point it at forked repositories that you control.
Re: Go 1.11 Rc1 released
#27Earlier quoted context omitted.
ant, maven and gradle are not shipped with the JVM, yet the java community figures out how to do a build system somehow.
in fairness, Java has an excuse that it’s ancient in language terms and expectations were different then. Go, not so much - it came out in 2012. Pip and CPAN and Gem had been around for years. Go’s lack of a sane packaging solution this far into its lifetime remains a serious weakness of an otherwise solid platform.
One could argue that golang is a solid platform because they focused on the platform first, instead of the package management. It is all about priorities.
Re: Go 1.11 Rc1 released
#28There has been some tremendous improvements for ARM architecture. If you run some serious code on raspberry PIs, get ready to be amazed.
I skimmed the release notes, and only a little mention there ARM specific changes, can you elaborate on what tremendous improvements are made? Very curious!
Yes, the release notes are a bit humble about it.
Specifically, optimized assembly instructions are used now in crypto code and also lot of optimizations have gone into the ARM assembler.
One example - https://gist.github.com/carlosedp/f85274ef2a9bacc773cf8ddeed....
Re: Go 1.11 Rc1 released
#29Earlier quoted context omitted.
Java doesn't bundle and market a `java get` command that works fine until it suddenly dosn't.
The `go get` command was never marketed as a versioned package management tool. `go get` also works just fine if you point it at forked repositories that you control.
> The `go get` command was never marketed as a versioned package management tool.
Because the Go team kept pushing the ridiculous idea that versioning doesn't matter.
> `go get` also works just fine if you point it at forked repositories that you control.
And at that point, what value does `go get` add?