
Go 1.13 Release Notes - 0xmohit
https://golang.org/doc/go1.13
======
mfer
I started poking around and noticed that Go 1.13 now defaults to the Golang
Proxy to fetch modules. This means a proxy, governed by the Google Privacy
Policy, is now capturing everyone's module usage by default. Unless you change
settings this includes proprietary/corp stuff.

[https://codeengineered.com/blog/2019/go-mod-proxy-
psa/](https://codeengineered.com/blog/2019/go-mod-proxy-psa/)

~~~
FiloSottile
The Modules Mirror and the Checksum Database are governed by this specific
privacy policy:
[https://proxy.golang.org/privacy](https://proxy.golang.org/privacy)

"go env -w GOPRIVATE=*.corp.example.com" was added to make it as easy as
possible to configure private modules. If the environment is not set up, just
the name of the module will reach the Google services, it will not be
published, and an error will be returned.

Anything else would have make it possible to bypass the protections of the new
Checksum Database
([https://golang.org/design/25530-sumdb](https://golang.org/design/25530-sumdb)),
a state-of-the-art authentication system that provides auditable proof that
the operator is behaving honestly.

For an example of why the Mirror is valuable, beyond the 10x performance gains
(depending on number of dependencies and connection latency) and security
gains from not using git on the client, look no further than git.apache.org,
which has been down for days breaking a number of builds
([https://status.apache.org/incidents/63030p4241xj](https://status.apache.org/incidents/63030p4241xj)).

I really think this architecture brings together the best of the decentralized
module ecosystem that Go had (with its lack of regularly compromised registry
accounts, and no mismatch between code and package origin) and the centralized
registries of other languages (with their better performance and reliability).

Particularly proud of how the Checksum Database provides even more security
than the centralized registries (because it's cryptographically accountable
for its actions, while registries can sign anything they want) without
requiring authors to manage keys, register an account, or change their
workflow at all.

[Note that I work on the Go team, and co-designed the Checksum Database. But
of course I don't speak for the company.]

EDIT to add: I should also mention that the sumdb allows the use of any
untrusted proxy, easily configured with "go env -w GOPROXY", for users that
can't or don't want to use the Google provided one. The proxy can also opt-in
to mirroring the Checksum Database, in which case no user requests at all need
to reach the Google services, while still providing all the integrity
guarantees that proxy.golang.org users benefit from.

~~~
rgbrenner
First programming language that I've had to read and understand a privacy
policy to use.. and consider that it may change in the future.

The idea that the language I'm programming in now reports anything back to
google is distressing.. and I say that as someone who has been programming in
Go for about 7 years. What right does google have to collect usage information
from modules hosted on github (or elsewhere)?

I checkout the code for the modules, review it, and commit it into my own
repository. I don't need you to speed up the rare git checkout of a module.
Not that I think some minor speed improvement is worth my privacy.

You talk about decentralization... while centralizing the entire thing around
Google. You talk about git.apache.org being down, while you're willing to
bring down the entire ecosystem across the board with your own special server.

This "feature" should have an option to disable it.. at the very least.

This is the first language in my 23 years programming that reports my usage
back to the language authors. It's unprecedented. And the truth is, if this is
ok to you, then there's really no limit what the code I write today, may
report back to google tomorrow.

~~~
TheDong
> This is the first language in my 23 years programming that reports my usage
> back to the language authors

I suppose that means you haven't used any of:

1\. nodejs, which reports your usage back to npm Inc with the exact same
amount of detail (names of dependencies, ip of caller) (and stores much more,
since it publishes 'downloads per month', etc)

2\. rust, which does the same with crates.io

3\. perl, which does that with cpan

4\. python, which does that with pypi

5\. ... etc

All of those languages have a central registry of packages that has the same
level of detail in the metadata it can potentially collect as the go proxy
does.

> This "feature" should have an option to disable it.. at the very least.

It does. Multiple options. You can run your own proxy, disable it entirely, or
opt out of the go mod experiment and never run go get, but rather vendor by
hand with `git clone` or whatever.

> And the truth is, if this is ok to you, then there's really no limit what
> the code I write today, may report back to google tomorrow.

Very much a slippery slope. They've communicated clearly how to disable it and
what it does, it's in-line with what other language ecosystems do in terms of
metadata reported to a central package repository, and I think it's very easy
for someone to be okay with this, but to not be okay with any step beyond this
line.

~~~
rgbrenner
If I download something from a server, of course that server knows what I
downloaded.

This is different. It’s a proxy in front of others repositories. They want
info on downloads from GitHub, gitlab, and anywhere else you get code from.

They (google) are a 3rd party to the download.

~~~
sudhirj
They're offering a cryptographically signed mirror - the first mainstream one
available. You can either run your own personal mirror, run one for your
company, or turn it off.

~~~
panpanna
> They're offering a cryptographically signed mirror - the first mainstream
> one available.

But why? Who asked for this??

------
donatj
Contrary to what someone else has said, this is my _least_ favorite release of
Go ever.

I'm salty about how the proxy, which is enabled by default, makes it so much
more difficult to pull private modules by having to set environment variables
on everyone's individual machines.

I've got an issue being discussed on GitHub about it
[https://github.com/golang/go/issues/33985](https://github.com/golang/go/issues/33985)

~~~
tapirl
go env -w GOPROXY=direct

go env -w GOSUMDB=off

~~~
panpanna
This should be off by default and enabled manually for people who need it.

------
tptacek
Honestly, and I don't think I'm snarking (but would have to reflect a bit on
it), "0b", "_", and signed shifts are probably going to make Go more pleasant
for me than generics would have. This is my favorite release in years.

~~~
skunkworker
It brought one of my favorite parts about writing numbers in languages such as
Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement
and should be no-cost.

~~~
mseepgood
> From 10000000 to 10_000_000 is such a readability improvement and should be
> no-cost.

1e7

~~~
masklinn
> 1e7

Is a float literal.

~~~
majewsky
Not in Go. Number literals don't have a type until they're assigned to a
variable or used in a place that implies a type (e.g. a function argument).
For example, the following is valid:

    
    
      var u uint32 = 10000000000.0 / 100000
    

even though 10000000000 overflows uint32 and it's also written like a
floating-point literal.

~~~
masklinn
> Not in Go.

Yes in go. `var u = 1e7` gives a float. That means 1e7 is a float literal. You
_can_ coerce it to an integer by explicitly typing the target, but it's still
a float literal.

~~~
yencabulator
`1e7` is an untyped numeric constant with a default type of float64.

[https://blog.golang.org/constants](https://blog.golang.org/constants)

[https://golang.org/ref/spec#Constants](https://golang.org/ref/spec#Constants)

------
gameswithgo
I like the way Go proceeds as a language, with features added very very slowly
and the compiler and tools regularly improving. I hope Rust can settle down
into a similar focus soon.

~~~
rolleiflex
I think Go is the only software release at this point to whose releases I
respond with ‘Ooh shiny’ and not ‘Oh god’. I _love_ the way they’re doing this
— calm, collected, slow, and with ample heads up.

At this point, I think we all have some JavaScript PTSD.

~~~
seabrookmx
C# obviously has a very different design philosophy than Go, but its releases
are moving along at a similar (and IMO, reasonable) pace.

------
DuskStar
> The GO111MODULE environment variable continues to default to auto, but the
> auto setting now activates the module-aware mode of the go command whenever
> the current working directory contains, or is below a directory containing,
> a go.mod file — even if the current directory is within GOPATH/src. This
> change simplifies the migration of existing code within GOPATH/src and the
> ongoing maintenance of module-aware packages alongside non-module-aware
> importers.

Oh wonderful! This makes switching back and forth between module projects and
'legacy' projects far easier. (Well, at least for me - since I tend to keep
all cloned git repos inside the GOPATH. I don't have a problem, really!)

------
cameronbrown
I occasionally use Python for large-scale processing of structured data (XML,
JSON) and the data's really messy as you'd expect (malformed responses,
missing fields, normalisation, etc..). One of the things putting me off of Go
for these kinds of projects is it's much more verbose/harder to handle edge
cases - it feels like I'm less productive writing the program, but end up
building something much more stable than the Python equivalent.

I'm definitely going to see if Go is acceptable for my next project since I
really need the performance for my workload, and I've wanted to put this great
language to work in something that isn't a toy project.

~~~
axaxs
> is it's much more verbose/harder to handle edge cases - it feels like I'm
> less productive writing the program, but end up building something much more
> stable than the Python equivalent

This is exactly how I felt moving from a Python codebase to Go. But you
realize on the 100th or so Python stacktrace that it's worth the investment up
front, if not for type safety alone.

> I really need the performance for my workload

Careful with that assumption. A pure Go application will in many cases be more
performant than a pure Python one, but Python has a better C interop story. In
the particular cases of parsing XML and JSON, I'd wager Python is much faster,
actually.

~~~
tgv
> on the 100th or so Python stacktrace

Go's not perfect in this respect, either. I had your typical
map[string][]interface{}, because the data in the map was an array of records,
but different records in different cases, and made an error in an append(), so
ended up with nested arrays. That's correct according to the type definitions,
but unwanted. Generic could have helped here. So I think the language still
needs to grow a bit.

~~~
dx034
I tend to write custom parsers for jsoniter in this case so that I catch any
unexpected data types as early as possible.

------
zubspace
I actually just started to use go on windows just to check it out. First
impressions from a newbie:

\- Getting started with go and vscode is kinda bad right now. I installed go,
set up GOPATH, installed all kinds of extensions in vscode and then, somewhere
down the official tutorial I learn about GO111MODULES, go mod init, vendor
folders and the language server... I was completely confused and still am. I
removed all extensions except the main one from vscode and the language server
was crashing like crazy until I unset GOPATH. Works now, mostly. Intellisense
and code formatting seems to be still unstable now and then. But geez, that
first experience was horrible.

\- The syntax is very weird after writing too much C#. Sometimes I have the
feeling, that declarations are reversed just for the sake of it.

\- Why does go need := with the colon? I know it's a declaration, but I
haven't figured out the reason for the colon.. Seems weird..

\- I love gofmt and format-on-save. But it was not the default setting. Still
don't know if I should use another one.

\- I hate configuring vscode. After hearing only good things about it, the
configurations and keybindings are horrible and that I need an extension for
each and every small thing. Maybe I'm in the minority, but Visual Studio is
miles ahead in this regard, I think.

\- Fast compilation times are awesome. I love, that I can create a simple exe
without a framework dependency.

\- I can parse 2GB of simple JSON files in less than 20s. I'm awed.

\- I have no idea how to compile some modules like the sqlite one. Seems to
need gcc..? Do I have to fully switch to Mingw/WSL?

\- I was losing my mind when I saw my program giving different results on each
run... Until I found out about that randomized map iteration.. Funny.

\- Finding an item in a slice: Yeah, sometimes generics would be nice but
let's not start a holy war...

\- Need to get used to error handling.. It can get really verbose and those
scoping rules are strange.. I miss exceptions, but I can get used to the go
way.

\- I love that I can use the official docs locally: godoc -http=localhost:6060

\- I had to use google and stackoverflow more than I initially thought for a
'simple' language... But well, I guess that's normal?

Sorry for the rambling. I love the simplicity of the language and hope to get
into it more. But the initial experience is still, umm, not streamlined, it
seems? But I hope that's just temporary.

~~~
saisasidhar
> The syntax is very weird after writing too much C#. Sometimes I have the
> feeling, that declarations are reversed just for the sake of it.

Rob Pike explains the reasons behind Go's deceleration syntax in this blog
post: [https://blog.golang.org/gos-declaration-
syntax](https://blog.golang.org/gos-declaration-syntax)

~~~
zubspace
Wow, this is really mind-opening. Everything makes sense now. Thank you.

It's also funny, that they stuck to the * pointer notation which led to the
problem, where they could not tell apart a pointer from a multiplication, so
they put it to the left of the variable name. It's the small things...

But I guess * is just too convenient and ingrained.

------
sime2009
How does Go compare to Rust these days with respect to language maturity,
community size and general maturity/availability of libraries?

So far I've found Rust more interesting and pushes the envelope a bit more.
But what is the sales pitch for Go?

~~~
bborud
The way I view it is that Go is for people who write software while Rust is
for those who like to think about how to write software.

Perhaps I’m old and grumpy but I feel that at this point I’ve had every
language discussion before and if people start to moan about lack of
metaprogramming support I just leave.

I have yet to see a project that failed due to lack of high order abstractions

~~~
pjmlp
I have yet to see a project that failed due to being written in Assembly, yet
we moved on to better abstractions.

~~~
bborud
I’ve worked on two projects (in early x86 assembler) that ran out of steam
because they took too long to do and it was hard to onboard new developers.

I’ve also abandoned a few paths during projects because of libraries that were
overly abstract, didn’t work and were thus hard to understand and maintain.

A product at a company I used to work for had to reimplement a huge chunk of
code because the original designer left and the metaprogramming behemoth he
wrote was too hard to understand, extend and debug. That one chunk of code
cost about $500k and 6 months to replace. I’m unsure of the total cost of that
effort as it delayed the next release at a critical time.

Abstraction levels need to be appropriate. Enough to make things simple - not
so much that it makes life harder.

~~~
pjmlp
Like this?

[https://archive.fosdem.org/2019/schedule/event/kubernetesclu...](https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/)

~~~
bborud
I would have to look at this since I’m not familiar with the codebase, but
I’ll have a look. Thanks!

I’m not quite sure this is what I meant from the description of the problem.
This looks more like a problem of trying to program Java in Go. What I was
thinking of was more along the lines of modeling things in ways that either
disconnect you from the problem you are trying to solve or solve it with too
much abstract cruft grafted onto the model so just dealing with the
abstractions themselves becomes more work than a more direct and naive
approach.

------
nemo1618
Nice to see that out-of-bounds panics will now include the offending index.
Was that difficult to implement, or just controversial? Seems like something
that could have been added a long time ago and saved much frustration when
debugging.

~~~
typical182
I think the concern was that it would be too expensive, but then later they
were able to figure out a way to do it.

Some more details:
[https://github.com/golang/go/issues/30116](https://github.com/golang/go/issues/30116)

------
dahfizz
> Go programs are now compatible with Android 10.

That's pretty cool

------
sigjuice
So GOPROXY is like AMP for my Golang codebase?

Edit: :)

~~~
seabrookmx
Not sure if you were trying to be funny.. but I find this hilarious :P

------
omaranto
I haven't been keeping up with Go. Is it still the case that the only datatype
than can be used as keys to a map and is not of a fixed size is string?

~~~
nemo1618
Strings are fixed-size, though. A string is a pointer and a length.

It's true that you can't use a slice as a map key, though, even though slices
are also fixed-size (pointer, length, and capacity). As I recall, the argument
is that the equality rules for slices are unclear. (maps and funcs can't be
used as keys either, for the same reason: they're not comparable.) Is a
0-length slice equal to a nil slice? Is a slice with len 3, cap 3 equal to a
slice with len 3, cap 4?

In practice, this is rarely a problem. It most commonly comes up when you want
to use []byte as a key, in which case you can convert the []byte to a string.
This overhead of this conversion (specifically when it occurs in the context
of a map key) has been optimized away for a few versions now.

~~~
eptcyka
Would it be too hard to just compare arbitrary slices and arrays based on the
contents of said data structures? Converting arbitrary bytes to strings should
fail at least some times, since not all byte sequences are valid UTF-8, and
afaiu, in Go, the string type should always contain valid UTF-8.

~~~
nemo1618
Go strings do not need to contain valid UTF-8, although in practice they
usually do. A 'range' loop over a string will loop over its UTF-8 codepoints,
but in general, a string can contain arbitrary binary data. See
[https://golang.org/pkg/builtin/#string](https://golang.org/pkg/builtin/#string)

------
w8rbt
Awesome news. Go is C for the Cloud.

Can I trademark that? ;)

------
6ue7nNMEEbHcM
Is there some information about how to set-up your own proxy/checksum DB?

EDIT: I understand that there are environment variables you can set, but how
do I go about deploying my own proxy/checksum server? Is the source code
behind [https://sum.golang.org/](https://sum.golang.org/) published somewhere?

------
zadokshi
The documentation makes clear, if someone accidentally commits something they
shouldn't (i.e. a file containing your users personal details, credentials,
etc...) then it is stuck in their proxy forever. It is clear that google
employees believe we live in a perfect world where all employees never make
mistakes.

[https://proxy.golang.org](https://proxy.golang.org) :

> "...the mirror aims to cache content in order to avoid breaking builds for
> people that depend on your package, so this bad release may still be
> available in the mirror even if it is not available at the origin. The same
> situation applies if you delete your entire repository. We suggest creating
> a new version and encouraging people to use that one instead."

~~~
xvector
If you commit and push your credentials, they have been compromised, full
stop. This proxy should make no difference to how you handle such a
compromise.

~~~
zadokshi
Actually it does make a difference. If an employee accidentally commits a CSV
file with customer private data, are you actually suggesting that it should
not be possible to remove it?

I disagree. The quicker that the personal data can be taken down, the less
chance there is for someone to discover that personal data. I can't imagine
any large company being comfortable with developers choosing technology that
makes this harder to deal with than it should be.

(I am not at all suggesting this scenario is ok, simply asking how one would
deal with it if the scenario should occur.)

~~~
infogulch
The go _checksum database_ / go sum / sum.golang.org appends your module name,
version, and _hash_ of it's contents into a permanent, immutable, public log
as soon the first time it's seen. But sum.golang.org doesn't host any code.

On the other hand, _proxy.golang.org_ re-hosts your module, and you can know
that the proxy isn't serving you maliciously or differently than anyone else
by verifying it via the public checksum database at sum.golang.org.

I don't believe proxy.golang.org, or any proxy for that matter, is _required_
to host _all_ of the modules and versions listed. It's a dumb caching proxy,
and must deal with all of the real world complexities of hosting user content,
including taking it down if deemed necessary. So if they need to take
something down from the proxy they can, and the checksum database will only
permanently retain the _hash_ of the content that makes up the module.

------
jftuga
I have noticed a slight slow down in my own programs - around 5% compared to
1.12. Has anyone else noticed this in with their programs?

~~~
tomlu
File a bug with a repro? Chances are it'll get fixed if your benchmark is
good.

------
Gibbon1
> The existing octal notation indicated by a leading 0 followed by octal
> digits remains valid.

Oh my god why?

~~~
ptman
To not break go1 backwards compat?

~~~
Gibbon1
Compatible with what exactly. No one uses octal.

Here is a link to Pike fucking it up 10 years ago.

[https://github.com/golang/go/issues/151#issuecomment-6604830...](https://github.com/golang/go/issues/151#issuecomment-66048306)

~~~
psanford
Lots of code uses octal. Its still the standard way of notating file
permission bits on unix: os.Chmod(filename, 0777).

You would break so much code if you just threw that away.

~~~
tandr
> standard way of notating file permission bits on unix: os.Chmod(filename,
> 0777)

... and honestly, is the ONLY place where I have ever seen octal been used.

------
arez
Great so now we have a language that leaks my data to a proprietary service
and I can't even see what they're doing with that data. Somehow Google becomes
more and more like Microsoft was in the old days. Why is it so hard to not be
evil? Why is it so hard for devs working at Google to use open-source
paradigms and be careful with anything involving corporations?
[https://github.com/golang/go/issues/34029](https://github.com/golang/go/issues/34029)

------
int_19h
Looking at the release notes:

> Go 1.13 now requires macOS 10.11 El Capitan or later; support for previous
> versions has been discontinued.

> Go 1.13 now requires FreeBSD 11.2 or later; support for previous versions
> has been discontinued. FreeBSD 12.0 or later requires a kernel with the
> COMPAT_FREEBSD11 option set (this is the default).

Sounds like they're still using syscalls directly on those platforms. Is
Google ever going to admit that it's broken by design, because userspace apps
on those platforms (outside of the base system, which is tightly coupled to
the kernel) are not meant to be calling into the kernel directly directly, and
should do everything via libc and other userspace libs that wrap syscalls?

~~~
terinjokes
This has probably been the case since Go 1.11 (2018/08/24)[0]

    
    
        On macOS and iOS, the runtime now uses libSystem.dylib
        instead of calling the kernel directly. This should make
        Go binaries more compatible with future versions of
        macOS and iOS. The syscall package still makes direct
        system calls; fixing this is planned for a
        future release.
    

I'm not an expert in Darwin, but looking at the implementation of the syscall
and runtime packages in Go 1.13, and most seem to be via trampolines into
libSystem.dylib

FreeBSD looks deprecated not because of syscall difficulties, but because
missing functionality and upstream EOL.[1]

[0]:
[https://golang.org/doc/go1.11#runtime](https://golang.org/doc/go1.11#runtime)
[1]:
[https://github.com/golang/go/issues/27619](https://github.com/golang/go/issues/27619)

~~~
int_19h
Fair enough - so it's fixed on macOS, but not on FreeBSD.

That they don't run into issues with this constantly on BSD is not surprising
- it didn't always break in macOS, either. Syscalls just don't change that
much, usually, so you can get away with it more often than not. The problem is
that when they do change eventually, every precompiled Go app that used one
stops working.

