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.
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.
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.
> 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.
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.
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)
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.
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.
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.
32 comments
[ 2.8 ms ] story [ 81.6 ms ] threadThat 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. =)
> 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)
> 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.
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.
1: https://github.com/golang/go/commit/c15593197453b8bf90fc3a90...
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
The final release is due in Feb.
>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.
[1]: https://tip.golang.org/pkg/io/fs/
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.