* In any remotely trustable and reliable way; random PPAs relying on somebody's free time don't count, IMHO.
I've noticed Ubuntu, Debian, Centos, and Oracle Enterprise Linux are always trailing by quite a clip. Often years.
The strategy I've been using is to just manually install it on the machines where I need it. The production go versions only get updated as required.
Arch Linux.
I just saw the release when I was checking for updated versions of packages I maintain, and built it before users started bugging me about outdated go binaries.
3 MB savings on Mac, and 2 MB on Windows: https://github.com/caddyserver/caddy/pull/3642#issuecomment-...
So about 8-10% reduction.
Reducing binary size makes a difference when the app is deployed to remote servers thousands of times under normal operation.
Storage and bandwidth is cheap, yes, but it adds up.
I've noticed the issue of big deploy sizes with docker including with interpreted and other big package languages (Java can haul around a ton + JVM etc). It's somewhat hard to get small container sizes even for a simple hello world program with these approaches.
Folks are doing 15MB docker images for Go. Google likes really stripped down things (low attack surface etc) - see their distroless initiative.
...but the point being made is at 10% reduction, a 9MB and a 10MB binary are indistinguishable.
They scale almost identically.
so... it seems a bit like premature optimisation to devote such a large amount of effort to what appears to be a win that affects virtually no one except those few (FANG) who deploy to thousands of services daily.
Are there other mainstream languages that are as conservative as Go when it comes to adding new features?
I don't love Go as a language, but coming from C++ and Python, both of which have non-stop accumulation of features (and complexity), Go's philosophy is a breath of fresh air.
I too like Go's restraint. It really doesn't want to give you a tool to make a one-liner that is easy to conceal a bug. For example, Go's increment (eg, i++) is a statement, not an expression. You can't do list[++i] or anything.
There are parts of Go that I'm less a fan of, but they keep a nice eye toward making sure that the code is understandable and reviewable.
Though, I wonder how much more the language could be improved if it weren't tied down to the bad decisions of the past. Those must all continue in perpetuity while the compatibility promise is kept.
https://www.youtube.com/watch?v=4Dr8FXs9aJM&t=169
I can't help but laugh each time I see it.
They even announced that the language is now final.
The last really big change was transducers, and even those were nicely retrofitted onto the core functions without any breaking changes.
I'm glad this is fixed! That will make life that one bit less annoying.
Official blog post: https://blog.golang.org/go1.15.
Some fixes already planned for Go 1.15.1: https://github.com/golang/go/milestone/162.
This sounds interesting.
To get explanations on the optimization decisions by the compiler build your package with:
go build -gcflags="-m -m"
go tool compile -h
go doc cmd/compileBlog post -> [ https://blog.golang.org/go1.15 ] <-
So much good stuff in this release, COVID notwithstanding, including an extremely improved linker and smaller binaries. Definitely the best Go release ever :)
Here's some details on the changes in the corner of it that Katie and I take care of.
The long deprecated Common Name field on X.509 certificates is now ignored, reducing complexity and removing a gnarly conflict with Name constraints. Public CAs are unaffected, the only major service that broke was AWS RDS, and they've been awesome and fixed it in time for the release (but customers need to regenerate certificates). I honestly did not expect this change to make it and I am thrilled about it and what it means for keeping the Go X.509 ecosystem modern and secure. https://github.com/golang/go/issues/39568#issuecomment-67142...
crypto/tls Configs now have a spiffy VerifyConnection callback that runs for all connections (which is easier to think about than VerifyPeerCertificate) and that gets passed a ConnectionState. This was Katie's idea to make the callback have access to SCTs and stapled OCSP (which makes it possible to write verifying callbacks for those, although we are working on built-in suppport!) but I also love how it delivers the parsed certificates and makes it trivial to customize verification. https://golang.org/pkg/crypto/tls/#example_Config_verifyConn... https://golang.org/cl/229122
What I should have started with: session ticket keys and session tickets are now rotated automatically without any impact on the application :sparkles:, greatly mitigating the main weak link in the forward security chain of TLS 1.2. :happydance: This is a. big. deal. https://blog.filippo.io/we-need-to-talk-about-session-ticket... https://golang.org/cl/231317 https://golang.org/cl/230679
Besides deprecating Common Name, X.509 verification also now has a consistent story on how to handle invalid hostnames: they are matched case-insensitively 1:1 to certificate fields without wildcard or trailing dot processing. There is no spec that says what to do with them, so we had to come with a policy that is predictable, doesn't break applications, but can be implemented securely. It was amazingly difficult. https://golang.org/cl/231378 https://golang.org/cl/231380 https://golang.org/cl/231381
crypto/ecdsa now has SignASN1 and VerifyASN1 functions that do what Sign and Verify should have done all along and operate on byte slices instead of big.Ints. https://golang.org/cl/217940
There is now a function to make RFC 5280-compliant X.509 v2 Certificate Revocation Lists. https://golang.org/cl/217298
Public and private key types now have an Equal method that works with go-cmp, and lets you make your own non-empty PublicKey interface. https://golang.org/cl/231417
crypto/elliptic now has functions to marshal and unmarshal compressed elliptic curve points. Too many people had to implement this one! https://golang.org/cl/202819
math/big.Int now has a method that makes me extremely happy. FillBytes takes a fixed size buffer and puts the value in it, which is both more performant, and saves annoying padding steps in most crypto applications. If you ever had a bug that only happened 1/256 of the times because you were not adding the padding zero at the beginning if the value happened to be small, this is for you. You know who you are, remember that the support group this week meets on Wednesday not Thursday. https://golang.org/cl/230397
Finally, Cthulhu. On macOS we now use the system root store even if there's no cgo, by calling straight into Security.framework with... there's assembly involved, that is all. This code is my nemesis, so it was all worth it. https://golang.org/cl/227037
And more! Check out the release notes. I also plan to write in details about the changes on my newsletter, like I did for Go 1.14.
I feel like I’m developing an addiction to hacks like this. Ever since I started to gain a more intuitive understanding of calling conventions and C/++ ABI I’ve been doing asm calls into MSVC functions and manually laying out COM vtables in pure Go. It’s powerful as long as you have reasonable assurances the ABI rug won’t be pulled from under you!
This is nice. I basically only write small CLIs with Go and don't explicitly define help flags. I always wondered why it returned an exit code of 2.
This also means that, if your OS certificate store trusts the cryptographic signer of the archive, then the archive can 1. be auto-expanded after download, in effect giving you the experience of "downloading a folder" (or in macOS, "downloading a bundle") directly; 2. the contents can skip having your OS's foreign-source / untrusted / quarantine xattr-of-choice applied to them; and 3. any disk images unpacked from the archive can have an xattr applied to them saying that they've been pre-integrity-checked and can skip any checksum verification they'd normally do on mount.
Sadly, Apple's implementation of .XIP (which is, AFAIK, the only existing implementation of .XIP), which used to be happy to unpack arbitrary .xip file, switched in 10.13 to only expanding .xip files signed by Apple, treating anyone else's .xips as invalid. So .XIP itself is "broken"—since, even if it was adopted by other players, at least on one major OS the default handler would just say the archive is corrupt.
But that doesn't mean that the concept behind .XIP is bad. Someone could totally create an open format that has equivalent extraction semantics to .XIP, but "for real." It's not like there's any patented tech here; it's just a format with metadata attached, that archivers have special logic for. We'd just need support for the same sort of verification—but against the actual OS cert store—in extractors like 7zip, The Unarchiver, and GNOME's Archive Manager.
-----
Then again, maybe this would be a too-soon-obsolete technology anyway. Every OS's primary filesystem seems to trending toward a concept of subvolumes these days.
In a world where all filesystems supported subvolumes, an ideal archive format would just be a CQRS event-stream representation of the construction process for the dirents+inodes+extents of a subvolume, in some vendor-neutral "abstract filesystem" format.
Older/traditional systems could hold onto, and pass around, such an archive as a file (though, to operate on it, they'd have to effectively rebuild a regular disk-image-alike from it.)
But, upon receipt by a modern consumer OS, the downloading program could ask the filesystem to not reserve a file for the download, but rather to reserve a subvolume for the download, and then feed in the download body as a "change stream" for that subvolume, ala `btrfs receive`.
So you'd never actually write such an archive to disk in its packed state; you'd just unpack it as you receive it into its own isolated subvolume space. Like a streaming `tar x`, but without the decision of where to put the result. The new subvolume could even be a "non-root item" in the garbage collection sense; ref-counted by its firm-link references within your existing filesystems (where one such firm-link would be added from the beginning by the downloading program.)
Such a subvolume-event-stream archive format could have the same sort of cryptographic integrity-checking as .XIP, where subvolume-streams signed by trusted sources would have different forced-mount-flag metadata set for the unpacked subvolume. Interestingly, this cryptographic integrity-checking could be applied by the filesystem driver as it constructs the subvolume from the stream, thus making it impossible for an application to screw up, and ensuring that the contents are never made available to userspace if they're corrupt, or signed by a blacklisted signer.
As a bonus, you could have [signed] subvolume-event-stream archives that are incremental, and OS an app authors could use those for version updates, patching read-only subvolume "app-vN" or "OS-vN" with an update-stream to generate "app-vN+1" or "OS-vN+1." Like a cross between how CoreOS does OS updates, and Google Chrome's Courgette binary-diff updates.
Signature: https://storage.googleapis.com/golang/go1.15.src.tar.gz.asc
Signed with `EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796` which is the Google Linux Packages Signing Authority.
EDIT: I realized you wanted the binaries.
You can fetch them from "https://dl.google.com/go/go1.15.linux-amd64.tar.gz.asc", append `.asc` to the binary I reckon.
Signed with the same key as the source release.
Would love to know if they're there and I've missed them.
Rob Pike is the ultimate troll.
Until you reach channels and realize that mantra apparently went out the window at some point.