Great work, Go team!<p>Standout points in my opinion:<p>Overall performance improvements:<p>>> "We observed a 5–35% speedup across our benchmarks."<p>Decreased compile times and binary size:<p>>> "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%."<p>Vendoring dependencies by default:<p>>> "...and in Go 1.7... the "vendor" behavior is always enabled"<p>Context package added to std lib:<p>>> "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."
I just learned Go 2 days ago and today I am already running my own web app!<p>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.<p>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.
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).
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?<p>Edit: Dont know why so many downvote, but it is a honest question.
>A new compiler back end, based on static single-assignment form (SSA), has been under development for the past year<p>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.
<a href="https://github.com/golang/go/commit/a62ae9f62fcfca02075b70e6e0aa757f4fd8f5ec" rel="nofollow">https://github.com/golang/go/commit/a62ae9f62fcfca02075b70e6...</a><p>> SystemCertPool returns an error on Windows. Maybe it's fixable later<p>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?
Be sure to check out the release notes, especially if you run FreeBSD (see known issues section).<p><a href="https://golang.org/doc/go1.7" rel="nofollow">https://golang.org/doc/go1.7</a>
vendor directories are no longer optional, which is nice.<p>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.
I have some years of experience with python and picking up golang was extremely straightforward.<p>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.<p>Thanks go team !
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.<p>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.<p>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".
Elevator description:<p><pre><code> - 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</code></pre>
I wish the Clojure compiler was half as fast as Go's :(<p>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.)<p>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).
Great work,<p>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.<p>What can we expect from Go 1.8?
Is Go based on llvm? It doesn't seem like it, but would be curious to know why not?<p>Isn't this the point of llvm, to separate the "language component" from the "cpu component"?