Go 1.6 is Released

> JVM configuration

This is the mother of all premature optimization. Other than maybe modifying heap size or setting client vs. server, most of the default JVM configurations work for almost everything.

> build system configuration

I actually find maven pretty easy to use, but maybe it's just that I am used to it.

> IDE configuration

I don't know what crazy IDE you are using, but both Intellij and Netbeans need very little, if any, configuration out of the box.

> [Java] community goes off on some crusade

As opposed to everyone else? /s

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

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

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

What are you using generated code with lots of types for out of interest? I haven't felt the need as yet but would like to try it out.

Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http handlers.

The other thing to bear in mind is that if you try to make things all implicit rather than explicit in order to avoid repetition, it's very easy to be unaware of what's happening behind the scenes (auto-auth, or auto-render as in rails), and get stuck when you want to do something off the beaten path. I rather like Go's more verbose but very explicit style. It's a trade-off.

Auth, CSRF, parameter parsing should definitely be in a separate pkg you're using, not repeated each time IMO, so there should be minimal boilerplate for those.

Using text template is a really nice way to generate http handlers if you typically set up resources in a similar way, so I'd definitely recommend trying that out. I haven't looked into go generate as that came out after I started this approach.

The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic, then render, and then edit those as necessary, as often as an app grows each action diverges from the standard (say it doesn't do auth, or processes parameters differently etc). This is easy, explicit, and very clear when returning to code after 6 months at the cost of some verbosity.

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.