--- id: 1a31e06c0d969b4b6cbbc590259cf089 author: iwanhae title: Go 1.27, oder wie ich lernte, mir keine Sorgen mehr zu machen und generische Methoden zu lieben description: Generische Methoden, encoding/json/v2, ein Standardpaket für uuid und ein Goroutine-Leak-Detektor, der tatsächlich funktioniert. Eine Übersicht über Go 1.27 mit Beispielen, die allesamt tatsächlich ausgeführt wurden. language: de date: 2026-08-15T02:08:43.129534158Z path: /blog/posts/go-1-27-or-how-i-learned-to-stop-worrying-and-love-generic-methods-za800e454 category: release --- ![Überblick über Go 1.27](/assets/images/whats-new-in-go1.27/overview.webp) Go 1.27 erscheint im August 2026, und diesmal hat sich die Sprache selbst verändert. Nicht in dem Sinne, dass „wir eine neue Funktion zu `slices` hinzugefügt haben", sondern tatsächlich. Generische Methoden sind eingeführt. Ein elf Jahre altes Issue wurde geschlossen. `encoding/json` wurde leise durch eine neue Engine ersetzt, während das Flugzeug in der Luft war. Jedes der folgenden Beispiele wurde mit `go1.27rc3` (darwin/arm64) ausgeführt. Jeder Ausgabeblock ist echte Ausgabe, kopiert, einschließlich der Fehlermeldungen. Wenn etwas merkwürdig aussieht, liegt das daran, dass der Compiler tatsächlich so geantwortet hat. ```bash go install golang.org/dl/go1.27rc3@latest go1.27rc3 download ``` ## 1. Die Sprache hat sich verändert (ja, wirklich) ### 1.1. Generische Methoden Seit Go 1.18 gibt es Generics, und seit Go 1.18 gibt es auch das Gespräch. Es verläuft so: > „Ich schreibe einfach eine `Map`-Methode für meinen Slice-Typ:" > > `method must have no type parameters` > > „...gut. Dann eben eine Funktion auf Paketebene." Methoden konnten nur Typparameter verwenden, die vom _Receiver_ deklariert wurden. Eine eigene Methode konnte keine neuen einführen. Also wurde jede generische Transformation in den Paketbereich verbannt, wo sie neben siebzehn anderen frei stehenden Hilfsfunktionen lag, die alle irgendeine Variante von `MapSlice` hießen. Go 1.27 behebt dieses Problem: ```go type List[E any] []E // F ist ein Typparameter, der von der Methode selbst deklariert wird func (l List[E]) Apply[F any](f func(E) F) List[F] { r := make(List[F], len(l)) for i, x := range l { r[i] = f(x) } return r } func main() { l := List[int]{1, 2, 3} fmt.Println(l.Apply(func(i int) string { return fmt.Sprint(i * 10) })) // [10 20 30] } ``` Der Receiver muss nicht einmal generisch sein. Ein schlichter Struct kann eine generische Methode haben: ```go type Bag struct{ items []any } func (b *Bag) Add[T any](v T) { b.items = append(b.items, v) } ``` Bevor Sie heute Nachmittag Ihre gesamte Codebasis umbauen, gibt es nun **zwei Einschränkungen**, die wichtiger sind, als sie auf den ersten Blick wirken: 1. Interface-Methoden dürfen keine Typparameter deklarieren. 2. Generische Methoden können keine Interface-Methoden implementieren. Die zweite Einschränkung ist diejenige, die Sie tatsächlich treffen wird: ```go type Adder interface{ Add(int) int } type G struct{} func (G) Add[T any](v T) T { return v } var _ Adder = G{} ``` ``` cannot use G{} (value of struct type G) as Adder value in variable declaration: G does not implement Adder (wrong type for method Add) have Add[T any](T) T want Add(int) int ``` Generische Methoden und dynamische Dispatch vertragen sich also nicht. Das ist keine Knauserigkeit des Go-Teams: Eine generische Methode hat unendlich viele Instanziierungen, eine Interface-Methodentabelle muss jedoch endlich sein und zur Kompilierzeit feststehen. Man kann kein Unendliches in eine endliche Tabelle packen. Das Universum hat Nein gesagt. Praktisch bedeutet das: Generische Methoden sind für konkrete Typen mit hilfsfunktionsartigen APIs gedacht. Alles, was sich hinter einem Interface verbergen muss, braucht weiterhin den alten Ansatz. Die Standardbibliothek hat das bereits genutzt. Der `Rand` aus `math/rand/v2` erhielt eine generische Methode: ```go func (r *Rand) N[Int intType](n Int) Int ``` ```go r := rand.New(rand.NewPCG(1, 2)) fmt.Println(r.N(int32(100))) // 76 fmt.Println(r.N(time.Second)) // 616.436223ms ``` Bisher war nur die Funktion `rand.N` auf Paketebene generisch, was bedeutete, dass sie die globale Quelle verwendete. Jetzt erhält Ihr eigenes, seeded `*Rand` denselben Komfort. Eine kleine Sache. Eine schöne Sache. ### 1.2. Feldselektoren in Struct-Literalen, oder: Issue #9859 wird endlich geschlossen Embedding ermöglicht `u.ID`. Embedding ermöglicht _nicht_ `User{ID: 1}`. Stattdessen verlangt es `User{Base: Base{ID: 1}}`, was Gos Art ist, nachzufragen, ob Sie das wirklich so gemeint haben. [Issue #9859](https://go.dev/issue/9859) wurde 2015 eröffnet. Es wurde nun geschlossen. Irgendwo bekommt ein Gopher, der inzwischen zweimal den Beruf gewechselt hat, eine GitHub-Benachrichtigung. ```go type Object struct{ name, color string } type Point3D struct { Object x, y, z float64 } type Line struct { Object p, q Point3D } // Go 1.27: das hochgestufte Feld direkt verwenden line := Line{name: "diagonal", q: Point3D{y: -4, z: 12.3}} ``` `name` ist kein Feld von `Line`. Es ist ein Feld des eingebetteten `Object`. Bisher hätte man `Line{Object: Object{name: "diagonal"}, ...}` schreiben müssen. Nun zum Kleingedruckten, das ich geprüft habe, indem ich tatsächlich versucht habe, alles zu kompilieren. **(a) Der Schlüssel ist weiterhin ein einfacher Bezeichner.** Sie können keinen beliebigen Selektorpfad angeben. ```go _ = Line{Object.name: "x"} // invalid field name Object.name in struct literal _ = Line{p.x: 1} // invalid field name p.x in struct literal ``` Das Feature bedeutet also nicht, dass Schlüssel jetzt wie Feldzugriffe funktionieren. Es erlaubt konkret implizit hochgestufte Feldnamen. Das ist etwas enger, als die Überschrift vermuten lässt. **(b) Sie können nicht gleichzeitig ein eingebettetes Feld und etwas angeben, das aus ihm hochgestuft wurde.** ```go obj := Object{"edge", "black"} _ = Line{Object: obj, name: "diagonal"} // cannot specify promoted field name and enclosing embedded field Object ``` Vernünftig. Sie haben dem Compiler zwei widersprüchliche Dinge über denselben Speicher mitgeteilt, und er hat sich geweigert zu raten. **(c) Eingebettete Zeiger sind nicht vorgesehen.** ```go type PtrEmbed struct { *Object z int } _ = PtrEmbed{name: "x"} // invalid implicit pointer indirection to reach name ``` Um einem Zeiger zu folgen, braucht man einen Zeiger, dem man folgen kann, und zum Zeitpunkt der Literalkonstruktion existiert noch keiner. Auch das ist fair. Die gute Nachricht: `go fix` schreibt Ihre alten Literale für Sie um. Dazu später mehr. ### 1.3. Typinferenz für Funktionstypen ist weniger willkürlich Die Typinferenz für generische Funktionen funktionierte früher an manchen Stellen und an anderen nicht, ohne erkennbares Prinzip dahinter. Einer Variablen zuweisen? Kein Problem. Dieselbe Funktion in einem Struct-Feld ablegen? Compiler-Fehler, bitte schreiben Sie `double[int]`, als wäre es 2022. Go 1.27 sorgt dafür, dass die Inferenz in **jedem Kontext funktioniert, in dem der Zieltyp eindeutig bekannt ist**: ```go func double[T ~int | ~float64](v T) T { return v * 2 } type S struct{ f func(int) int } type A [1]func(int) int func main() { s := S{f: double} // 1.26: benötigte double[int] a := A{double} // 1.26: benötigte double[int] c := make(chan func(int) int, 1) c <- double // 1.26: benötigte double[int] var fn func(float64) float64 = double // das hat immer funktioniert fmt.Println(s.f(21), a[0](5), (<-c)(7), fn(1.5)) // 42 10 14 3 } ``` Ein einziges `double` wird an drei Stellen als `func(int) int` und an einer vierten als `func(float64) float64` instanziiert, und zwar vollständig aus dem Kontext. Wenn Sie Optionsstrukturen oder Handler-Tabellen voller Funktionswerte schreiben, verschwindet bald eine Menge `[T]`-Rauschen aus Ihrer Codebasis. ## 2. Laufzeit: kostenlose Performance und ein Leak-Detektor ### 2.1. Größenspezialisierte Allokation Der Compiler erzeugt nun für kleine Objekte Aufrufe von größenspezialisierten Allokationsroutinen. Die Release Notes versprechen bis zu 30 % weniger Allokationskosten für Objekte unter 80 Bytes und etwa 1 % insgesamt für allokationsintensive Programme. Ich glaube Release Notes nicht ohne Messung, also: ```go type small struct{ a, b, c, d int } var sink any func BenchmarkAlloc(b *testing.B) { for b.Loop() { sink = &small{} } } func BenchmarkSlice(b *testing.B) { for b.Loop() { sink = make([]byte, 48) } } ``` ``` # Standard (größenspezialisierte malloc aktiv) BenchmarkAlloc-12 3000000 5.358 ns/op BenchmarkSlice-12 3000000 13.58 ns/op # GOEXPERIMENT=nosizespecializedmalloc BenchmarkAlloc-12 3000000 8.722 ns/op BenchmarkSlice-12 3000000 20.81 ns/op ``` 30 bis 35 % schneller in einem Mikrobenchmark, der auf Apple Silicon nichts anderes tut als allokieren. Das heißt: Dies ist der Bestfall, unter Laborbedingungen erzielt, mit einem Benchmark, der so entworfen wurde, dass die Zahl gut aussieht. In einem echten Programm begraben GC und tatsächliche Arbeit den größten Teil davon. Die Angabe von etwa 1 % ist die ehrliche. Der Preis ist die Binärgröße. Hello World: ``` 2413202 bytes (default) 2361826 bytes (nosizespecializedmalloc) ``` Etwa 50 KB, fest, unabhängig von Ihrem Programm. Sie können sich mit `GOEXPERIMENT=nosizespecializedmalloc` abmelden, aber **dieser Fluchtweg soll in Go 1.28 entfernt werden**. Behandeln Sie ihn also als Workaround für Bug-Reports und nicht als Lebensstil. ### 2.2. Das Goroutine-Leak-Profil ist jetzt real In Go 1.26 experimentell, in 1.27 allgemein verfügbar. Das GOEXPERIMENT `goroutineleakprofile` ist verschwunden; es funktioniert einfach. ```go func leak() { ch := make(chan int) // Niemand wird jemals senden. Niemand. go func() { <-ch }() } func main() { for range 3 { leak() } runtime.GC() runtime.GC() pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1) } ``` ``` goroutineleak profile: total 3 3 @ 0x104de3f18 0x104d7f0b0 0x104d7ec34 0x104e374f4 0x104dea024 # 0x104e374f3 main.leak.func1+0x23 /tmp/go127/leak/main.go:12 ``` Drei Goroutinen, dauerhaft festsitzend, mit einer Datei- und Zeilenangabe, die genau auf die Stelle zeigt, an der Sie das verursacht haben. Der Trick dahinter ist wirklich clever: Er **nutzt die Erreichbarkeitsanalyse des Garbage Collectors wieder**. Wenn Goroutine G auf Primitive P blockiert und P von keiner lauffähigen Goroutine (oder von allem, was diese Goroutinen wecken könnten) erreichbar ist, dann kann P niemals wieder berührt werden, und G wird daher nie aufwachen. Das ist keine Heuristik, sondern ein Beweis. Dasselbe Design liefert die Einschränkung gleich mit: Wenn der Channel oder Mutex über eine globale Variable oder über eine lokale Variable einer noch laufenden Goroutine erreichbar ist, kann der GC ihn weiterhin sehen, sodass die Laufzeit nichts folgern kann. Beachten Sie, dass selbst das obige Spielzeugbeispiel zwei Aufrufe von `runtime.GC()` benötigt, bevor es meldet. Es fängt nicht alles. Es fängt jedoch den klassischen Fall „vergessen, den Context abzubrechen, die Worker-Goroutine lebt ewig", und das ist den größten Teil der Zeit der häufigste Leak. Wenn Sie `net/http/pprof` importieren, ist es außerdem unter `/debug/pprof/goroutineleak` erreichbar. Binden Sie das in Staging ein, prüfen Sie es wöchentlich und seien Sie insgeheim entsetzt. Diese Arbeit wurde von Vlad Saioc bei Uber beigetragen, dem ein Getränk seiner Wahl zusteht. ### 2.3. Tracebacks verraten jetzt, welcher Request gestorben ist Für Module, die Go 1.27 oder neuer deklarieren, enthalten Traceback-Kopfzeilen nun die Goroutine-Labels aus `runtime/pprof`. ```go func handle(ctx context.Context) { var wg sync.WaitGroup wg.Go(func() { buf := make([]byte, 4<<10) os.Stdout.Write(buf[:runtime.Stack(buf, true)]) }) wg.Wait() } func main() { labels := pprof.Labels("request", "GET /orders/42", "tenant", "acme") pprof.Do(context.Background(), labels, handle) } ``` ``` goroutine 3 [running] {request: "GET /orders/42", tenant: acme}: main.handle.func1() /tmp/go127/tblabel/main.go:15 +0x40 sync.(*WaitGroup).Go.func1() ... goroutine 1 [sync.WaitGroup.Wait] {request: "GET /orders/42", tenant: acme}: ... ``` Das wichtige Detail: **Labels werden an Kind-Goroutinen vererbt.** Goroutine 3 hat nie ein Label gesetzt. Sie hat es von ihrem Elternteil erhalten. Wenn also das nächste Mal die Produktion in einen Deadlock läuft und jemand den Prozess mit SIGQUIT beendet, erhalten Sie statt 4.000 Goroutinen, die alle identisch aussehen, 4.000 Goroutinen, die mit dem Request und dem Tenant markiert sind, zu dem sie gehören. Drei Zeilen `pprof.Do` an Ihrem Request-Einstiegspunkt verschaffen Ihnen genau das. Da Labels Dinge enthalten können, die Sie lieber nicht nach stderr schreiben würden, schaltet `GODEBUG=tracebacklabels=0` das Feature ab, und diese Abmeldemöglichkeit soll ausdrücklich für immer erhalten bleiben. ### 2.4. asynctimerchan ist endgültig weg Go 1.23 machte Timer-Channels unbuffered (synchron) und bot `asynctimerchan=1` als Weg zurück zum alten Verhalten an. In 1.27 wird diese Einstellung **dauerhaft entfernt**. Die Channels des Pakets `time` sind synchron, Punkt, ohne Verhandlung. Interessant ist die Richtlinie, die dafür eingeführt wurde. Ein entferntes GODEBUG, das noch in Ihrer `go.mod` steht, lässt den Build nicht automatisch scheitern. Er scheitert nur dann, wenn es auf den **alten** Wert gesetzt ist: ``` # go.mod enthält: godebug asynctimerchan=1 go: error loading go.mod: go.mod:5: removed GODEBUG "asynctimerchan" set to old value "1" (https://go.dev/doc/godebug#go-127) # go.mod enthält: godebug asynctimerchan=0 (builds fine) ``` Das bedeutet, dass nur diejenigen zurechtgewiesen werden, die sich tatsächlich auf das entfernte Verhalten verlassen haben. Alle, die es auf den späteren Standardwert gesetzt und dann vergessen haben, dürfen weiterhin nicht daran denken. Das ist ein durchdachtes Stück API-Archäologie. ## 3. Standardbibliothek ### 3.1. encoding/json/v2: Die Engine wurde im laufenden Betrieb ersetzt Das ist die große Neuerung. [Über zwei Jahre Diskussion über den Vorschlag](https://go.dev/issue/71497) sind endlich eingeflossen. Es gibt nun **drei Pakete**, und das Verständnis dieser Aufteilung ist bereits der größte Teil der Arbeit: | Paket | Aufgabe | | ------------------------ | ------------------------------------------------------------------------------ | | `encoding/json` | Die v1-API, die Sie kennen. **Verhalten zu 100 % unverändert.** Nun auf v2 aufgebaut | | `encoding/json/v2` | Semantische Verarbeitung. Go-Werte ↔ JSON | | `encoding/json/jsontext` | Syntaktische Verarbeitung. JSON als Token-Strom | Die Hauptaussage lautet, dass `encoding/json` auf einer völlig anderen Implementierung neu aufgebaut wurde und sich **identisch verhält**. So funktioniert das: ```go // encoding/json.Unmarshal aus Go 1.27, gekürzt func Unmarshal(data []byte, v any) error { return jsonv2.Unmarshal(data, v, DefaultOptionsV1()) } ``` Jede Eigenart von v1 wurde als Option kodiert, im Paket `DefaultOptionsV1()` gebündelt, und die v1-API wendet dieses Bündel immer an. Das bedeutet, dass sich folgender Code in 1.26 und 1.27 gleich verhält: ```go var m map[string]int json.Unmarshal([]byte(`{"a":1,"a":2}`), &m) // , map[a:2] ``` Ja, v1 akzeptiert doppelte Schlüssel weiterhin stillschweigend und nimmt den letzten. Das hat es schon immer getan, und es tut es noch immer. Kompatibilität bedeutet Kompatibilität auch mit den schlechten Teilen. **v2 hingegen hat Meinungen:** ```go var m map[string]int jsonv2.Unmarshal([]byte(`{"a":1,"a":2}`), &m) // jsontext: duplicate object member name "a" var s string jsonv2.Unmarshal([]byte("\"\xff\""), &s) // jsontext: invalid UTF-8 after offset 1 ``` Doppelte Schlüssel und ungültiges UTF-8 werden abgelehnt. Beides ist wirklich gefährlich, nicht nur unordentlich: Wenn sich zwei Parser darüber uneinig sind, welcher doppelte Schlüssel gilt, entstehen Sicherheitslücken. CVE-2017-12635 bei CouchDB war genau das: ein JSON-Body mit zwei `roles`-Schlüsseln, wobei der Validator den einen las und die Speicherschicht den anderen. Das Ablehnen ist die richtige Entscheidung. Optionen werden variadisch übergeben: ```go type Config struct { Name string `json:"name"` Tags []string `json:"tags,omitzero"` Timeout int `json:"timeout,omitzero"` } out, _ := jsonv2.Marshal(Config{Name: "api"}) // {"name":"api"} // sortierte Map-Schlüssel + Einrückung out, _ = jsonv2.Marshal(map[string]int{"b": 2, "a": 1}, jsonv2.Deterministic(true), jsontext.WithIndent(" ")) // { // "a": 1, // "b": 2 // } // unbekannte Felder ablehnen; früher war dafür ein Decoder mit DisallowUnknownFields() nötig var c Config err := jsonv2.Unmarshal([]byte(`{"name":"api","nope":1}`), &c, jsonv2.RejectUnknownMembers(true)) // json: cannot unmarshal JSON string into Go main.Config: // unknown object member name "nope" ``` `Deterministic`, `MatchCaseInsensitiveNames`, `StringifyNumbers`, `FormatNilSliceAsNull`, `OmitZeroStructFields`: Die meisten Dinge, für die Sie bisher eine Drittanbieter-Bibliothek oder ein handgeschriebenes `MarshalJSON` brauchten, sind nun Flags. Und die Migrationsgeschichte ist der beste Teil. **Spätere Optionen gewinnen**, sodass Sie die Strenge von v2 Verhalten für Verhalten übernehmen können: ```go // v1-Semantik beibehalten, aber doppelte Schlüssel wie v2 ablehnen jsonv2.Unmarshal(data, &v, json.DefaultOptionsV1(), jsontext.AllowDuplicateNames(false)) // duplicate object member name ``` Sie müssen eine Codebasis mit 200.000 Zeilen nicht nach v2 portieren, um doppelte Schlüssel nicht mehr zu akzeptieren. Sie schalten eine Option um. Für große Codebasen ist das der realistische Weg. Performance: Das Marshalling ist ungefähr gleichwertig, **das Unmarshalling ist deutlich schneller.** Falls etwas schiefgeht, stellt `GOEXPERIMENT=nojsonv2` die alte Implementierung wieder her. Auch diese Abmeldemöglichkeit steht irgendwann zur Disposition, reichen Sie also lieber ein Issue ein, statt sich damit abzufinden. `jsontext` ist die Low-Level-Schicht: `Encoder` und `Decoder`, die JSON als `Token` und `Value` durchlaufen, mit einer Zustandsmaschine, die Sie ehrlich hält. Greifen Sie danach, wenn Sie einen Streaming-Transformer oder einen JSON-Filter schreiben und Go-Werte gar nicht erst materialisieren möchten. ### 3.2. Ein Standard-uuid-Paket Endlich. RFC 9562, in der Standardbibliothek, ohne `go get`. ```go import "uuid" func main() { fmt.Println(uuid.NewV4()) // b97aa695-da08-472c-af81-ff088129019f // v7: die oberen 48 Bits sind ein Zeitstempel, daher sortieren diese immer in Erstellungsreihenfolge a, b := uuid.NewV7(), uuid.NewV7() fmt.Println(a.Compare(b) < 0) // true u, err := uuid.Parse("urn:uuid:0198a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b") fmt.Println(u, err) // 0198a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b fmt.Println(uuid.Nil(), uuid.Max()) // 00000000-0000-0000-0000-000000000000 ffffffff-ffff-ffff-ffff-ffffffffffff } ``` Die gesamte API besteht aus `New`, `NewV4`, `NewV7`, `Nil`, `Max`, `Parse`, `MustParse` und einem Typ: `type UUID [16]byte`. Das ist alles. Sie können die komplette Paketdokumentation lesen, während Ihr Kaffee abkühlt. Details, die man wissen sollte: - **`UUID` ist `[16]byte`**, daher funktioniert `==`, und der Typ ist direkt als Map-Schlüssel verwendbar. Gleiches Design wie `google/uuid`. - **`Nil` und `Max` sind Funktionen, keine Variablen.** Eine paketweite `var Nil UUID` wäre eine geladene Waffe, auf den eigenen Fuß gerichtet, und irgendjemand würde irgendwann darauf zuweisen. - Die Zufallsbits stammen von einem **kryptographisch sicheren** Generator. - Es implementiert `encoding.TextMarshaler`, `TextUnmarshaler` und `TextAppender`, passt also direkt in JSON-Structs. - **`NewV7` ist die richtige Wahl für Primärschlüssel in Datenbanken.** Zeitlich geordnet bedeutet, dass Ihr B-Baum-Index nicht mehr fragmentiert, was v4-UUIDs bekanntermaßen schlecht können. Sie können jetzt eine Abhängigkeit streichen. Wenn Sie v1/v3/v5 oder anspruchsvollere Parsing-Optionen benötigen, haben Drittanbieter-Bibliotheken weiterhin ihre Berechtigung. ### 3.3. crypto/mldsa: Post-Quanten-Signaturen, und sie sind riesig Go 1.24 brachte `crypto/mlkem` für den Post-Quanten-Schlüsselaustausch. Go 1.27 liefert die andere Hälfte: ML-DSA-Signaturen, standardisiert als FIPS 204. ```go sk, _ := mldsa.GenerateKey(mldsa.MLDSA65()) pk := sk.PublicKey() msg := []byte("release the gophers") opts := &mldsa.Options{Context: "gosuda.org/blog"} sig, _ := sk.Sign(rand.Reader, msg, opts) fmt.Println("private key seed:", len(sk.Bytes()), "bytes") // 32 fmt.Println("public key:", len(pk.Bytes()), "bytes") // 1952 fmt.Println("signature:", len(sig), "bytes") // 3309 fmt.Println(mldsa.Verify(pk, msg, sig, opts)) // fmt.Println(mldsa.Verify(pk, msg, sig, &mldsa.Options{Context: "other"})) // mldsa: invalid signature ``` Schauen Sie sich diese Zahlen an. **Eine einzelne Signatur hat 3.309 Bytes.** Ed25519 hat 64. Das ist eine Steigerung um den Faktor 50, und der öffentliche Schlüssel umfasst zusätzlich knapp 2 KB. Packen Sie einige davon in eine Zertifikatskette, und Ihr TLS-Handshake braucht eine eigene MTU-Strategie. Das ist der tatsächliche Preis der Quantenresistenz heute, und deshalb stellt morgen noch niemand alles um. Aber das Verfahren ist jetzt in der Standardbibliothek, und dort soll es sein, _bevor_ Sie es brauchen. `Options.Context` dient der Domänentrennung: Signieren Sie mit demselben Schlüssel für verschiedene Zwecke, verwenden Sie für jeden einen anderen Kontext, und eine Signatur aus einem Kontext wird in einem anderen nicht verifiziert. Das obige Beispiel zeigt genau das: derselbe Schlüssel, dieselbe Nachricht, anderer Kontext, abgelehnt. `PrivateKey` implementiert `crypto.Signer`, passt also in bestehende Interfaces. `crypto/x509` verarbeitet ML-DSA-Schlüssel und -Signaturen, und `crypto/tls` unterstützt die Signaturverfahren `MLDSA44`, `MLDSA65` und `MLDSA87` in TLS 1.3. Außerdem gibt es `SignDeterministic`, das auf Zufall verzichtet. Das ist praktisch für Tests und reproduzierbare Builds. ### 3.4. simd: Vektorbefehle ohne Assembler Go 1.26 führte das architekturspezifische `simd/archsimd` als Experiment ein. Go 1.27 fügt `simd` hinzu: **portabel und unabhängig von der Vektorbreite**. Aktivierung mit `GOEXPERIMENT=simd`. ```go // dst = a*x + y func axpy(dst, x, y []float32, a float32) { va := simd.BroadcastFloat32s(a) w := va.Len() i := 0 for ; i+w <= len(x); i += w { vx := simd.LoadFloat32s(x[i:]) vy := simd.LoadFloat32s(y[i:]) vx.MulAdd(va, vy).Store(dst[i:]) } // den Rest mit einem partiellen Laden/Speichern behandeln, ohne skalare Bereinigungsschleife if i < len(x) { vx, _ := simd.LoadFloat32sPart(x[i:]) vy, _ := simd.LoadFloat32sPart(y[i:]) vx.MulAdd(va, vy).StorePart(dst[i:]) } } ``` ```bash $ GOEXPERIMENT=simd go1.27rc3 run ./simddemo vector bits: 128 emulated: false [4 7 10 13 16 19 22 25 28 31] ``` Die entscheidende Designentscheidung: **Die Vektorbreite ist nirgends fest kodiert.** Sie fragen `va.Len()` zur Laufzeit ab. `VectorBitSize()` liefert die tatsächliche Breite, `Emulated()` sagt Ihnen, ob Sie echte Hardware oder eine höfliche Software-Imitation bekommen. Mein Mac meldete 128-Bit-NEON, eine AVX-512-Maschine meldet mehr, und eine Maschine ohne Vektorunterstützung meldet Emulation, und der Code läuft trotzdem. `LoadFloat32sPart` und `StorePart` verdienen besondere Erwähnung. Der lästigste Teil handgeschriebener SIMD-Programmierung ist immer das unregelmäßige Ende eines Arrays, und das wird hier ohne separate skalare Schleife behandelt. Immer noch experimentell, die API ist noch instabil, nicht in der Produktion einsetzen. Aber dass dies Go-Code ist und nicht Assembler oder cgo, ist wirklich eine große Sache. ### 3.5. hash/maphash.Hasher Ein neues Interface, das den Vertrag zwischen einem Werttyp und hashbasierten Containern beschreibt: ```go type Hasher[T any] interface { Hash(*Hash, T) Equal(x, y T) bool } ``` Warum? Die eingebaute Map von Go akzeptiert nur `comparable`-Schlüssel. Sie können nicht nach einem Slice schlüsseln. Sie können nicht „gleich, unabhängig von Groß- und Kleinschreibung" definieren. `Hasher` löst beides gleichzeitig: ```go type CaseInsensitive struct{} func (CaseInsensitive) Hash(h *maphash.Hash, s string) { h.WriteString(strings.ToLower(s)) } func (CaseInsensitive) Equal(x, y string) bool { return strings.ToLower(x) == strings.ToLower(y) } var seed = maphash.MakeSeed() func hashOf[T any](hr maphash.Hasher[T], v T) uint64 { var h maphash.Hash h.SetSeed(seed) // derselbe Seed, sonst bedeutet das alles nichts hr.Hash(&h, v) return h.Sum64() } fmt.Println(hashOf(CaseInsensitive{}, "Go") == hashOf(CaseInsensitive{}, "GO")) // true ``` Für gewöhnliche `==`-Semantik gibt es `ComparableHasher[T]`: ```go hashOf(maphash.ComparableHasher[int]{}, 42) ``` Der Haken: **`Hasher` ist ein Interface, keine Datenstruktur.** Es gibt noch keine Standard-Hashtabelle und keinen Bloom-Filter, der es verwendet. Das ist die Grundlage für ein künftiges Container-Paket. Heute verwenden Sie es, wenn Sie eine eigene Struktur bauen, oder Sie konsumieren eine bestehende Implementierung wie `go/types.Hasher` (damit können Sie `types.Type` als Map-Schlüssel verwenden, unter Berücksichtigung von `Identical`). Die Seed-Verwaltung liegt bei Ihnen. Hätte `hashOf` oben bei jedem Aufruf einen neuen Seed erzeugt, hätten identische Werte unterschiedliche Hashes erhalten, und das Beispiel hätte `false` ausgegeben. Genau dieser Fehler passierte mir beim ersten Versuch. Ein Seed pro Container. (Der Seed ist zufällig, um Hash-Flooding-DoS-Angriffe zu verhindern, deshalb ist er keine einfache Konstante.) ### 3.6. httptest.NewTestServer + synctest.Sleep: Der Schlafwandler-Treffer Wenn Sie aus diesem Release nur eine Sache übernehmen, dann diese. `testing/synctest` wurde in Go 1.25 allgemein verfügbar und lieferte eine gefälschte Uhr zum Testen nebenläufigen Codes. Sobald Ihr Test jedoch ein echtes Netzwerk berührte, brach die Illusion zusammen. `httptest.NewTestServer` in Go 1.27 verwendet ein **speicherinternes, simuliertes Netzwerk**, sodass die Blase intakt bleibt. Und `synctest.Sleep` (= `time.Sleep` + `synctest.Wait`) rundet das Ganze ab. Hier ein Test für Retry mit exponentiellem Backoff: ```go func TestRetryWithBackoff(t *testing.T) { synctest.Test(t, func(t *testing.T) { var hits int srv := httptest.NewTestServer(t, http.HandlerFunc( func(w http.ResponseWriter, r *http.Request) { hits++ if hits < 3 { w.WriteHeader(http.StatusServiceUnavailable) return } io.WriteString(w, "ok") })) client := srv.Client() start := time.Now() var body string for attempt := range 5 { resp, err := client.Get(srv.URL) if err != nil { t.Fatal(err) } b, _ := io.ReadAll(resp.Body) resp.Body.Close() if resp.StatusCode == http.StatusOK { body = string(b) break } synctest.Sleep(time.Duration(1<= 0; i-- { _ = s[i] } } func Spawn(wg *sync.WaitGroup) { wg.Add(1) go func() { defer wg.Done() }() } ``` ```bash $ go1.27rc3 fix -diff ./fixdemo ``` ```diff import ( + "slices" "sync" "sync/atomic" ) func New() User { - return User{Base: Base{ID: 1}, Name: "gopher"} + return User{ID: 1, Name: "gopher"} } -var counter int64 +var counter atomic.Int64 -func Incr() { atomic.AddInt64(&counter, 1) } +func Incr() { counter.Add(1) } func Reverse(s []string) { - for i := len(s) - 1; i >= 0; i-- { - _ = s[i] + for _, v := range slices.Backward(s) { + _ = v } } func Spawn(wg *sync.WaitGroup) { - wg.Add(1) - go func() { - defer wg.Done() - }() + wg.Go(func() { + }) } ``` Vier Modernizer haben bei einer kleinen Datei angeschlagen: - `embedlit`: schreibt eingebettete Literale mit der neuen Syntax aus §1.2 um - `atomictypes`: `atomic.AddInt64(&x, 1)` wird zu `atomic.Int64.Add(1)`, was nicht-atomare Zugriffe unmöglich macht und nebenbei 32-Bit-Alignment-Fehler behebt, von denen Sie nichts wussten - `slicesbackward`: Rückwärtsschleifen werden zu `slices.Backward` - `waitgroupgo`: das Ritual `Add`/`go`/`Done` wird zu `wg.Go` (umbenannt von `waitgroup` aus 1.26, um Mehrdeutigkeiten zu vermeiden) `go tool fix help` listet alle 26 auf; `go tool fix help ` erklärt jeweils einen. Außerdem wurde `fmtappendf` „aus stilistischen Gründen" entfernt, was eine wunderbar diplomatische Beschreibung dessen ist, was auch immer in diesem Issue-Thread passiert ist. `go fix ./...` auf eine alte Codebasis laufen zu lassen, ist ein wirklich befriedigender Nachmittag. Lesen Sie den Diff natürlich vorher. ### 4.2. go test führt standardmäßig stdversion aus Dies ist die Änderung, die Ihren Tag am wahrscheinlichsten unterbricht. `go test` führt nun standardmäßig die Vet-Prüfung `stdversion` aus, die Symbole der Standardbibliothek markiert, die neuer sind, als die `go`-Direktive Ihrer `go.mod` erlaubt: ```go // go.mod sagt: go 1.24 package sv import "strings" func Ext(name string) string { _, ext, _ := strings.CutLast(name, ".") // CutLast ist ein Symbol aus 1.27 return ext } ``` ``` $ go1.27rc3 test ./... # sv ./x.go:6:23: strings.CutLast requires go1.27 or later (module is go1.24) FAIL sv [build failed] ``` Das beseitigt den klassischen Fehlerfall, dass alles auf Ihrem Rechner (neuester Toolchain) funktioniert und in der CI oder in der älteren Umgebung eines Nutzers explodiert. Wenn Sie Bibliotheken mit einer konservativen `go`-Direktive veröffentlichen, ist das ein Geschenk. ### 4.3. go test -json erhält OutputType Zeilen mit `"Action":"output"` enthalten nun ein optionales Feld `"OutputType"`: `"error"`, `"error-continue"` oder `"frame"`. ``` 'frame' '=== RUN TestFail\n' None ' x_test.go:6: hello\n' 'error' ' x_test.go:7: boom\n' 'frame' '--- FAIL: TestFail (0.00s)\n' 'frame' 'FAIL\n' ``` Die Ausgabe von `t.Log` (ohne Feld), die Ausgabe von `t.Error` (`error`) und vom Framework erzeugte Zeilen (`frame`) lassen sich nun unterscheiden. Wer einen regulären Ausdruck geschrieben hat, um herauszufinden, welche Zeilen der Testausgabe „echt" sind, kann diesen jetzt löschen. ### 4.4. Verbesserungen bei go doc **Syntax `package@version`.** Lesen Sie die Dokumentation einer bestimmten Version, ohne sie zu Ihrem Modul hinzuzufügen: ```bash $ go1.27rc3 doc golang.org/x/sync/errgroup@v0.10.0 package errgroup // import "golang.org/x/sync/errgroup" ... ``` Praktisch, um vor einem Upgrade zu prüfen, was sich geändert hat. **`-ex` und Ausgabe des Beispielquelltexts:** ```bash $ go1.27rc3 doc -ex strings | grep Example func ExampleClone() func ExampleCompare() func ExampleContains() func ExampleCut() func ExampleCutPrefix() ... $ go1.27rc3 doc strings.ExampleCut package main import ( "fmt" "strings" ) func main() { show := func(s, sep string) { before, after, found := strings.Cut(s, sep) fmt.Printf("Cut(%q, %q) = %q, %q, %v\n", s, sep, before, after, found) } show("Gopher", "Go") ... } Output: Cut("Gopher", "Go") = "", "pher", true ``` Beispielquelltext _und_ erwartete Ausgabe, im Terminal, ohne einen Browser-Tab zu öffnen, der nächsten Donnerstag immer noch offen sein wird. ### 4.5. go mod tidy räumt Ihre require-Blöcke auf Für Module mit `go 1.27` oder neuer führt `go mod tidy` verstreute `require`-Blöcke in höchstens zwei zusammen (direkte und indirekte), wobei angehängte Kommentare erhalten bleiben. ```go // Vorher module tidydemo go 1.27 require golang.org/x/sync v0.10.0 // Netzwerk require golang.org/x/net v0.33.0 require ( golang.org/x/sys v0.28.0 // indirect ) require golang.org/x/text v0.21.0 // indirect ``` ```go // Nachher: go mod tidy module tidydemo go 1.27 require ( // Netzwerk golang.org/x/net v0.33.0 golang.org/x/sync v0.10.0 ) ``` Beachten Sie, dass der Kommentar `// Netzwerk` erhalten geblieben ist. Das räumt vor allem nach der **Auflösung von Git-Merge-Konflikten** auf, denn dort entstehen die verirrten `require`-Blöcke. Wenn in Ihrem Team mehr als drei Personen Abhängigkeiten hinzufügen, werden Ihre `go.mod`-Konflikte merklich leiser werden. ### 4.6. Sonstiges - **Unterstützung für `bzr` entfernt.** Falls Sie das betrifft, würde ich die Geschichte dahinter wirklich gern hören. - **`go tool trace -http` bindet an localhost**, wenn nur ein Port angegeben wird. `-http=:6060` lauscht nicht mehr auf allen Schnittstellen. Verwenden Sie `-http=0.0.0.0:6060`, wenn Sie das so meinen. Das entspricht nun `go tool pprof` und verhindert gelegentliche versehentlich öffentliche Profiler. - **Antwortdateien (`@file`)** werden von `compile`, `link`, `asm`, `cgo`, `cover` und `pack` im GCC-kompatiblen Format unterstützt. Für Build-Systeme, die Kommandozeilenlängenlimits sprengen, hallo Bazel. ## 5. Compiler, Linker, Plattformen **Compiler.** Relative Dateinamen in `//line`-Direktiven werden nun relativ zum Verzeichnis der enthaltenden Datei aufgelöst, passend zu `go/scanner`. Relevant, wenn Sie Code-Generatoren schreiben. Die Symbolnamen von Funktionsliteralen (Closures) sind ebenfalls einfacher geworden: derselbe Name unabhängig von Inlining, und mehrere Instanzen desselben Literals dürfen sich im Binary Code teilen. Keine funktionale Änderung, _außer_: Code, der Funktionsidentität über `reflect.Value.Pointer` vergleicht, wird „gleich" häufiger feststellen als bisher. Dieser Vergleich war nie gültig, aber wenn Sie ihn verwenden, beginnt er jetzt lauter zu lügen. **Linker.** Die neuen Optionen `-macos` und `-macsdk` setzen die OS- und SDK-Versionen im Ladebefehl `LC_BUILD_VERSION` von macOS. **Plattformen.** - **Darwin erfordert nun macOS 13 Ventura oder neuer**, wie in 1.26 angekündigt. Prüfen Sie Ihre CI-Runner. - **PowerPC (`GOOS=linux GOARCH=ppc64`) wurde auf das ELFv2-ABI umgestellt.** Erfordert Linux-Kernel 3.13+ (RHEL7 hat es auf 3.10 zurückportiert). cgo, PIE und externes Linking werden nun unterstützt. Wenn Sie cgo verwenden, aber ein statisches reines Go-Binary brauchen, setzen Sie `CGO_ENABLED=0`. ## 6. Upgrade-Checkliste Go 1.27 nimmt Kompatibilität ernst, prüfen Sie dennoch diese Punkte, bevor Sie die Version anheben: - [ ] **Golden-File-Tests für komprimierte Ausgaben.** `compress/flate` hat seine Encoder geändert; gzip-, zip- und png-Bytes können sich unterscheiden. - [ ] **Tests, die JSON-Fehlermeldungen als Strings vergleichen.** Das Verhalten ist identisch; **der Fehlertext ist es nicht.** - [ ] **Entfernte GODEBUGs in `go.mod`.** `asynctimerchan`, `gotypesalias`, `tlsrsakex`, `tls3des`, `tls10server`, `tlsunsafeekm`, `x509keypairleaf`: Diese lassen den Build nur fehlschlagen, wenn sie auf ihre _alten_ Werte gesetzt sind. - [ ] **Verstöße gegen `stdversion`.** `go test` erkennt diese nun. Führen Sie es früh aus, wenn Sie eine Bibliothek mit einer konservativen `go`-Direktive pflegen. - [ ] **CI-Runner mit macOS 12 oder älter.** Die Unterstützung ist entfallen. - [ ] **Tests, die auf Symbolnamen von Funktionsliteralen prüfen**, sowie **Funktionsvergleiche mit `reflect.Value.Pointer`.** - [ ] **`Transport.MaxIdleConns = 0`** oder ein `Client` pro Request. In Kombination mit dem automatischen Leeren von Response-Bodies kann dies langsamer werden. ## Abschließende Gedanken Go 1.27 ist das Release, bei dem viel aufgeschobene Wartungsarbeit auf einmal fällig wurde. Generische Methoden waren das fehlende Stück der Generics-Arbeit aus 1.18. Feldselektoren in Struct-Literalen schlossen ein elf Jahre altes Issue. `encoding/json/v2` war zwei Jahre Diskussion über einen Vorschlag. Und `uuid` füllte eine Lücke, die praktisch jedes Go-Projekt seit einem Jahrzehnt mit derselben Drittanbieter-Abhängigkeit gestopft hat. Wenn Sie eine Prioritätenreihenfolge wollen, um tatsächlich Nutzen aus diesem Release zu ziehen: 1. **`httptest.NewTestServer` + `synctest.Sleep`**: Zeitabhängige HTTP-Tests werden schnell und deterministisch. Das beste Verhältnis von Aufwand zu Ertrag im gesamten Release. 2. **Das Goroutine-Leak-Profil**: Stellen Sie in Staging einen Endpunkt bereit und machen Sie sich auf Demut gefasst. 3. **Goroutine-Labels in Tracebacks**: Drei Zeilen `pprof.Do` an Ihrem Request-Einstiegspunkt machen Ihren nächsten Stack-Dump um 3 Uhr nachts lesbar. 4. **`go fix ./...`**: Lassen Sie das Werkzeug die Modernisierung übernehmen. 5. **`encoding/json/v2`**: Keine Eile. Übernehmen Sie es Option für Option. Holen Sie sich `go1.27rc3` und führen Sie Ihre Testsuite jetzt damit aus. Alles auf dieser Checkliste ist an einem Dienstagnachmittag deutlich angenehmer zu entdecken als während eines Incidents. **Referenzen** - [Go 1.27 Release Notes](https://go.dev/doc/go1.27) - [The Go Programming Language Specification](https://go.dev/ref/spec) - [proposal: encoding/json/v2 (#71497)](https://go.dev/issue/71497) - [proposal: portable SIMD (#78902)](https://go.dev/issue/78902) - [proposal: hash/maphash.Hasher (#70471)](https://go.dev/issue/70471)