
Go 1.7 is released - techietim
https://blog.golang.org/go1.7
======
travjones
Great work, Go team!

Standout points in my opinion:

Overall performance improvements:

>> "We observed a 5–35% speedup across our benchmarks."

Decreased compile times and binary size:

>> "While these changes across the compiler toolchain are mostly invisible,
users have observed a significant speedup in compile time and a reduction in
binary size by as much as 20–30%."

Vendoring dependencies by default:

>> "...and in Go 1.7... the "vendor" behavior is always enabled"

Context package added to std lib:

>> "To make use of contexts within the standard library and to encourage more
extensive use, the package has been moved from the x/net repository to the
standard library as the context package."

~~~
mattetti
The faster compilation time & speed up is quite real in our real life prod
application.

From Go 1.6 to 1.7: Test suite (CI), from 3:34 to 1:48 Docker image building,
from 3:05 to 1:50

[https://twitter.com/mattetti/status/763913903600349184](https://twitter.com/mattetti/status/763913903600349184)

~~~
namelezz
Following the twitter link and got this: "Something is technically wrong.
Thanks for noticing—we're going to fix it up and have things back to normal
soon."

~~~
mintplant
I've noticed this too on random pages. Seems Twitter is having issues today.

------
chrisper
I just learned Go 2 days ago and today I am already running my own web app!

I love Go because it is kind of like C, but better (more modern).Generally, I
always program my stuff in Java, but whenever I have an idea of creating
something I could only choose between: C, Java, bash. Obviously I am not going
to use C and bash for most of my ideas. Thinking about solving my issues in
Java is meh so often I decided it is not worth it to invest time. I feel like
using Java for my ideas is like using a semi truck for roadtrips. It can be
done, but it's just not very efficient having to launch the JVM everytime I
want to do something small.

Yes, I was open to new languages, but I did not really care about: C++,
Python, Perl, Ruby and so on because I never cared about web dev. Now I was
bored and finally decided to learn Go.

~~~
ufmace
I suggest giving Ruby a try too. I find it great for both web dev and local
automation scripts. You can do pretty much anything you can do in bash but
with clearer and shorter code. I've been writing all my non-trivial automation
code in Ruby for years.

Rails is just a popular web framework for Ruby, there's a lot more the
language can do.

~~~
woah
It's annoying to have to install the ruby interpreter onto everything. Go
feels a lot like a scripting language, but produces binaries.

~~~
Spiritus
Then Python is a good alternative, it's basically already installed
everywhere.

~~~
Longhanks
'Everywhere' being most Linux distributions, an outdated version (2.7) on OS
X, no version at all on Windows.

------
geodel
Seems like a great release. Faster compilation and faster at runtime. Normally
these 2 are considered opposite of each other.

~~~
oxplot
And smaller binary size too. For a statically linked blob, that's a big plus.

~~~
cm3
BTW, what does one have to do to get fully statically linked executables? The
binaries I've created with go get SOMETHING are linking against libc, but I
remember that go doesn't rely on the system libc. Has that changed? For
instance I just installed git-appraise, and it's a dynamically linked
executable. What am I doing wrong?

~~~
Scaevolus
Go generally links to libc to use the system's getaddrinfo-- some OSes
override it to do special things with dynamically discovered hosts on local
networks, interfacing with LDAP/AD, etc.

If you use `CGO_ENABLED=0 go build`, it should make a statically linked
executable.

~~~
kyrra
I don't believe that has been true for a few releases now. I believe go
defaults to a pure Go resolver implementation now. You have to force enable
the cgo resolver.

[https://golang.org/pkg/net/](https://golang.org/pkg/net/)

~~~
f2f
from the same page:

"When cgo is available, the cgo-based resolver is used instead under a variety
of conditions: on systems that do not let programs make direct DNS requests
(OS X), when the LOCALDOMAIN environment variable is present (even if empty),
when the RES_OPTIONS or HOSTALIASES environment variable is non-empty, when
the ASR_CONFIG environment variable is non-empty (OpenBSD only), when
/etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go
resolver does not implement, and when the name being looked up ends in .local
or is an mDNS name."

------
cyphar
Yay, s390x support is finally in mainline! Finally we (SUSE) no longer needs
to use gcc-go to build Go binaries on some platforms (we've had nothing but
issues from gcc-go, half of the patches we apply to Docker are to make it
behave when built with SLE's gcc version).

------
ksec
Ok, off topic question. Not an expert in grammar, but something about "Go 1.7
is released" seems wrong to me. Anyone could tell me if this is an correct
usage of grammar?

Edit: Dont know why so many downvote, but it is a honest question.

~~~
prewett
It seems right to me (American speaker). "Released" functions as an adjective,
with similar meaning to "available." "Go 1.7 is available" would be
grammatically correct.

"Go 1.7 has been released" would also be correct, but uses the present perfect
tense.

So the question is, can "released" be used as an adjective? "The released
version has a bug" seems correct to me, and "released" clearly functions as an
adjective there.

All that said, the present perfect version seems clearly correct, while I
can't make a great argument for the adjectival version.

~~~
lobster_johnson
It's just present tense, usually known as "historical present" tense when used
in a headline like this. "Released" here might be intended as an adjective or
verb; it's ambiguous, but both are valid in the sentence structure.

------
Tehnix
>A new compiler back end, based on static single-assignment form (SSA), has
been under development for the past year

Huh, I was under the impression that either SSA or CPS was pretty standard for
any serious compiler. Does anyone know why they didn't design it for this from
the beginning? It's like one of the earlier things you learn when making
actual compilers.

~~~
enneff
It was more expedient to start with the Plan 9 tool chain that we had at the
time. Ken was already familiar with the code base, which was small and
compiled quickly (a few seconds). Because of this we got a lot done quickly,
knowing that we would eventually modernize the compiler.

~~~
thomasahle
How much is Ken involved in the language today?

~~~
bradfitz
Ken is not really involved in the project these days. His last commit was in
2011, before Go 1 was even released.

------
blinkingled
[https://github.com/golang/go/commit/a62ae9f62fcfca02075b70e6...](https://github.com/golang/go/commit/a62ae9f62fcfca02075b70e6e0aa757f4fd8f5ec)

> SystemCertPool returns an error on Windows. Maybe it's fixable later

This doesn't inspire confidence in Go as a cross platform language which is at
version 1.7. If this is implemented in say 1.8, am I supposed to check for Go
versions in order to know if the SystemCertPool func works or not? I mean why
not just release it when it works on all tier-1 supported platforms?

~~~
IshKebab
Go is _far_ better than most languages at supporting random system APIs. I
mean, you can cross-compile code on Windows that uses Linux syscalls. Try
doing that in Python. Actually I just Googled and I'm not sure Python even
lets you use syscalls. I also couldn't even find any third party library to
give you the system CA pool, let alone a first party one.

Tell me a language that has a first-party cross-platform library that allows
you to get the system CA pool on all platforms.

~~~
wbond
My third-party Python library that gives access to the system CA trust store:
[https://github.com/wbond/oscrypto](https://github.com/wbond/oscrypto)

------
stock_toaster
Be sure to check out the release notes, especially if you run FreeBSD (see
known issues section).

[https://golang.org/doc/go1.7](https://golang.org/doc/go1.7)

~~~
bradfitz
FWIW, this isn't a new regression on FreeBSD. We also saw these problems on Go
1.6 once we looked at our old build logs. It's just now documented.

------
sfrailsdev
vendor directories are no longer optional, which is nice.

Go get now update submodules... I'm honestly not sure what the current hack is
for package management, but I assume people are still doing wrappers around go
get to pin to commits/versions, (or else building your own repos for funsies),
and I'm wondering if that breaks anything.

~~~
Cidan
To be clear, vendor directories are still optional to use, you just don't have
to enable them by default.

We use a unirepo for all of our Go work, and being forced to use the vendor
directory would be a massive headache.

~~~
sfrailsdev
My understanding is that there is no longer an option to disable them as a
feature as there was in 1.6, though of course you don't have to use them.

~~~
nathany
Yup, and you can always rename vendor/ to _vendor/ if you want to ignore them
temporarily.

------
sdegutis
Cool. What's the plan for Go 8? What exciting features are up ahead?

~~~
bradfitz
SSA for all architectures, then delete the old compiler backend and optimize
the frontend which can then assume an SSA backend and do less work. (Currently
the frontend assumes a less-capable backend so has to do more work, which
actually makes SSA slower)

------
aprdm
I have some years of experience with python and picking up golang was
extremely straightforward.

Sometimes it annoys me a little bit because it's standard lib is much smaller
than python's however having it being compiled is more than worth it.

Thanks go team !

~~~
bberrry
That's been my feeling for a long time now. After getting spoiled by Pythons
enormous standard library, other languages feel incredibly bare-bones and
getting things done takes a lot more work. I wish other languages focused more
on including lots of library functions.

~~~
krylon
Size alone is only half (at best) of the equation. What makes Python's
standard library stand out is the way it is structured and documented.

Consider Java's standard library, which is _huge_. That last few times I did
anything in Java, I spent more time browsing the library documentation than
coding. Admittedly, I did not know the library very well, if one uses Java all
the time, that ratio probably changes. In Python I don't _need_ to know the
standard library well, because the way the documentation is written makes it
very easy to find what I am looking for.

------
cyphar
The one thing that really pisses me off about the way Go handled vendoring is
that they did it in a way that makes it incompatible with GOPATH. Previously
in runC and Docker, we had build hacks that would symlink (or full copy) the
current directory into vendor/src/<package> and then set the GOPATH to
vendor/. This was compatible with every go version. In addition, many other
projects did the exact same thing.

But the way that vendoring works in Go 1.5 and up is that you make vendor not
a valid GOPATH and you have to now either create a fake GOPATH and move your
current directory into it, or you have to do some symlink stuff within vendor/
that doesn't really work. Why was such a small cosmetic change seen as a good
idea? It's needlessly incompatible with previous ways of making vendoring work
seamlessly with Go.

I'm hoping that the packaging discussions that are going to be happening over
the next few months don't result in a similar decision that "we know best".

~~~
lobster_johnson
If anything, the Go people have repeatedly claimed they _don 't_ know best --
because Google famously uses a huge monorepo with all deps vendored, and don't
do "package management" as such -- and have preferred to let the community
find a solution organically.

Which is also why we ended up in this frustrating profusion of competing tools
(Godeps, Glide and many others, plus the messy business that is git
submodules) rather than a concerted effort towards a unified solution.

I don't at all believe the argument that they can't design something because
they don't need it at Google. They're engineers, after all. You don't need to
use a bridge in order to build one. There are plenty of existing tools
(Bundler, Cargo, NPM, Cabal) that can also be used as case studies in how to
do things right (Bundler, Cargo) or don't do them wrong (NPM).

In my company we use Glide, which is the best solution I've encountered so
far, but it's beyond buggy, and struggles with some Google repos that need to
be flattened in order to avoid duplicate, conflicting dependencies (glog and
pflags, sigh).

~~~
cyphar
> If anything, the Go people have repeatedly claimed they don't know best

So why is the defacto vendoring system for the Go tooling incompatible with
old Go versions (the "organic" solutions _were_ compatible with Go versions
without vendoring support because they were implemented before vendoring
support was a thing!)?

The vendor/src hack meant that you could compile with _ANY_ version of Go --
that's important for distributions (and other people who want to build runC
and Docker -- put plainly we pin Go versions because of compiler bugs). But
no, now we have to use vendor/ which means that now we have to do even more
messing around with the GOPATH (which makes rpmbuild even more ugly than it
needs to be). _sigh_

~~~
lobster_johnson
I can't explain that since I'm not on the Go team. However, it's possible that
they also didn't realize this hack was being relied on by people. The fact
that you describe it as a hack implies it was never _intentionally_ supported
behaviour. Did you bring it up during the development of 1.5?

~~~
cyphar
> The fact that you describe it as a hack implies it was never intentionally
> supported behaviour.

It's used by the largest Go projects that exist. So if the Go developers
didn't look at what the largest Go projects do and take inspiration from that,
I'm really not sure what else to say.

A hack that is used by everyone is relied upon behaviour. I wouldn't even call
it a hack, it's trying to make Go's obsession with your filesystem actually
usable -- why on earth does my compiler toolchain care about how my home
directory is structured?

The old method still works, you just have to call the directory something
other than vendor/. Which just defeats the whole point.

> Did you bring it up during the development of 1.5?

My experience with Go 1.5 was a lot of other (more serious) bugs, so I didn't
have a chance to comment on that particular issue. I'm surprised nobody from
Docker said anything though.

------
WhitneyLand
Elevator description:

    
    
      - Open source, 6 years old, backing from Google
    
      - Nice for concurrency and service implementations
    
      - Not nice for generic types
    
      - C like, modern, minimalist, garbage collected
    
      - Becoming more popular

------
jcadam
I wish the Clojure compiler was half as fast as Go's :(

I'm not much of a fan of using Go for anything 'big', but I have taken to
using it in places where I would have previously used Python (tiny/simple
services, housekeeping/utility scripts fired by cron, etc.)

I'd love to use Go at work (amongst many other things), but my employer
already gives me a hard time for writing small utilities in Python rather than
Java (I refuse to wait for a JVM to spin up just to convert a single file from
csv to xml. I simply will not do it, and apparently my employer doesn't
consider it worth firing me over).

~~~
infinotize
What makes you choose Go over Python for simple services and utility scripts?
(I'm just learning Go but would heavily lean towards Python for those things)

~~~
jcadam
Off the top of my head:

\- Ease of deployment. It's a standalone binary - I don't have to ensure
python and all needed libraries are installed/configured.

\- I like Go's standard library - it usually has everything I need to whip up
a basic network service easily.

\- Better/easier concurrency support.

\- It's faster than Python (though that's usually not incredibly important
most of the time).

------
tmaly
Great work,

I am looking forward to recompiling my code to see how things are. I have had
my side project running on a set of Go micro services compiled against 1.4
since last year.

What can we expect from Go 1.8?

~~~
nathany
You can read through this thread to see what people want to work on for Go
1.8.

[https://groups.google.com/forum/#!topic/golang-
dev/098vr4999...](https://groups.google.com/forum/#!topic/golang-
dev/098vr4999Tk)

------
maxpert
Awesome! Time to recompile RaspChat :D

------
yuyuyy
Is Go based on llvm? It doesn't seem like it, but would be curious to know why
not?

Isn't this the point of llvm, to separate the "language component" from the
"cpu component"?

~~~
micro_cam
There are llvm (and gcc) implementations of go but main/reference
implementation was written from scratch in C and later moved to pure go. IIRC
the authors wanted to achieve really fast compilation and a few other things
that required them to start from scratch.

~~~
nathany
There was also the matter of figuring out llvm in order to use it. The initial
Go compiler was based on the Plan 9 C compiler toolchain, which the designers
of Go know well.

One of the other reasons relates to how stacks are handled for goroutines.

------
nilso
Nice work

------
litaohackernews
The semantics of Go is too ugly. It has no taste.

~~~
spriggan3
It's also a necessary "evil" to demonstrate that languages should have the
right amount of features, no more and tools are part of a language, along with
ease of deployment. It's is questionable whether Go strikes the right balance
when it comes to features vs "simplicity" though, but it might inspire better
solutions in the future. I think MSFT is trying to follow the same path with
.net core and its tool chain, I hope they succeed as C# and F# are vastly
superior to Go.

~~~
mixedCase
>I hope they succeed as C# and F# are vastly superior to Go.

In number of features, yes. Everything else and you come off as opinionated. I
cannot comfortably write C# from my Linux workstation since all the tools are
Windows-first.

C# is a language where everything must be done in classes and inherits a
C++/Java school of OOP which I find abhorrent as it tends to favor
monstrosities of abstraction upon abstraction. I can almost always read a Go
codebase and get a good general sense of what it's doing in a few minutes, I
can't say the same about C# codebases, and I have worked with C# for around
the same time I've worked with Go.

These things aren't clear cut for everyone the same way.

~~~
lobster_johnson
C# in VSCode is really good, and works on Linux. Have you tried it?

