Das Go-Projekt hat am 15. August 2016 Go 1.7 mit einem neuen Compiler-Backend und erweitertem Testsystem veröffentlicht. Die Änderungen betreffen überwiegend Toolchain, Laufzeit und Bibliotheken. Für Teams mit eigenen Netzwerkdiensten oder Entwicklungswerkzeugen sind insbesondere die Kontextverwaltung und die Diagnose nebenläufiger Abläufe relevant.
SSA-Backend zunächst nur für x86-64
Die neue Codeerzeugung verwendet Static Single Assignment, kurz SSA. Diese interne Darstellungsform erleichtert Compiler-Optimierungen. Zum Start steht das Backend ausschließlich für die Plattform amd64 bereit. Das Go-Team meldet in seinen Benchmarks Geschwindigkeitsgewinne zwischen 5 und 35 Prozent. Daraus folgt keine entsprechende Beschleunigung jeder Anwendung und auch keine Aussage über andere Prozessorarchitekturen.
Compiler und Linker wurden ebenfalls beschleunigt; erzeugte Programme können kleiner ausfallen. Laufzeit und Übersetzungsdauer bleiben dabei unterschiedliche Messgrößen. Auch LLVMs ThinLTO für große C++-Builds behandelt dieses Spannungsfeld, arbeitet aber auf einer anderen Stufe der Toolchain. Die Techniken sind nicht miteinander gleichzusetzen.
Abbruch und Fristen werden Teil der Standardbibliothek
Das bisher separat gepflegte Paket golang.org/x/net/context zieht als context in die Standardbibliothek ein. Es transportiert Abbruchsignale, Fristen und an eine Anfrage gebundene Daten. Unterstützung dafür erhalten unter anderem net, net/http und os/exec. Das zusätzliche Paket net/http/httptrace ermöglicht die Beobachtung einzelner Ereignisse innerhalb von HTTP-Anfragen.
Die Release Notes zu Go 1.7 nennen außerdem hierarchische Tests und Benchmarks. Gemeinsame Vorbereitungsschritte lassen sich damit für mehrere Untertests nutzen. Vendoring wird festes Verhalten der Toolchain; die bisherige Umgebungsvariable GO15VENDOREXPERIMENT entfällt.
Plattformfreigaben unterscheiden sich im Reifegrad
Go 1.7 ergänzt die Unterstützung für macOS 10.12 Sierra. Der neue Port für Linux auf IBM z Systems ist dagegen ausdrücklich experimentell. Bei einem Toolchain-Wechsel müssen deshalb neben dem Quellcode auch Zielplattform, Tests und Laufzeitverhalten geprüft werden. Ein neuer Port bedeutet nicht automatisch denselben Unterstützungsstand wie bei bereits etablierten Plattformen.