Agreed. In addition I hope they provide a blog post about best practices w.r.t. vendoring in order to explain the problem and solution in more depth to a wider audience than the initial design doc.
The go core team may not be the best group to describe the best practices. At Google they work on a large monorepo and don't do distributed packages the way many others do. They aren't intimately familiar with the problem and solution.
I would expect the best patterns to come from the community which is something Rob Pike pointed to at the first Gophercon.
I don't think it's as obscure as a problem as you think.
I've been trying to learn Go as a sideproject for less than a month, and even I realize what the problem is and how the vendor spec solves it (at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)
One of the things I miss the most when working in Go is PHP Composer, and it's pretty obvious how the vendor design doc solves the same problem in a more Go idiomatic way.
Composer (or the alternatives for other languages) do more than the vendor/ directories do. Those tools manage the versions in the directories which are important for compatibility, ensuring versions around security issues, and so on.
Glide[1] is a tool like Composer but for Go and it uses the vendor/ directory. It's designed to complement the go commands.
Submodules in git specify the specific commit to be checked out and don't automatically track the HEAD of a branch (unlike go get.)
That's why I include the statement that Go vendoring is useful "(at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)"
Submodules and even subtrees can be useful ways to link repos. But, I'm wary of commit ids as versions. From a commit id you can't tell if the version you can is after the version that fixed a security issues. You can't tell what version of the interface to the package you're using. The meaning we are able to pull from and even compare with version number is missing. And, submodules are pinned to commit ids.
I see where you're coming from and agree that commit IDs aren't very friendly, but from a technical perspective it solves the same problem of having dependencies on specific versions of software.
Now that I've looked into glide a little more I'm curious: since the main benefit is the ability to use semantic versioning to manage your dependencies, why do you use a glide.lock file instead of making the "glide" command a simplified way to update/maintain vendor submodule references with semantic versioning? Then users wouldn't need the glide tool, only developers, and users could just use standard go tools.
- The Go community supports Git, Svn, Bzr, and Hg. We keep that up. According to the Eclipse community survey, 2014 was the year Git usage passed Svn usage. Svn usage is still quite high.
- A lot of developers struggle with and even have strong negative opinions of submodules. So much so that we now have subtrees. I've find a lot of developers would prefer not to use them.
- The way Glide works is in line with the package managers from the other major/popular languages. This way it's familiar to many people coming to Go by solving the same problem in the same way they're already used to.
Thanks for glide! We're using it at Quizlet for our go builds and are fans. In conjunction with vendoring, makes it easy to have reproducible builds over time.
> NOTE: This is a DRAFT of the Go 1.6 release notes, prepared for the Go 1.6 beta. Go 1.6 has NOT yet been released. By our regular schedule, it is expected some time in February 2016.
The increase was caused during 1.4->1.5 by translating the whole compiler toolchain from C to Go. The core devs focussed on correctness over performance on the first pass. They clawed back a lot of the performance already, and though it is slower than it used to be, it isn't at all bad compared with C++ and other languages I've used.
I'm a little sad about the slower compiler speed to, though it's still lightyears better than C++. But for my project it's juuust long enough that not having status printed while compiling feels pretty annoying.
If they just printed out each file as it was compiled, it would go back to feeling lightning fast. :)
boom! that does it, thanks. (well actually what i reallly want is in between -- just each file name as it compiled, in a pretty list that gives me something to look at while waiting for the compile. but this is 𝞊 away.)
Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. For more details, see these slides and associated video.
I'm also interested in the vendoring support. I've been using godep and I haven't really taken a look at the vendoring in 1.5 yet (being experimental and all).
The vendor support is that if you create a directory called "vendor" in the "current project", it will be preferred to the GOPATH for that project. That's pretty much it. The idea here is that they officially support that in the compiler, and then the community can build whatever tools it likes around that support. Whether you call that "support for vendoring" depends on exactly what you're looking for from "support". It's true that the compiler "supports" it, but it's also true that Go still has no "official" vendoring solution, unless you want to count the default one of manually mananging vendored directories, though I don't think most people interested in "vendoring" would call that support (and neither would I, so that's no criticism).
I could use a tool that I could fire at a codebase that asserts that all imports are either coming out of the vendor directory or coming out of the base system.
Default values mean optional arguments. Optional arguments mean functions with lots of arguments. Then you need to document what happens with each option. Not having that possibility enforces you to actually design an elegant API, instead of stuffing everything in a function and relying in optional arguments to hide the mess.
> Not having that possibility enforces you to actually design an elegant API
Yes, of course, the forced elegance of MarshalIndent next to Marshal — being able to indent in Marshal would be graceless, of CreateHeader alongside Create in case you wish to specify more than just the file name, of asn1.Unmarshal and its friend asn1.UnmarshalWithParams, so much more dignified than Unmarshal optionally taking params is it not?
You'd have to be blind not to see the refinement of DialHTTP to connect to an RPC server, unless you want to connect to a path which isn't / then DialHTTPPath has that undefinable quality of an excellent API, you definitely wouldn't want DialHTTP to just have a default path that would be tasteless.
And it's really quite obvious to have ToUpper and ToUpperSpecial, can you imagine how unpolished an optional case parameter to ToUpper would look?
Or Split taking an optional number of substrings? How gauche, lucky us the designers of the API were forced to add the soigné SplitN to which you can explicitly pass a negative number to get all substrings.
Really there are so many examples of the lack of optional parameters forcing the design of an outright dandyish API. Just look at WIN32, saved from the dreaded "lots of arguments" by C not having default parameters, not a function in there using that to hide the mess no sir, not in a million years would a language with default parameters have achieved the summit, the peak, the pinnacle of delight that are CreateWindowEx or RegQueryValueEx.
And naturally optional anything means you will build an inelegant API one day and have lost all chance to elegant API, which is why Go requires all structure fields to be explicitly filled.
shrug It'd be one more special case for the compiler to handle (and one more feature for my brain to hold onto when reasoning through code... "This is being called with two arguments, is that a typo or does this function take default arguments? Guess I'll have to go look up the function's declaration...").
I can see the alternate viewpoint but given that we can use structs and default fields to get the same effect I'm happy with the current solution.
> I can see the alternate viewpoint but given that we can use structs and default fields to get the same effect I'm happy with the current solution.
And that's completely fair, I routinely use languages both with and without optional parameters[0] and that's fine I'm not saying languages must[1] have optional parameters, or even that they should[1]. My comment only tries to humorously denote that the claim I quoted is pure lunacy.
> we can use structs and default fields
Don't forget the builder pattern which works pretty well to replace optional parameters (and keyword/named parameters), though it's less convenient on the implementer's side.
[0] whether in the "native" sense à la Python or C#, in the "overloaded method" sense à la C++ or Java or in the "well your question doesn't even make sense" à la Smalltalk
Hardly, but that's not the argument, I was replying to an assertion that not having default arguments enforces you to actually design an elegant API. It does no such thing. Contrary to the person I was replying to (and to you apparently) I would say that there are advantages to and issues with both options, but the claim I quoted and replied to is just plain insane.
> things are up-front and obvious, easier to document, and less error-prone.
Things are none of these, the exact same claim can be made about having optional parameters and against not having them.
I hear what you are saying, and functions can certainly get messy with too many arguments, default or otherwise, but if you are disciplined about the number of arguments a function takes then having this feature (default optional arguments) is a huge win for a language.
IIUC, the go-idiomatic way to do this if you find yourself wanting default arguments is to pass in a struct as one of the args to your function and have the default values of the fields in the struct mean "default" in the behavior of the function.
But in general, if you have a two-argument function and one of the arguments could be defaulted, just pass it. It's clearer at the call point what's happening then.
Thanks! I usually rely on Feedly to show me an icon when it can subscribe, but I pasted blog.golang.org/feed.atom into the 'add content' option and it just worked.
That's not how semantic versioning works[0]. If they want (and everything still points in this direction AFAIK) they will just keep releasing Go 1.10, 1.11, 1.12, etc.
There is no Go2. Go2 is not a "thing", it's the absence of another thing. It's very Zen. Go2 is everything that Go1 cannot be. If Go1 was the universe, Go2 would be everything outside of it - which is nothing. Anytime someone mentions "This needs to wait for Go2", what they mean is "We can't do this now due to the Go1 compatibility promise, so let's leave it for the far future, for a day that may never even come, and table this discussion".
I seriously doubt that - what they have clearly opposed is breaking backwards compatibility in Go 1.x - they day they decide to break backwards compatibility is the day work begins on Go 2.0
