
Go 1.6 Beta Released - omginternets
https://tip.golang.org/doc/go1.6
======
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.

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

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

~~~
mfer
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](https://github.com/Masterminds/glide)

~~~
driusan
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.)"

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

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

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

------
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](https://golang.org/dl/#unstable)

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

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

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

~~~
dilap
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?)

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

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

------
UniQP
Does anyone know the current state of the SSA backend mentioned in
[https://news.ycombinator.com/item?id=9099744](https://news.ycombinator.com/item?id=9099744)
?

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

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

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

------
jcadam
Ah good, I've been waiting on a fix for one nasty bug in particular:
[https://github.com/golang/go/issues/3665](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).

~~~
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...](https://github.com/golang/go/commit/dab143c8820151538fea908efe54e9625d1bc795)

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

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

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

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

~~~
akavlie
Did they say why?

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

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

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

~~~
fixermark
_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.

~~~
masklinn
> 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

------
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](https://github.com/golang/go/releases))
you at least get a notification of new releases:
[https://github.com/golang/go/releases.atom](https://github.com/golang/go/releases.atom)

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

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

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

~~~
sudhirj
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

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

