
Go 1.11 and Beyond - ngaut
https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQajZ2Hcoh29tm_LQCpgfrCnuRk/edit#slide=id.g33148270ac_0_143
======
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](https://changelog.com/gotime/77#transcript-60)

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

~~~
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...](https://en.wikipedia.org/wiki/Copernican_Revolution#/media/File:Apparent_retrograde_motion.gif)

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

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

~~~
zdw
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/](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.

------
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](https://godoc.org/github.com/google/go-github/github)

[2]
[https://hexdocs.pm/phoenix/overview.html](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.

~~~
013a
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.

~~~
weberc2
Ah, I see. I guess I think of these UX improvements as “the last mile”, and
it’s nice to have something that gets us 95% of the way there compared to
everything else that makes you work to get to 40%.

Also, i’ve never found Rust’s docs to be very easy to read; maybe the
complexity of the type system makes for a more challenging UX, or maybe my
opinion is simply an outlier.

In any case, it’s good to know things can get even better. Thanks for sharing!

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

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

~~~
cageface
One big problem with macros is that they make it very difficult to build good
tools. You can't really understand the meaning of any particular piece of
syntax without completely evaluating any macros that might be in use.

~~~
Groxx
That sounds exactly like what a compiler has to do. And what all type-aware Go
tools currently have to do. So we're already doing that, we just have no
language-level support for doing so, so we have _incredibly_ less-capable
workarounds like makefiles and go:generate.

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

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

~~~
pebers
That's kind of my point; the code might not be as beautiful as we could ever
imagine, but as a product it works extremely well, and would be worse if it
carried around a lot of runtime baggage and poor performance which many of the
alternatives would have given.

~~~
jacques_chester
This is not about beauty. It is about reliability, simplicity and safety, all
of which contribute to development velocity.

Golang is simple only for toy examples.

At scale Golang codebases are difficult to navigate, understand and test due
to the repetitive repetition of repetitious repeats.

And the idea that at-the-time-viable alternative languages like Java, C++ or D
are too slow for something as relatively lightly trafficked as the core
Kubernetes controller codebase is just plain silly.

~~~
pebers
When I mentioned speed, I obviously wasn't ruling out C++ on that basis - but
I would rule out Python or Node. Java is fast enough when going but the
awkwardness of needing a JVM plus abysmal runtime memory usage make it pretty
unattractive to me, especially for the k8s agents where the resource needs
have to be subtracted from total node size.

I've not found Go difficult to navigate because of repetition. Quite the
reverse really - it's easy to reason about where everything comes from and
(usually) easy to work out how everything connects together. I would take that
any day over a large Java codebase with the usual obfuscations of dependency
injection, or a Python or C++ codebase where somebody has tried to be
"clever".

~~~
jacques_chester
You are focused on good Golang vs bad Java.

People have also written bad Golang and good Java.

The difference for me is: given the choice between good Java and good Golang,
I'd take Java. I don't have acres of stuff _in my damn way_.

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

