
Go 1.6 is Released - geetarista
https://blog.golang.org/go1.6
======
sinatra
Go checks a lot of boxes for _my_ ideal language for developing web services:
Static type, C derived, has garbage collection, generates a single binary,
supports concurrency very well, is opinionated, is small/simple, its community
prefers to just use standard lib for most work, etc. Yes, Generics is an issue
and so is debugging. But, overall, I can't think of many other options that
check so many boxes.

EDIT: I must highlight the point about checking lot of boxes. In many
discussions about features of programming languages, we get responses like,
"language Y does that too. Why not choose that language?" Well, because we
don't pick languages for one specific feature. We pick them for the
combination of features.

~~~
meddlepal
Java SE and a fat jar... checks all the boxes and has generics and superior
tooling.

I still don't get the Go love.

~~~
autoreleasepool
I don't like Oracle. I don't like the JVM. I refuse to learn Java because I
personally have a strong bias for native, compiled code. In fact, I really
dislike everything about the Java way of programming. The mental image of a
huge ram sucking IDE with code completion for frameworks is simply
incompatible with what I would consider the ideal creative process for me as
programmer.

That being said, if I were starting a web service as a business today, it
would be _very_ hard to persuade me to not choose Java. It's simply the best
platform from a business perspective. For better or worse, CS departments
across the US produce Java programmers more than anything else. This makes it
very easy to hire Java developers. Java has stability, Java has concurrency,
Java has hot reloading, Java has a good track record, Java scales, Java has
really nice functional programming support, and Java is _very_ popular with
the everyday programmer. It Java has so many benefits outside of it's
technical or philosophical specifications, that it's almost an obvious choice
to me for web.

What's funny is that Erlang _is_ the ideal platform for me from an idealist
perspective, but I don't think I have the luck or experience it takes to
successfully start an internet company with Erlang.

~~~
StevePerkins
> The mental image of a huge ram sucking IDE with code completion for
> frameworks is simply incompatible with

> what I would consider the ideal creative process for me as programmer.

Java has long been my primary professional language, and over the past few
years Go has taken on a strong secondary niche at my job. I'm big fan of both,
and tend to play Switzerland in arguments between them.

That being said, the best Go IDE out there right now is the official Go plugin
for IntelliJ... which again, happens to be the best Java IDE out there. If you
are doing modern software development in ANY language, then you are probably
traveling one of three paths:

(1) Using an IDE based on JetBrains or Eclipse.

(2) Using a variant of Microsoft Visual Studio, which is about an order of
magnitude more bloated than #1.

(3) Using a plain text editor, which for a typesafe language is a bit daft.

~~~
logicchains
What does the Go plugin for IntelliJ offer that Go plugins for Emacs don't? My
setup right now has live error checking (highlights errors as they occur),
gofmt on save, safe refactoring via gorename, jump-to-definition, proper
autocomplete, and Go Oracle integration, for e.g. finding all callers of a
method. Due to being Emacs it also has much better support for Vim keybindings
via Evil mode.

~~~
dlsniper
Debugging, cross-platform, integration with a lot of other languages, and
databases, local history, out of the box configuration for everything you've
just mention (including the Vim key working mode, via a plugin) so that people
don't spend time in doing all of that and so much more :)

~~~
logicchains
In what way is IntelliJ more cross-platform than Emacs?

~~~
twistedpair
It's written in Java ;)

------
jonesb6
The reason I love Go is that every time I pull it out, I write a small amount
of it and it runs beautifully. For example my company has a critical micro-
service implemented in ~300 lines of Go, it's been running for six months now
without a single hiccup, highly performant, very sexy.

The reason I will almost never use Go for web apps is because interaction with
databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by
the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's
a huge drop in efficiency to spin my own SQL.

The point to take away here is that Go, more so then many other languages IMO,
has its strengths and weaknesses. If you use Go in one of it's weaker use-
cases you're gonna have a bad time. If you use Go for one of it's strengths
you're gonna have a great time.

See you guys and gals in n weeks when we need to rehash the pros and cons of
Golang again.

~~~
no1youknowz
> The reason I will almost never use Go for web apps is because interaction
> with databases is limited > but it's a huge drop in efficiency to spin my
> own SQL.

Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM
appears. I actually am a DBA also. I am very familiar with SQL and I love
writing out raw SQL.

I don't see this as a limiting feature. It doesn't affect me at all.

There are ORMs for Go as well. But I don't know how good they are. YMMV!

Last point. I have shipped into production a web app using GIN framework. I
ported from PHP to Go. I didn't feel I was losing anything.

Go is amazing. It hasn't let me down yet. I doubt it will.

~~~
fleetfox
What are these ORMs you are speaking of? Only usable ORM i've seen for PHP is
Doctrine.

~~~
Ruhigengeist
Any framework has their own. Yii implements active record, I've been working
with that for a few years now and I really love the paradigm.

------
nathany
There is a Go AMA on reddit for the next 24 hours.

[https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...](https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/)

~~~
lsllc
OK Go are also doing a reddit AMA!

[https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_w...](https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_were_here_to_talk_reddit_so_ask_us/)

------
eddiezane
I've really enjoyed the time I've spent with Go but feel like the state of
dependency management has kept me away.

Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a
reason why one of these hasn't emerged/been adopted by the community? (I'm
aware of the 1.5 experiment with vendoring.)

Semver and pinning versions has always just _made sense_ to me. I can easily
adopt new features and fixes automatically without worrying about things
breaking.

How does the community feel this far along?

~~~
munificent
> Is there a reason why one of these hasn't emerged/been adopted by the
> community?

Personally, I believe package management is one of those things that really
does need an official blessed solution. Otherwise, you have a nasty
bootstrapping problem: if there are ten competing package managers, how do you
install them, and how do package developers know which one to put their
packages in?

Collection types have the same problem. You basically need to put some
collections in a blessed core library, otherwise it's virtually impossible to
reliably share code. Any function that wants to return a list ends up having
to pick one of N list implementations and which ever one they pick means their
library is hard for users of the other N-1 lists to consume.

The Go team hasn't blessed a package manager, I think, because it's not that
relevant to them: they mostly live within Google's own infrastructure which
obviates the need for something like version management. They probably don't
feel the pain acutely and/or might not have the expertise to design one that
would work well outside Google.

~~~
prodigal_erik
Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a
language to consider a solution worthy of blessing when it doesn't interop
with the one my platform was already using or even the ones other languages
have.

~~~
munificent
> Use the platform's blessed solution (rpm or dpkg).

Most languages are cross-platform. No language maintainer is going to say,
"sorry, Windows, Mac, or <random Linux distro> user, you don't get to use our
language."

Likewise, you can't require every package maintainer to just publish their
package to every single OS and distro's package repository every time they
want to release a new version. Well, you _can_ , you just want have any users
if you do.

~~~
conceit
But it makes sense if half the configuration (or what not you expect from a
package) is platform specific, like where do the libraries and resources live,
does pip know about the windows registry? I doubt it.

------
Cyph0n
I can't wait to see what's new in 1.6! I really had a pleasure working with Go
for my senior project last year. If I need to write either a server (HTTP or
TCP/UDP), or a client application that must be easy to build and distribute,
Go is my first choice.

What Go is lacking at this moment in my opinion is:

1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice
now, with Django a very close second.

2) A decent cross-platform GUI toolkit; heck, I'd settle with Qt and/or .NET
bindings for Go. The power of Go is statically linked binaries, and I think
the area of desktop applications will be easy to target if a good solution
emerges.

~~~
golergka
Why GUI though? Go shines for servers, but I would never want to write a
desktop application with it though. Especially if I could do it in C#.

~~~
Cyph0n
The way I see it:

1) Go produces 100% portable code. I absolutely suffered doing the same for a
very basic C++ program that used C++11's std::regex. Compiled fine on
clang-3.5 on OS X, fails on clang on Linux. It took me hours of searching
online to find and install the exact version of GCC that actually fills in
std::regex instead of just keeping it empty. Trust me, there are some versions
that do that! No errors during compilation, but still doesn't run.

2) Statically compiled binaries. I can be confident that the absence of some
essential library from the user's end won't break my app.

3) Cross-platform, especially with something like Qt. Write once, compile for
each OS, then run - done!

~~~
tosseraccount
Go programs can link the Qt library, specifically the GUI components,
statically? ... it produces one output binary per target OS?

~~~
Cyph0n
I have not tried Qt with Go to be honest, but in general yes compiled Go code
produces a single statically linked binary on the target OS.

~~~
noselasd
You can't currently link to Qt statically though. (And holy smokes, that would
be a huge binary if it did, just libQt5Widgets.so links to 49 other libraries,
everyting from X11 libs to libbz2 to opengl)

------
dominotw
I've been writing some gocode recently and huge chunk of code is

 _if err != nil ..._

I know you can do if ; err!=nil but that not that much better and you end up
in deeply nested if blocks.

i have to mentally block out err !=nil to read any gocode linearly. How is
this acceptable, I don't get it.

[https://blog.golang.org/errors-are-values](https://blog.golang.org/errors-
are-values)

 _We recently scanned all the open source projects we could find and
discovered that this snippet occurs only once per page or two_

This seems false from my experience, def way more than 1 or 2 instances per
page.

~~~
dilap
Hard to say without specifics, but my experience writing server code in, say,
Python, was, I ended up wanting to handle errors in the best possible way, so
my code turned into:

    
    
        try:
            x := blah()
        except Foo:
            yadadad
    

which is worse (IMO) than

    
    
        x, err := blah()
        if err != nil {
            yadada
        }
    

Besides the extra syntactic clumsiness, it was really hard to know what was
going to throw exceptions, and which exceptions, and when. Frequently I would
get bugs from unexpectedly thrown exceptions.

You said "I have to mentally block out err != nil to read...code" \-- for me,
the error handling code _is_ code, code I want to pay just as much attention
to as the non-error path.

So for that reason I really like Go error handling.

For a client-side script or something, maybe this isn't true; feel free to use
log.Fatal or panic if that makes sense for your use case.

~~~
randallsquared
> for me, the error handling code is code, code I want to pay just as much
> attention to as the non-error path.

You likely want to pay as much attention as required to make things work, but
the purpose of your code isn't to generate errors -- errors are what get in
the way of the actual purpose of your code.

For people who want to get an overview of what some code does, the error code
is interesting only after you understand the actual purpose, and sprinkling
the error code throughout the code that describe the purpose of the program
causes distraction.

~~~
dilap
A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll
reopen the app and try again/rerun the script'), but I think not so reasonable
for server-side code..

There's element of personal preference here.

The longer I program the more I favor systems and styles that minimize
unexpected problems; explicit error handling is very much in that vein.

Another complication is that the word "error" actually encompasses two very
different kinds of situations:

(1) expected-but-non optimal external conditions (there's no file at that
path, the tcp connection got closed) and (2) unexpected conditions caused by a
bug (array index out of bounds, the regular expression typed into the code is
invalid).

Handling (1) gracefully is very much part of the actual purpose of your code:
files WILL be missing sometimes, network connections WILL die, so it behooves
you and your program to think about these situations as first class.

(2) is not part of the purpose of your program, it's an error IN your program.
These are best handled by crashing/exceptions/panic.

A lot of languages mix the handling of (1) and (2), e.g. Python and some
styles of C++, which use exceptions for everything. Go uses explicit error
returns for (1) and panics for (2), which feels right to me.

~~~
randallsquared
> A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll
> reopen the app and try again/rerun the script'), but I think not so
> reasonable for server-side code..

This seems like a response to something that wasn't my comment. I even went
out of my way to state what I thought might be obvious: "pay as much attention
as required to make things work".

 _Handling errors is a given in this thread._ The question was how to
represent that in the structure of the program.

> There's element of personal preference here.

I agree that there's some of that, but if you accept that the main purpose of
programming language syntax is to ease reading, writing, and understanding
programs, then preference only matters to the extent you can know it, and most
of us can assume that we do not know the preferences of the people reading and
trying to understand our code. Given that, we must try to use somewhat more
objective measures.

When reading code, is it more useful to get a broad overview of the algorithm,
or more useful to dive into every possible branch? The answer to this won't
always be the same, but for a given type of code it will likely lean heavily
toward either breadth-first or toward depth-first readings, which correspond
fairly closely to whether error handling is done locally at the site of the
error. Further, I think most programs will benefit more from a breadth-first
organization, such that errors are better handled (syntactically) in a way
that doesn't interrupt the process of understanding what the code is supposed
to do.

Go has a lot of things I like, but the difficulty of laying out a clear "do
this, then this, then this, then that" is not one. Either you end up with "do
this (or handle the error from trying to do that by doing this other thing),
then this (unless there's an error here, in which case...)", or you abuse
panic, or explicitly ignore errors. If you're in this situation, then the
first is the best of a bad lot, but unless you're doing some very finicky,
low-level code, it would be nicer to be able to handle errors outside of the
purposeful flow of the application.

I agree that having a distinction between different kinds of errors is nice,
but errors of type (1) are not the purpose of your code. They're problems that
prevent your code from fulfilling its purpose. That's a whole different
conversation, though. :/

~~~
sacado2
> errors of type (1) are not the purpose of your code. They're problems that
> prevent your code from fulfilling its purpose.

I don't really agree with that. In a module that checks whether a user has the
right credentials to perform a given task, for instance by checking the used
IP is correct and a correct password is given within 3 attempts (or else the
account is blocked), dealing with errors (checking password is valid, checking
IP is valid, checking account is not blocked, blocking it if needed) _is_ the
purpose of the module.

This is the same with any kind of automaton. Knowing when you go into an error
state and how you get out of it is part of the problem you deal with.

------
golergka
I just recently started with go, but I love how simple (apart from horrible
$GOPATH) and effective that is.

Still can't get over the moment I realized that in order to deploy my web
server on an empty virtual box all I had to so was to build and upload. After
all the languages and frameworks that required endless customization and
setting up it was a true eureka moment.

~~~
sigjuice
What is horrible about $GOPATH?

~~~
golergka
The notion that you can't put the codebase wherever you want to on your own
computer. A "project", as a folder, should be atomic and work regardless of
where it is moved; the $GOPATH convention just breaks this encapsulation
completely.

For example, when I create client-server projects, sometimes I put both client
and server under the same git repository, in the same folder (whether it is a
good or bad decision is another discussion). $GOPATH forces me, therefore, to
put a client project in the $GOPATH tree, and this just feels ugly.

Of course, you can change $GOPATH per project, and I end up with `export
$GOPATH` in makefiles, but this is rather ugly too.

~~~
sigjuice
I completely agree that a developer should have the freedom to put the
"project" folder anywhere. As a golang newbie, I went through the motions of
setting up GOPATH, but did not give it too much consideration. It also isn't
clear to me how one might have multiple copies of the same project.

~~~
golergka
> It also isn't clear to me how one might have multiple copies of the same
> project.

A lot of technologies employ temporary, cache data storage to build for
specific platforms and/or configurations. This data is derived from the actual
project, and is not saved in the repo, but it often takes significant time to
generate.

For example, I work with Unity3d. Unity3d has a great graphics pipeline; if
you release the same project for different platforms, you still have the
original PSD textures in source control, and they are automatically exported
to relevant graphic formats when you switch between different platforms.
However, this generation takes a LONG time on different projects, and you
usually have several copies of the project on your hard drive, each with a
different platform selected.

git even introduced a feature that is usable precisely for that scenario,
worktree.

~~~
sigjuice
Sorry, I should have phrased this a little better. What I meant to say was
that I almost always have multiple copies of the code that I am actively
working on. And if Go has restrictions on where you can place your source
tree, then it complicates the ability to have multiple copies of it.

------
protomyth
Can someone give a decent explanation of the following:

1) Supposed I have a library that was written in C that receives a security
update which is used in a Go program. Under what conditions do I need to get a
recompiled version of the Go program.

2) Supposed I have a library that was written in Go that receives a security
update which is used in a Go program. Under what conditions do I need to get a
recompiled version of the Go program.

3) Is there a way to tell from the binary that the program was written in Go?

Trying to figure this out for my Sys Admin dealing with Vendors role.

~~~
spacey
3) A compiled Go binary contains the import paths of all used libraries plus
all variable names that they are using. Also the header of the binary contains
a string like "Go" followed by a hash. If you open a binary in a Hex Editor
you will see it yourself.

~~~
protomyth
So I should be able to write a program or one already exists to check if its a
Go program and what its dependencies are.

------
jernfrost
Read the debate with Go vs Java here with interest. I'd like to add a point I
think is missed by the Java crowd in favor of Go.

Complexity isn't free. Java might have and abundance of tools, IDE's, language
features etc, but you can't claim that matching up every Go feature or tool
with something superior found among the huge Java universe makes Java superior
in every way.

I find that there is an unfair assumption being used by the Java advocates,
here which is that every software developer has a deep knowledge of Java.

As one of those people who can certainly write Java code, but who is not
familiar with the Java eco system and has not spend a lot of time with I must
say that Go to me is a clear winner.

My exposure to professional Java development has been quite frustrating
compared to writing Go code. Every Java project I have gotten has used some
different built tool: Ant, Maven or Gradle. They have also all seem to use
different IDE's. The complexity of each of these tools is staggering.
Considerable time has to be spend learning these tools.

Go in comparison is laughably simple. You can get productive in less than a
week without ever having used the dam thing. The tools and the libraries are
very quick to get into. In fact I find Go code so easy to read that although I
am an iOS developer by trade, I frequently read Go code to understand how
various algorithms and network stuff works.

An organization would easily be able to add people to a Go project without
much previous exposure to the language. Adding people with limited Java
knowledge to a Java project however would be far more expensive. Considerable
time would be needed for training.

There is a lot of money to be saved from having a well thought out standard
library combined with a simple language with simple well thought out tools.

As a Swift/Objective-C developer, my major gripes with my development process
is actually the complexity of the tooling. Both Swift and Objective-C are
fairly straightforward languages IMHO. In this regard I greatly envy Go
developers although I do enjoy the strong typing and generics in Swift.

------
kampsy
I fell in love with python because it was clean and easy to work with. Like
most developers, I used to use c when I needed a performance boast. Then I got
fade up and decided to learn a new language that could give me the feel of
python and the performance of c. Two languages from a list of 10 passed the
above criteria Go and Rust. Java did not even make the list because I Don't
use languages that are owned by evil empire's(Oracle).

I went with Go because it was easy to use and understand. I could read other
people's code easily( Even with a large code base, I have never found myself
scratching my head trying to figure out my own code does), could set up my
workspace in less than a minute and all the text editors I used (sublime,
Atom, Vim) supported it. I Don't really care about the fancy IDE's. Just
syntax highlighting and code completion is good for me.

I started learning go on September 2015. And I have managed to implement the
porter stemmer algorithm and an inverted index in it. Miss generics but LOVE
interfaces. The fact that any concrete type that implements method 1 satisfies
interface 8 is awesome. You can easily reuse code from different package
without changing anything.

------
alblue
Release notes are here:

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

Notably new this time is transparent http/2 support and tighter rules for
integration with C.

------
dh997
Go CSP is minimal and ortongonal, I just wish it did three things:

0\. could lto optimize or link against a shared library to reduce the titanic
size of compiled programs and cut down on duplication of instruction. Therue
is no practical sense in wasting memory and storage on systems with dynamic
linkers: edge cases of including the world for rare situations but YAGNI in
real production systems.

1\. could output flat binaries and self-host runtime (panics) for practical
kernel development in Go

2\. Generics (both types and immutable constraints), I think C++1z has the
right approach to this (and constexpr and constant arrays are nice and are
able to provide more hints to the compiler).

I also wonder why Go wasnt developed as an IR compiler / llvm frontend,
because it would've levered an existing debug and portability ecosystem with
much less work.

~~~
hacknat
0\. It does dynamic linking on most stdlibs (libc, etc)

1\. What do you mean self-hosted runtime? Anyways, golang will likely never be
a good candidate for kernel development, but in theory you could do it (go
supports assembly)

2\. Generics would be nice. Who knows, maybe they'll be in 2.0?

Go wasn't developed in llvm, because they wanted to build something very fast,
and they were planning on writing the compiler in golang from the start (so
that it could be part of the libs). Also having your own scheduler kind of
breaks debugging, you can build go programs with gccgo, but gdb doesn't work
because it has no concept of what a "go routine" is. Delve
([https://github.com/derekparker/delve](https://github.com/derekparker/delve))
will eventually fill the hole of the missing debugger, imo.

Edit:

Formatting

~~~
aikah
> 2\. Generics would be nice. Who knows, maybe they'll be in 2.0?

There will be no 2.0 and there will be no generics, at all.In fact there will
never be any changes to the type system, cause it's impossible at this point.

~~~
hacknat
Not that I even care that much, but that's total crap. Compile-time generics,
which is what most people seem to be referring to when they say they want
generics in Go, are eminently doable. It would not be hard to implement.
Runtime generics are probably possible as well.

What are you even basing your assertion on?

Edit:

What do you mean, "there will never be a 2.0"? Do you have a crystal ball?

~~~
pjmlp
The team has already stated "The language design is done".

~~~
grey-area
The issues list has a bunch of breaking changes they've put off to Go2. It
won't come soon, but probably at some point they will produce a Go2, if only
to fix a few small annoyances and things they got wrong in the stdlib which
would otherwise break the Go1 pledge. Of course, that doesn't mean Go2 will
introduce lots of huge changes to the language, I doubt very much it would,
but it probably will happen sometime.

[https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+l...](https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3AGo2)

As another datapoint, here are the answers of the team to a question on what
they dislike about Go1. These are mostly breaking changes which would require
a Go2. I don't think anyone is hostile to it long-term, they're just not in a
hurry. There is a _huge_ value to developers in not having churn in an
ecosystem and breaking changes, I and many others really value that and am
pleased they take this approach.

[https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...](https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03s41s)

So I think you've misinterpreted the above statement, it was probably an off
hand remark in response to proposals for Go1 which would have radically
altered the language (I can find no ref to it on the web, 0 results for that
phrase).

~~~
pjmlp
Update to my reply.

"So… when is Go 2?", Slide 38

"No plans. Maybe never.", Slide 39

[https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMN...](https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMNvpo7ntqteWQfynq9hFTCkhQ/view?slide=id.p&pref=2&pli=1#slide=id.g118cf9b85c_0_404)

------
zenlikethat
Congratulations to the Go team! There are many excellent folks working on the
Go language and it's been an absolute joy to work with in my experience.

------
ukd1
[https://golang.org/doc/go1.6](https://golang.org/doc/go1.6) \- lists the
changes

------
sriram_malhar
Have been using Go since its release, and like the deployment experience, the
feeling of solidity of putting together a tight system. The toolchain is
great. 1.6 is yet another Solid release in that direction. Thank you all.

However, the _language_ doesn't give me much programming pleasure alas. Since
there is plenty of time for Christmas, here's my syntax wish list :)

'?': C's if-then-else operator.

Block-syntax for closures ala Ruby. Unifying blocks and closures makes
creating DSLs easy, but doesn't add to cognitive load (no more than using anon
funcs)

Pattern matching like Scala, ML, Rust.

Sum types -- (Yeah, I lied. Not just syntax enhancements), or at least
discriminated unions. I'd like to see an example (in the FAQ entry on the
topic) on why support for it is troublesome.

For 2017 Christmas, \-------------------

Macros ala Nim.

Systemic support for Goroutines, including detection of conditions where a
goroutine would never get scheduled. Erlang-like tools for built-in goroutine
insight.

\------

My ideal language would be an intersection of Nim+Go

~~~
sacado2
Sum types don't play well with zeroed values by default. What is the zero
value of a sum type ?

Pattern matching doesn't work well without sum types.

So don't hold your breath.

------
Exuma
I upgraded and it broke our app, something to do with the way it handles https
has changed, not sure what

~~~
nathany
If it works in Go 1.5.3 but not Go 1.6, definitely consider filing an issue.
[https://github.com/golang/go/blob/master/CONTRIBUTING.md](https://github.com/golang/go/blob/master/CONTRIBUTING.md)

------
niccaluim
Not officially. "Go 1.6 is soon (but not yet)." \- commit message from today.

~~~
bsg75
I _just_ got this email:

"Hello gophers,

We just released Go 1.6.

You can read the announcement blog post here:
[https://blog.golang.org/go1.6](https://blog.golang.org/go1.6)

..."

------
bmh_ca
Go has a lot going for it.

That said, there were a few points I noted, based on a recent go I gave it
(pardon the pun), at least in relation to my style of development for this
project:

1\. It's hard to tinker, mostly because it's fussy about what variables are
defined or used. This is a strength in the usual course, but when one is
trying to posit what a poorly documented 3rd party API is doing it can be a
serious pain.

By tinkering, I found that I often had to comment out or uncomment lines, or
handle or ignore errors. There was a lot of flipping up to the beginning of
the file. I would spend so much time fiddling with the lines that I would at
times forget what I was even trying to do.

I might just have memory problems, I acknowledge. :)

However, what would make sense is a go "mode" where it runs in a non-strict
way, with what would ordinarily be errors being warnings. A "tinker" or
"whirl" mode, so to speak, that softened the requirements so one could get a
better sense of what was happening before committing to a design.

An interpreter mode might also be quite valuable, to address this problem and
the ones below.

2\. Error propagation - I see the point of errors being returned and the lack
of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for
marginal gain. I usually end up with an error propagating a set of strings
that ultimately conclude as: "Database error: transaction error: processing
error: http error: _reason_ ", which is to say: equivalent but less
information than a stack trace would give. I see the mandatory error
acknowledgement simultaneously as a strength and a waste of time, and I admit
being on the fence about it.

3\. The next point I am not on the fence about: Debugging. It is not apparent
how to get a stack trace, and the best option looks like including a third
party application that generated errors. For the obvious and reasons below,
this is a problem.

4\. Package management: This was fussy and could be time-consuming. It is not
apparent to me why one needs a GOROOT and a GOPATH. I think Python's
virtualenv gets it right, by comparison. A second but related problem is
package versions. Maybe I'm missing something, but making sure you get the
latest semantically equivalent version (in the semver sense) was not apparent.

5\. Package debugging: If you include a 3rd party package, and it's broken in
any way, it's a veritable quagmire to identify and fix the problem. My
experience was that the best way to debug a third party package was to block
and copy all its bits and then debug it as a local source in your own.
Obviously this is bad for a long number of reasons, and I might be missing
something, but no more apparent option appeared when I investigated on how to
tell what is even happening inside third packages.

6\. Automated testing: I've not seen a test runner that reloads when source
files change, particularly one that might be used with goapp from AppEngine,
meaning go auto-testing can be quite a bit of patient thumb-twiddling as the
binary reloads.

Which is all to say that there are some concerns about developing a larger
project in this language, particularly if there is quite a bit of complexity
that needs lots of testing or potential debugging and/or inclusion of many
third party packages.

I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent
there.

In any case, none of the issues above is insurmountable, and overall I give
the Go design a lot of credit for experimentation and interesting choices, but
the issues I've seen above give me pause before committing a team to the
language – for the moment.

~~~
zenlikethat
For (1), I'd highly suggest using 'goimports' (my editor's fmt-on-save uses
'goimports' by default). It will remove and add non-referenced imports as
needed. Also, quick prototyping is partially what the underbar (_) notation is
meant for in variable assignments.

As for (2), I feel it's more of a consequence of programmers not using error
types to its advantage. Since Error is an interface it allows for an absurd
amount of flexibility (e.g. bundle up a whole bunch of information into one
error and send it back) and typed errors, both of which are excellent for
testing and debugging.

As for (3), I usually rely on printing output (github.com/davecgh/gospew is
quite useful). To get a stack trace just calling panic() in the offending code
area will suffice.

No arguments on (4) - it could be better - but I think support for vendoring
is a good step, and the maintainers seem to be taking it slow and getting it
right.

On (5) -- if you go get the package it's available in GOPATH and/or it's
usually vendored, so you can just go edit it in place (including debugging
statements if you need more insight) without needing to know any magic $X_PATH
rules -- I see this as a huge advantage. Furthermore, go get-ed code is each
in its own version control repo, so sending patches back upstream is
(generally) easier than ever.

Anyway, hope I don't seem argumentative (everyone has different tastes), but
maybe some of these suggestions might help you a bit with your language
peeves.

~~~
bmh_ca
Great feedback, thank you.

On (1) Great suggestion, looks good.

On (2) I'm probably biased by having spent a lot of time with Python and
Javascript and bound to some preconceived notions of how one should deal with
exceptions, so perhaps I give Go a harder time than I should for my failings
and not its. :)

On (4) I hope they get it right; packaging can definitely make-or-break the
system.

On (3) and (5) I found these techniques could/did-not work when testing Go App
Engine. Editing the third party source had no impact, even after restarting
App Engine, re-running tests, and deleting the .a files. I'm sure it's just
another trick, but I couldn't find it so I eventually just gave up ... hence
it being in my list of concerns.

Thanks for the feedback, I appreciate the suggestions.

Cheers

------
pori
Seen a lot of Erlang mentions in this thread. Is that the native alternative
to Go?

Personally, I prefer to write code in a functional manner. While I've always
thought Go looked like an amazing platform for programming in general, I
haven't been keen on moving to another imperative language.

It seems the landscape for functional alternatives are mainly Scala and
Clojure which are both based on the JVM and require a bit of time to learn the
tooling. I am not a Java or JVM export, so I haven't been too inspired by this
either.

~~~
cies
> It seems the landscape for functional alternatives are mainly Scala and
> Clojure

Cannot talk about functional alternatives without mentioning Haskell. OCaml
(when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often
abstain from the "O" in Scala) is also an interesting option.

Finally there's Rust, which is besides being a bit more functional also more
low-level than Go.

While being fairly young, Frege[1] also deserves a mention. Very similar to
Haskell, but on the JVM.

1: [https://github.com/Frege/frege](https://github.com/Frege/frege)

~~~
pori
Well, I was tempted to mention Haskell. Problem is, I haven't found a
practical use for it. Of all the FP languages, this is actually the one I am
most tempted by.

I had forgotten about Rust. Are there major projects being used for this yet?
I've heard it's picking up quite a bit.

~~~
codygman
> Well, I was tempted to mention Haskell. Problem is, I haven't found a
> practical use for it.

That's the same as saying:

Well, I was tempted to mention Go. Problem is, I haven't found a practical use
for it.

That is to say, just pick a problem and try to use Haskell to solve it. 90%
chance it will fit your niche fine.

------
helper
Rebuilding our integration docker image right now. If all our tests pass I
expect to have go 1.6 binaries in production by this evening.

------
CSDude
I would just love some IDE-debug love and better packaging. More packages I
use and more I distribute my files, compilation takes considerably longer.
Maybe I do not know, but is there some process to compile some parts before
hand and link only the changed resulting binary?

------
jay_kyburz
Can anybody tell me if you can run Go in Chrome using the NaCL stuff? I
remember there was talking of it a few years ago but I don't know if anything
ever came of it.

A google seach show that you could build for NaCal in Go 1.3 but only run it
in special builds not Chrome itself.

~~~
iso-8859-1
As you can see on
[https://github.com/golang/go/wiki/NativeClient](https://github.com/golang/go/wiki/NativeClient)
, there is no PNaCl support, which means it is only available in the Chrome
Web Store.

~~~
jay_kyburz
Thanks for the heads up.

------
robbles
There was some discussion leading up to the release about whether to merge the
"SSA" branch, which seems to be a refactor that allows for easier compile time
optimisations but also slows compile times for the time being.

Does anyone know if that was included in this release?

~~~
zenlikethat
IIRC from the e-mail thread, the idea being discussed was to potentially merge
the SSA branch immediately after the release (in order to have as much time as
possible to test it), so I'd be surprised to find it in this release. There
were concerns about the compiler slowdown but I didn't see the end result of
the thread.

------
rphlx
> Source trees that contain a directory named “vendor” that is not used in
> accordance with the new feature will require changes to avoid broken builds

That seems a little bit distasteful.

------
kiril-me
Do you know any framework using http2 on go lang?

------
enneff
Binaries are up but not everything is fully updated yet. Announcement blog
post coming shortly.

Edit: Blog post up:
[https://blog.golang.org/go1.6](https://blog.golang.org/go1.6) maybe change
the article link to that?

~~~
dang
Ok, we changed from
[https://golang.org/dl/#go1.6](https://golang.org/dl/#go1.6) to that.

------
andreamichi
A draft for the 1.6 release notes:
[https://tip.golang.org/doc/go1.6](https://tip.golang.org/doc/go1.6)

------
obelisk_
Release notes: [https://golang.org/doc/go1.6](https://golang.org/doc/go1.6)

Mods, maybe change OP link to this?

~~~
enneff
This is the better link target:
[https://blog.golang.org/go1.6](https://blog.golang.org/go1.6)

------
fuddle
Go is great, but I wish they would add terany operator support.

~~~
oofabz
They won't. The Go authors value simplicity. Many people dislike ternary
syntax and find it hard to read. Go errs on the side of verbosity and
readability. It is sort of the opposite of Perl in that respect.

~~~
fuddle
Which is more simple, an if/else block or a terany operator?

if/else:

if i == 0 {

    
    
       return "foo"

} else {

    
    
       return "bar"

}

terany:

return i == 0 ? "foo" : "bar"

