Go 1.6 Beta Released | Hacker News Reader

Go 1.6 Beta Released

tip.golang.org

217 pointsomginternets64 comments

I, for one, am very excited to see that vendoring is leaving its experimental status. I think this is the most noteworthy change in the tooling.

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.

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.

disclosure: I'm one of the glide devs

[1] https://github.com/Masterminds/glide

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.

A few reasons we don't just use submodules

- 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.

Typical Git usage is to create a tag for every release, giving it a nicer name than a raw SHA1 sum. You can check out a submodule to such a tag too.

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.

Also, there's some good discussion of other approaches to dependency management on the go forum: https://forum.golangbridge.org/t/the-best-dependency-manager...

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.

Vendoring:

> Go 1.6 includes support for using local copies of external dependencies to satisfy imports of those dependencies, often referred to as vendoring.

https://tip.golang.org/cmd/go/#hdr-Vendor_Directories

The submission title is misleading.

> 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.

1.6 has not been released, but this is the 1.6 Beta 1. It should be considered unstable, obviously.

Unless the title has been updated since your comment, it is accurate. The beta is out today, builds available from https://golang.org/dl/#unstable

Doesn't say anything about compilation speed. How close to 1.4 performance are we? The slow compilation on 1.5 has kept us on 1.4 so far.

I was looking for this too. Disappointed to see no mention of it as compilation time doubled in 1.5.

Any idea what causes this increase? I'm surprised as I understood fast compilation times to be one of Go's major strengths.

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.

The compiler was convert/rewritten from C to Go.

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. :)

(Maybe there's a way to do this?)

go build -x will print the subcommands as it executes them, is that what you are looking for?

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.)

Oh god, so it's not just me... it really is slower...

From the 1.5 release notes

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.

Ok, cool. I can live with that :)

Thanks!

1.5->1.6 has roughly the same speeds. There are discussions about improving compiler speed in 1.7.

Does anyone know the current state of the SSA backend mentioned in https://news.ycombinator.com/item?id=9099744 ?

They moved it to 1.7 because it didn't get completed in time. You can see the source code here: https://github.com/golang/go/tree/dev.ssa (In particular, https://github.com/golang/go/compare/dev.ssa is interesting).

It's not clear to me what work is left, but hopefully it gets merged super early in the 1.7 cycle.

That's interesting! PHP 7 is getting one too - https://marc.info/?l=php-internals&m=144990711202803&w=2 - i wonder which will be completed first?

That sounds like an (e-)SSA-based optimization but not like an SSA backend.

Congrats on the release! Very excited about http2 and vendoring.

But what's happening with the work on shared libraries? :(

This was released in Go 1.5 for amd64. See https://golang.org/s/execmodes

HTTP2 in the standard library is a huge win. Really excited for this to drop!

Ah good, I've been waiting on a fix for one nasty bug in particular: https://github.com/golang/go/issues/3665

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.

Is that link right? You linked to a bug about http client support for Expect: 100-continue, and it looks like a fix was merged in October: https://github.com/golang/go/commit/dab143c8820151538fea908e...

Or are there still problems that aren't mentioned in that issue?

Well, yes, but the fix won't be included until the 1.6 release.

Is there any plan to add default keyword parameters to functions in go? In either 1.X or 2.X?

The Go dev's have noted they were happy they left default function parameters out of Go in the past--

Did they say why?

It's an extremely useful feature in Python, and makes for more elegant APIs.

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.

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.

> 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.

yes, it is clearer the Go way. things are up-front and obvious, easier to document, and less error-prone.

although your contribution in snark is much appreciated, you're incorrect.

> yes, it is clearer the Go way.

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.

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

[1] in an RFC 2119 sense

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.

No. It's a deliberate design choice: https://golang.org/doc/faq#Why_doesnt_Go_have_feature_X

I wish golang.org had an RSS feed.

blog.golang.org does: blog.golang.org/feed.atom

The linked article is part of the "static" documentation set though, which has no feed.

It's not ideal but Github does provide a "releases" feed, though it only links to the tagged commit (it's essentially a feed dump of https://github.com/golang/go/releases) you at least get a notification of new releases: https://github.com/golang/go/releases.atom

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.

you can add change notification to any page with this site

http://www.changedetection.com/

What, no generics!!!!!!

/kidding :p

Interesting, so "go 2.0" is 2 years down the road, it will be interesting to see what happens next.

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.

http://semver.org/

According to Ian Lance Taylor's recent post, there are no current plans for go2: https://groups.google.com/forum/#!topic/golang-nuts/ydeLGm2S...

Where did you get this idea?

I think 2.0 implies breaking backwards compatibility, which the Go devs have opposed on principle.

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

That's... what I just said...

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".

That's not how version numbers work.

Reply on news.ycombinator.com