
What else is in Go 1.11? - ngaut
https://talks.godoc.org/github.com/mvdan/talks/2018/go1.11.slide#1
======
vesak
Go is missing 2 things that I care about:

1) proper dependencies management system (the new module system might address
this) and

2) gener... nah, just kidding -- actually null protection. I don't want to see
another segfault or null pointer failure ever again.

If it had these two features, I'd probably stop toying around with Rust and
Crystal and just use Go. Unfortunately, 2) is probably impossible without
seriously breaking old code, and they're not gonna break old code.

~~~
yawn
Totally agree on 2. "Learn a language a year" they said. "Learning new
languages expands your thinking" they said. What they didn't say was that once
you use ADTs to model data, Maybe/Option types to avoid null, exhaustive
pattern matching, etc, you want those features in all the languages you use.

I don't ask for much. I just want a GC'd Rust (one of the few modern languages
that has option types in the std lib) or an F# that isn't tied to the .NET
standard lib. Please?

~~~
masklinn
> F# that isn't tied to the .NET standard lib. Please?

F# is basically OCaml on .Net, so… OCaml?

~~~
mlevental
I just made this choice (learn fsharp or oval). initially I was leaning ocaml
for the same reason as gp but then I tried a simple scraper (make a get
request and parse the HTML) and couldn't get it to compile because of cabal
hell. well obviously not cabal hell but dependency hell where I had to keep
changing installing and uninstalling versions of cohttp and the compiler. in
the end I said screw it and installed all the .net/mono/f# stuff and it worked
flawlessly the first time. I don't understand how language developers don't
prioritize package management in 2018 - it's simply a deal breaker when other
languages get it right. yes I realize ocaml and haksell have a different
perspective on dependency resolution than other languages but then they should
ensure that it works (and yes I also realize dependency resolution is np
complete).

~~~
xfer
It can happen if you happen to install a recent compiler and that package
manager has not done the work(probably changing the bounds) to update in opam
repo.

> I don't understand how language developers don't prioritize package
> management in 2018

As you already know, Ocaml already has a decent package manager opam, this
same situation will happen in any language where the packages get stale(e.g.
in rust you installed something used nightly features that didn't make it
mainstream).

------
ancarda
>Last release where _godoc_ has a command-line interface

What? Are they removing “godoc <pkg>”? I used that a lot as a man page. It’s
especially useful when you don’t have internet access

Edit: it’ll still be available in `go doc`, just that `godoc` will only be a
web server.
[https://tip.golang.org/doc/go1.11#godoc](https://tip.golang.org/doc/go1.11#godoc)

------
mappu
Plaintext at
[https://github.com/mvdan/talks/blob/master/2018/go1.11.slide](https://github.com/mvdan/talks/blob/master/2018/go1.11.slide)
if anyone else gets Chrome freezing for a few seconds navigating left/right.

~~~
Insanity
Thanks! I am on my phone and it is impossible to read it.

------
trulyrandom
Is there a good way to view these Go presentations on mobile? I find them
almost impossible to navigate on my smartphone.

~~~
nostalgeek
Yes it's bad UX on mobile, here you go:

[https://raw.githubusercontent.com/mvdan/talks/master/2018/go...](https://raw.githubusercontent.com/mvdan/talks/master/2018/go1.11.slide)

------
kodablah
A change to gofmt like that is going to require a large formatting commit to
conform. Presumably/ideally there are CIs that fail on invalid format, so it's
not like you can wait until you touch the file again. Not a big deal, but
still worth noting.

~~~
mappu
There was a change to gofmt in 1.10, too:
[https://golang.org/doc/go1.10#gofmt](https://golang.org/doc/go1.10#gofmt)

"""Note that these kinds of minor updates to gofmt are expected from time to
time. In general, we recommend against building systems that check that source
code matches the output of a specific version of gofmt. For example, a
continuous integration test that fails if any code already checked into a
repository is not “properly formatted” is inherently fragile and not
recommended."""

~~~
kodablah
> For example, a continuous integration test that fails if any code already
> checked into a repository is not “properly formatted” is inherently fragile
> and not recommended.

As a frequent repo/commit spelunker, I'm gonna have to disagree here. It is
better to have this changed all in one commit instead of tacking on that
formatting change along with an unrelated change elsewhere in the file and
doing that all over the place at separate times. What's inherently fragile
(formatting wise) is making a change to a file that does not meet the current
formatting requirements and then having it format on save/commit, messing up
blames, code review diffs, etc.

~~~
iainmerrick
Yep -- formatting for style is great iff it’s done rigorously and consistently
on every commit (which is what a presubmit check is good for). Ad-hoc
reformatting mingled in with real changes plays havoc with change tracking.

Ideally the format would never change at all. An occasional change-the-world
update is a reasonable compromise, but it should be done as a single commit
with no logic changes.

------
wawhal
Finally, I can keep my Go projects wherever I want.

~~~
geezerjay
I missed any reference to GOPATH. Does this release fixes Go's problem of
forcing developers to specify source code directories through GOPATH?

~~~
agnivade
That is correct. Now you can clone and build Go repos anywhere.

Note that support is still experimental, so if you want stability, it is
advised to remain inside GOPATH for another release. This is a good post -
[https://systemdump.io/posts/2018-07-22-go-
modules](https://systemdump.io/posts/2018-07-22-go-modules)

However, do please feel free to try it out and file bugs.

~~~
geezerjay
The GOPATH nonsense was the reason why I've decided to take a hard pass on
Golang, and instead pick up Rust. I'll stay away fron Golang until that
braindead idea is officially dead and a thing of the past.

------
Animats
The "prove pass" is a nice step forward. As that is improved, more subscript
checks will be optimized out.

------
iainmerrick
Huh, a change to spacing in gofmt? Won’t that cause extra source control churn
in a lot of projects?

~~~
cyphar
It actually could cause bigger problems than that. Most Go projects I've seen
have CI runs that check whether 'gofmt' complains -- and fail builds if they
do.

Ultimately though I don't really care all that much. Everyone will fix it in a
few commands, and everything will be green again.

~~~
iainmerrick
I care if it makes it harder to browse version history and see which changes
were made when, and why.

~~~
cyphar
I don't think it would make it much harder if people just do all of the
'gofmt' changes in a single commit. After all, it's not like your entire
codebase consists of such edge-cases, and if you hit a 'git blame' where the
commit is a format change you can always just do 'git blame
$THE_FORMATTING_REVISION^ $file'.

I have to do this all the time when 'git blame -wM' doesn't give me what I
want when looking at kernel changes.

------
mvdan
If anyone wants the recording, this is the timestamp in the meetup recording
before an edited version is available:
[https://youtu.be/RGeHsqj2RWo?t=2h16m11s](https://youtu.be/RGeHsqj2RWo?t=2h16m11s)

I can see that the slides alone aren't self-explanatory in some points, for
example with the random byte reading or gofmt. I'll make sure to link to the
issues/CLs in the slides next time :)

------
gok
> Kernel calls on macOS and iOS now go through libSystem.so

Well it’s called libSystem.dylib :) but, still, good. It looks like this was
only done in “runtime” but hopefully the rest can come in 1.12. [1]

[1]
[https://github.com/golang/go/issues/17490](https://github.com/golang/go/issues/17490)

------
fenollp
> Some crypto funcs now randomly read an extra byte

Can someone explain how this is a feature?

~~~
kibibu
It's to stop people misusing the crypto APIs, or making assumptions about them
that the Go maintainers don't want to be stuck supporting.

[https://go-review.googlesource.com/c/go/+/64451](https://go-
review.googlesource.com/c/go/+/64451)

> Code has ended up depending on things like RSA's key generation being
> deterministic given a fixed random Reader. This was never guaranteed and
> would prevent us from ever changing anything about it.

~~~
rauhl
I respect agl a _lot_ , but this really doesn’t make sense to me. Should I be
able to rely on the RSA keygen being deterministic between versions, given a
fixed random Reader? No. But should I be able to rely on it being
deterministic between runs with the same version? IMHO, yes. This changes the
signature of key generation from (Reader) to (Reader, internal random).

------
eadmund
> Last release to support GOCACHE=off

That's a bit disturbing, since Go's test caching can be a bit of a nuisance. I
did some quick Googling, but couldn't find an explanation.

~~~
komuW
If you want to disable test caching, you can still do; go test -count 1

if you want to rebuild without cache; go clean -cache && go build

------
thoeni
Here’s a video of the talk by Daniel where you can see these slides explained:
[https://youtu.be/mQYjjVCGVJ8](https://youtu.be/mQYjjVCGVJ8)

