Go 1.6 Beta Released

[omginternets]

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.

[qznc]

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

[s3th]

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.

[florianletsch]

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.

[jamescun]

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

[omginternets]

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

[dvdplm]

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.

[iends]

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

[grey-area]

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

[omginternets]

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

[UniQP]

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

[iends]

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.

[mappu]

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?

[teabee89]

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

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

[enahs-sf]

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

[iends]

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

[jcadam]

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

[jerf]

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.

[infogulch]

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?

[jgalt212]

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

[ominous_prime]

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

[voidlogic]

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

[smegel]

I wish golang.org had an RSS feed.

[masklinn]

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

[SixSigma]

you can add change notification to any page with this site

http://www.changedetection.com/

[jshen]

What, no generics!!!!!!

/kidding :p

[aikah]

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

[vanderZwan]

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/

[PopsiclePete]

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

[zellyn]

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

[omginternets]

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

[mseepgood]

That's not how version numbers work.

[iends]

Where did you get this idea?