Go 1.11 and Beyond

https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQajZ2Hcoh29tm_LQCpgfrCnuRk/edit#slide=id.g33148270ac_0_143

by ngaut • 8 years ago

182 79 8 years ago

docs.google.com

ainar-g2• 8 years ago

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

howeyc• 8 years ago

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.

mseepgood4• 8 years ago

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• 8 years ago

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.

brianolson• 8 years ago

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.

mseepgood4• 8 years ago

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

thibran• 8 years ago

No, they solve a complex problem.

Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible.

Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.

coldtea6• 8 years ago

Well, they sort of give the same message already, but with custom code-level solutions instead of macros...

"Everybody go an invent your own way to handle error checking/propagation" etc...

nostalgeek• 8 years ago

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

I prefer safe AST based macro than runtime reflection like Go has. The latter is actually a cop-out, unlike the former in the context of type safety at compile time.

pjmlp7• 8 years ago

Instead one gets to use go generate for the same purpose.

kodablah• 8 years ago

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.

kevhito• 8 years ago

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.

LukeShu3• 8 years ago

Indent your code with 4 spaces to prevent HN from eating the newlines:

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


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

golergka• 8 years ago

Does it have generics yet?

whatpad• 8 years ago

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

That is Aug 2020 or Feb 2021 for generics.

pietroglyph• 8 years ago

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

dixie_land• 8 years ago

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

maxpert• 8 years ago

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?

pebers3• 8 years ago

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

jacques_chester3• 8 years ago

Kubernetes has enormous masses of repetitive code that is essentially a workaround for the absence of generics or other kinds of improved types. The reliance on "union types" -- really, exclusive arcs -- gives me the heebies and also guarantees that there is a bottleneck for new features: PRs to core. And then there's the whole TypeMeta thing. An entire dynamic type system because Golang can't express what Kubernetes needs.

And no, I don't see code generation as a good thing. It's fragile and difficult to safely upgrade.

coldtea6• 8 years ago

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

ptx• 8 years ago

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

LukeShu3• 8 years ago

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.

zdw• 8 years ago

This might be seen as a problem, but it allows the OpenBSD devs to push the envelope of expectations and find bugs across the entire software ecosystem.

An example of this was the change to 64-bit time_t back in 2013 (talk: https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ ), and evolving syscalls like pledge(2) that changed syntax between releases as the problems/benefits of a specific implementation choices were learned.

AnIdiotOnTheNet• 8 years ago

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.

LukeShu3• 8 years ago

Windows calls their syscall wrapper ntdll.dll, not libc.so; but it's conceptually the same thing. The ntdll.dll ABI is public & stable, the underlying syscall ABI isn't. Several unixoids do the same thing, where their libc.so ABI is public & stable, but the underlying syscall ABI isn't.

giovannibajo1• 8 years ago

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

013a2• 8 years ago

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

urtrs• 8 years ago

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

shazow• 8 years ago

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.

thefounder• 8 years ago

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.

q1t• 8 years ago

ExDoc does not miss links to the source code. (Click on any Module/function and there should be brackets "<>" that point to the source code.) Types are also present in any module that defines them.

weberc23• 8 years ago

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.

013a2• 8 years ago

That's mostly what I mean. I love godoc and the philosophy behind it; its a massive improvement over the manual documentation build steps of Java, JS, Python, etc. But even more modern languages, like Rust and Elixir, do it better. There's a lot of low-hanging UX and usability fruit to be fixed in godoc which can make the experience better.

the_duke• 8 years ago

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.

ainar-g2• 8 years ago

It's funny how these things are so personal. I love Godoc, mostly because everything is on one page, with very little JS and a good, almost monochrome colour palette. At the same time, I really can't stand Rust's docs, because everything seems to get its own page, it's colours galore, and of course there is a sidebar.

The mileage does vary greatly apparently.

agnivade• 8 years ago

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 !

coldtea6• 8 years ago

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

dilatedmind3• 8 years ago

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

tree_of_item• 8 years ago

"Solved" by having lots of meaningless unsafe glue code. That's not a solution.

It sounds like you're going to reject proposals for generics on the grounds that "you could just cast values of type `interface{}`" unless someone can show you a situation where you can't do that. The problem is that the people who want this sort of feature don't think that's even a solution.

mseepgood4• 8 years ago

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

ghthor• 8 years ago

It really does. Our codebase is very large and I'm a member of the team responsible for the build system and language tooling. Java library resolving in our repo can take 45mins from a clean build. Python is better, and we've managed to lock it down to offline only sources so libraries never update on us out of the blue. I've been a gopher since the the first announcement and I'm so excited that Russ Cox discovered a simple way to declare and resolve dependencies that avoids the SMT solver nightmare that I've seen bog down progress in every major project I've been involved in, from Ocaml and Haskell to python, java, rust and javascript (security nightmares every night here).

One of my greatest hopes is I can convince my teammates that its be worth the time investment to transition all our dependencies management ecosystems into the Minimum Version Selection algorithm.

unethical_ban• 8 years ago

What am I missing? It's a dependency declaration file.

etaoins• 8 years ago

It’s a slightly simplified version of Cargo which itself is an evolution of what yarn/npm/sbt/etc are doing. This is explicitly called out in the vgo paper.

It only seems like a revolution because the previous situation in Go was such a mess. As someone that writes a lot of both Rust and Go I’m not nearly as impressed.

coldtea6• 8 years ago

It vastly improves on and simplifies anything that existed in this domain before.

I've read the specs and justification posts. I don't find it gives anything better (and in some ways it's worse) than what can be achieved with, e.g. cargo.

It's like saying Copernican heliocentrism didn't bring anything extraordinary to the table compared to Ptolemaic geocentrism

Yeah, it's like saying that, with the only difference that we're actually talking about something that brought nothing extraordinary here (as opposed in the contrived example).

Go 1.11 and Beyond

Related Stories