Go 1.16 Beta 1 | Hacker News Reader

Go 1.16 Beta 1

groups.google.com

86 pointsmnouquet30 comments

Looks like Apple M1 support is live in this version:

> Go 1.16 adds support of 64-bit ARM architecture on macOS (also known as Apple Silicon) with GOOS=darwin, GOARCH=arm64.

A bit ahead of what I think most people expected. This should accelerate a few other projects progress. (Docker being the big one)

https://www.docker.com/blog/download-and-try-the-tech-previe...

From that link:

> The Go language will support Apple Silicon in their 1.16 release which is targeted for February 2021.

That article is a big part of why I said this was a bit earlier than expected. This ticks off one of the concerns Docker devs had about the next version.

That's interesting. I wonder if Apple paid contributors for M1 support. It is a closed eco-system so basically they have done what Apple should contribute if they think they still embrace developers, so I hope they paid them adequately. On the other hand it's a shame that developers spend their time on this rather than other things that could benefit the wider audience rather than just users of M1. It is just my opinion.

It's likely Google paid for Go's M1 port, because Go is Google's language. Apple has supported some OSS projects via hardware donations, I'm not sure if Go benefitted, but Docker has.

I'm not sure why you think the M1 is any more closed than Intel. It's a CPU core owned by a corporation. You can't license either design for personal or commercial use. If you are using x86 you are lining Intel's pockets (and likely Microsoft's). If you are using M1, you are lining Apple's pockets.

Go has had aarch64 support for years. Bootstrapping the toolchain on the M1 worked as soon as the M1 hit the market. The main thing that needed fixing was Go didn't detect ARM CPU features like hardware AES support, fixed by [1]. Since that was written by Googlers, you could say Google funded it.

1: https://github.com/golang/go/commit/c15593197453b8bf90fc3a90...

I cannot buy M1 and a motherboard and install Linux on it.

You can install a third party OS on an M1 Mac or rather... you will be able to as soon as someone ports a third party OS to the M1 Macs. Someone is already making a Linux port.

Yes, but I cannot buy just the CPU and other parts not from Apple.

And yet another definition of "Open"/ "Closed" is born.

There are Intel CPU manuals, optimization manuals, and enough documentation to make an open source driver. That seems quite a bit more open than the M1.

> This should accelerate a few other projects progress

Yes: (at least) 16 brew core formulae have status "Re-check when go works" (some of them: circleci, consul, docker, docker-machine, helm, kubernetes-cli, packer, terraform)

https://github.com/Homebrew/brew/issues/7857

Absolutely can’t wait for this. I want to do some performance and memory usage comparisons.

This is their normal schedule - the beta release is a couple of months before the final release.

The final release is due in Feb.

Gotcha, somehow I missed the Beta 1 on the Title!

I'm always excited for new Vet additions: https://tip.golang.org/doc/go1.16#vet

>The vet tool now warns about invalid calls to the testing.T method Fatal from within a goroutine created during the test.

I've seen this happen a fair number of times, often discovered weeks/months after it was introduced. Good to see it's being warned about now.

The new embed api is nice and simple! I've been using packr2 most recently, but I've been wanting this as part of the core for ages now. It makes having things like a default base configuration as a json file a lot easier.

I think the embed will be super useful. I use to use a older 3rd party package for this.

Yeah this is going to be a massive win for shipping resource dependencies. Genuine single file static linked applications is such a massive win for deployment and management.

That's a great idea to include default configuration as a file instead of coded values!

Thanks! Yea, I built a whole kind of config api for another project a long time ago and used this technique. It worked well.

That said, I went a bit overboard on it because I wanted to load a json file as the 'default' base and then be able to save it on the filesystem, update it via a http API and merge in changes over time to the saved version on disk. The reason was that this 'agent' ran on thousands of little computers (litecoin mining machines) and needed to be configurable per miner.

This is the source if you want to take a look:

https://github.com/blockassets/bam_agent/blob/master/service...

It is all unit tested too.

For another more recent project that isn't open source, I've since re-done it to be a lot simpler (and moved to packr2). It just reads the file. =)

I'm excited about io/fs[1]. As a newcomer to Go, one of my favorite things is the excellent I/O interfaces. I can write code to take io.Writer's or io.Reader's (etc.) and my program is suddenly both a CLI app, a Web app, and a Whatever app with minimal effort. (The effect is similar at lower levels too. For example, I can log to a file or to memory with a one-line change.) I sense a lot of potential in applying this interface-based design on filesystems themselves.

[1]: https://tip.golang.org/pkg/io/fs/

Reading the API, I wonder how they plan to cancel long running (blocking) tasks, like WalkDir.

Since there's no context in the API, you'd probably just need to use a WalkDirFunc with a closure that can reach the context. Awkward for sure.

I was referring to io outside of the WalkDirFunc. ;-)

Instantiate the FS with a context, instead of requiring a context for each kind of FS operation.

The release notes (linked) are the interesting part: https://tip.golang.org/doc/go1.16

Annoyingly, the `go get golang.org/dl/go1.16beta1` installation method doesn't work on ApSi even if you already have an ApSi-supporting version (+edf60be151) installed. But the tar.gz for darwin/arm64 works perfectly.

Yay for `GO111MODULE=on` as default. I always had to google the name of that environment var.

I remember the community backlash against go modules but that all has but faded. Packages are easier to install in this release with the version qualifier.

The embed stuff is sweet.

Reply on news.ycombinator.com