Go 1.11 and Beyond

[howeyc]

Very interesting ideas in there. Especially the thought of an upcoming Go 2 perhaps being done in such a compatible way that "Go 2" is actually "Go 1.1X"

He also hints that it would likely only be done to address major issues/concerns/changes such as:

* generics

* modules (perhaps done? time will tell)

* errors (if err != nil {}, extra type information, chaining, etc)

* context

Still to early to tell if anything I listed or he listed would be part of "Go 2" or whatever it happens to be called.

[mseepgood]

> Very interesting ideas in there. Especially the thought of an upcoming Go 2 perhaps being done in such a compatible way that "Go 2" is actually "Go 1.1X"

Go project lead Russ Cox already talked about that on an episode of the Go Time podcast. Transcript: https://changelog.com/gotime/77#transcript-60

[fredch]

Don't people just write helper functions to deal with the error checking spam? It's five lines at the top of the file...

Anyway, I will miss our GOPATH overlords. I have enough decisions to make, I'm fine with the language making some for me.

[coldtea]

Stability is good is what's stable meets your needs.

The more they stall adding stuff like generics the more painful (and more work for the tools and ecosystem to catch up) will be when they eventually cave in and do it...

And there will always be all the workarounds, third party solutions, and wasted efforts that would could have been avoided if something that could have been delivered early on (like e.g. package management) didn't come a decade late for no good reason.

At least now they've come up with a module/dependency system, which, even though a decade late, doesn't bring anything extraordinary to the table compared to what other platforms already had for ages.

Generics and error management remain before it makes sense to make it stable and boring for eternity...

[dilatedmind]

When I think of generics i think custom data structures. Currently you are stuck with interfaces, but you can also wrap a library returning interfaces with methods operating on a specific type.

I would be interested to hear about use cases that couldn't be solved in this manner

[mseepgood]

> At least now they've come up with a module/dependency system, which, even though a decade late, doesn't bring anything extraordinary to the table compared to what other platforms already had for ages.

I don't think you fully grasp the breakthrough that the theory behind Go modules is for dependency management in general. It vastly improves on and simplifies anything that existed in this domain before.

It's like saying Copernican heliocentrism didn't bring anything extraordinary to the table compared to Ptolemaic geocentrism. https://en.wikipedia.org/wiki/Copernican_Revolution#/media/F...

[ptx]

For all the emphasis they put on stability, there is one part that doesn't seem particularly stable – on slide 32:

"Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4."

This is, I assume, because Go makes direct syscalls rather than going through the C library. Many operating systems, including Windows, don't consider that a stable public interface.

So does this mean that older Go binaries will stop working when you upgrade the OS? I guess that would make the source compatibility extra important to them, since you must keep recompiling your old programs as you upgrade to newer a OS. (Perhaps it's also why they're dropping support for older OS versions so quickly?)

[LukeShu]

OpenBSD doesn't make any promises about ABI stability between releases. That means that all older binaries may stop working when you upgrade the OS, not just older Go binaries.

[giovannibajo1]

This is not related to syscall vs libc. OpenBSD 6.4 requires stacks to be mapped with MAP_STACK, so it requires a runtime change. I’m not sure how using libc would have prevented this

Ref: https://github.com/golang/go/issues/26142

[AnIdiotOnTheNet]

> Many operating systems, including Windows, don't consider that a stable public interface.

Windows in no way requires libc. You're right that it does require you to call their public interface dlls, but they're pretty ridiculously stable.

[013a]

One really minor, but powerful, thing I'd love to see from the Go team is a better designed documentation experience. Here's the Google-produced Github library godoc [1]; its absolutely horrendous to browse, as is any sufficiently large package. Compare that to Elixir's [2] auto-generated documentation. There's a lot of work that can go into just improving that static HTML and making it more easily grokable.

[1] https://godoc.org/github.com/google/go-github/github

[2] https://hexdocs.pm/phoenix/overview.html

[weberc2]

I've not used Elixir, but I'm surprised by the strong dislike for GoDoc. I've used Java, C#, C/C++, Python, and JavaScript and I've never found anything to be as nice as GoDoc.

In particular, Godoc is absolutely effortless. No build step in your project, no cryptic documentation syntax, no need to tell the documentation generator how to link to your dependencies' documentation pages, etc. Everything just works, and the output is quite a lot cleaner than the aforementioned as well.

No doubt there's a little room for improvement in how the text is layed out and organized, but it's still leagues better than all other documentation systems I've used. With Python (sphinxdocs) in particular, everything gets rendered into a giant page with no clues about what class's `__str__()` method I'm currently looking at.

[shazow]

Godoc is an excellent forcing function when it's not ignored. Designing your package's public namespace so that it looks sensible in godoc yields great results for consumers.

[urtrs]

I prefer godoc. It is concise and I can find faster what I am looking for.

[the_duke]

I really prefer the Rust auto-generated documentation to both Godoc and Elixir docs.

See for example https://docs.rs/diesel/1.2.2/diesel/pg/index.html.

Godoc is too plain and almost cumbersome to read for me, while Elixir is too pretty and not so efficient in displaying the type information in my opinion.

Rust has a happy middle ground here.

[thefounder]

Godoc compensate by being more functional. The elixir example is missing links to the source code of the functions/methods etc. Godoc also generates an excerpt with all the functions/methods/types in the package.

[agnivade]

Hi,

godoc maintainer here. We have a lot of UI improvements coming for 1.12.

- A TOC at the top

- A sidebar for easy scrolling

- More cross-links for easy navigation.

If hotlinking comes through, that's a major improvement in itself.

Stay tuned !

[ainar-g]

It will be very interesting to see, what will using Go 2 generic code from Go 1 code look like.

[whatpad]

> It's quite likely that "Go 2" == Go 1.15 or 1.16

That is Aug 2020 or Feb 2021 for generics.

[pietroglyph]

They also hint to this in the slide 75 where they say "10 years is good".

[golergka]

Does it have generics yet?

[brianolson]

One feature that could achieve generics, eliminated `if err != nill{}` stutter, and allow for backwards compatibility: macros

(borrowing the '@' prefix for macros from Julia)

type ConcreteStruct @macroType(int64)

val := @errReturner(file.Write(data))

and backwards compatibility is allowed by running the go2 compiler in macro-expansion-only mode that creates macro expanded Go1 compatible source.

[mseepgood]

Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore".

[kevhito]

My preferred solution for the err handling stutter would be something like "whenever".

func Foo(x int) (int, error) { var err error a, err := whatever() if err != nil { return 0, err } b, err := whatever() if err != nil { return 0, err } ... }

becomes

func Foo(x int) (int, error) { var err error whenever err != nil { return 0, err } a, err := whatever() b, err := whatever() ... }

Essentially, "whenever" just means "insert this line at every point in the remainder of this code block where err is assigned a new value.

It is explicit, simple, easy to understand, and would be identical in function to how most errors are currently handled.

[kodablah]

At this point, Go would just see macros as automatically called code generation, which leads to an unpredictable speed reduction in compile times especially with large dependency trees. Slowing down compile times at any noticeable level is probably a non-starter based on language goals.

[maxpert]

I still don't get it; so you invented a language based on idea of not doing the "evil" things C++ or say other languages did and now you have to re-invent all those "evil" things because community wants it?

[pebers]

It isn't necessarily a bad idea to start with a minimal design and add features later once the implementation is more mature. Even if Go never gets generics, it's still a good solution for a number of problem domains (for example, it seems to have found something of a niche for infrastructure; Kubernetes, Prometheus, juju, etc.)

[coldtea]

No, they re-invent all those "evil" things it's wrong that they're evil, and modern software development needs them.

The problems C++ has have nothing to do with those things anyway.

Haskell has both generics and great error management, and it's not C++. Ditto for OcamL and any number of languages...

[dixie_land]

so coming back full cycle to realize they should've hired actual programmers that writes C++ so they don't have to invent a new language to babysit them