Go 1.27, avagy hogyan tanultam meg nem aggódni és szeretni a generikus metódusokat

Overview of Go 1.27

A Go 1.27 2026 augusztusában jelenik meg, és ezúttal a nyelv maga is megváltozott. Nem az a fajta változás, hogy "új függvényt adtunk a slices csomaghoz", hanem valódi változás. Megérkeztek a generikus metódusok. Lezárult egy tizenegy éves issue. Az encoding/json csomagot pedig egy új motor váltotta fel, miközben a gép a levegőben volt.

Az alábbi példák mindegyikét go1.27rc3 (darwin/arm64) alatt futtattam. Minden kimeneti blokk valódi kimenet, átmásolva, a hibaüzenetekkel együtt. Ha valami furcsának tűnik, az azért van, mert a fordító valóban ezt írta.

1go install golang.org/dl/go1.27rc3@latest
2go1.27rc3 download

1. A nyelv megváltozott (igen, tényleg)

1.1. Generikus metódusok

A Go 1.18 óta vannak generikus típusaink, és a Go 1.18 óta van "A Beszélgetés" is. Nagyjából így zajlik:

"Csak írok egy Map metódust a saját slice típusomra…"
method must have no type parameters
"…rendben. Akkor marad a csomagszintű függvény."

A metódusok korábban csak a receiver által deklarált típusparamétereket használhattak. Saját metódus nem vezethetett be újakat. Így minden generikus átalakítás a csomagszintre szorult, ahol további tizenhét, valamilyen MapSlice változatra keresztelt, lebegő segédfüggvény mellé került.

A Go 1.27 ezt javítja:

 1type List[E any] []E
 2
 3// F a metódus által deklarált típusparaméter
 4func (l List[E]) Apply[F any](f func(E) F) List[F] {
 5	r := make(List[F], len(l))
 6	for i, x := range l {
 7		r[i] = f(x)
 8	}
 9	return r
10}
11
12func main() {
13	l := List[int]{1, 2, 3}
14	fmt.Println(l.Apply(func(i int) string { return fmt.Sprint(i * 10) }))
15	// [10 20 30]
16}

A receivernek sem kell generikusnak lennie. Egy egyszerű struct is kaphat generikus metódust:

1type Bag struct{ items []any }
2
3func (b *Bag) Add[T any](v T) { b.items = append(b.items, v) }

Mielőtt azonban az egész kódbázist még ma délután átírnád, van két korlátozás, és ezek fontosabbak, mint amilyennek látszanak:

Interfész metódusok nem deklarálhatnak típusparamétereket.
Generikus metódusok nem valósíthatnak meg interfész metódusokat.

Ez utóbbi az, amelyik meg fog harapni:

1type Adder interface{ Add(int) int }
2
3type G struct{}
4
5func (G) Add[T any](v T) T { return v }
6
7var _ Adder = G{}

1cannot use G{} (value of struct type G) as Adder value in variable declaration:
2	G does not implement Adder (wrong type for method Add)
3		have Add[T any](T) T
4		want Add(int) int

Tehát a generikus metódusok és a dinamikus diszpécselés nem férnek össze. Ez nem a Go csapat fukarságából fakad, hanem abból, hogy egy generikus metódusnak végtelen sok példányosítása lehet, az interfész metódustáblának viszont végesnek és fordítási időben ismertnek kell lennie. Egy végtelen dolgot nem lehet véges táblába tenni. A világegyetem nemet mondott.

Gyakorlati tanulság: a generikus metódusok konkrét típusokhoz, segédfüggvény jellegű API-khoz valók. Ami interfész mögé kell rejtőzzön, az továbbra is a régi megközelítést igényli.

A standard könyvtár már ki is használta ezt. A math/rand/v2 Rand típusa kapott egy generikus metódust:

1func (r *Rand) N[Int intType](n Int) Int

1r := rand.New(rand.NewPCG(1, 2))
2fmt.Println(r.N(int32(100)))     // 76
3fmt.Println(r.N(time.Second))    // 616.436223ms

Korábban csak a csomagszintű rand.N volt generikus, ami azt jelentette, hogy a globális forrást lehetett használni. Most a saját, magvetett *Rand példányod is ugyanazt a kényelmet kapja. Kicsi dolog. Szép dolog.

1.2. Struct literál mezőválasztók, avagy: a #9859-es issue végre lezárul

A beágyazás lehetővé teszi a u.ID használatát. A beágyazás nem teszi lehetővé a User{ID: 1} használatát. Helyette a User{Base: Base{ID: 1}} írandó, ami Go módja annak, hogy megkérdezze, tényleg ezt akartad-e.

A 9859-es issue 2015-ben született. Most lezárták. Valahol egy gopher, aki azóta kétszer váltott szakmát, most kap egy GitHub-értesítést.

 1type Object struct{ name, color string }
 2type Point3D struct {
 3	Object
 4	x, y, z float64
 5}
 6type Line struct {
 7	Object
 8	p, q Point3D
 9}
10
11// Go 1.27: a felemelt mezőt közvetlenül használjuk
12line := Line{name: "diagonal", q: Point3D{y: -4, z: 12.3}}

A name nem a Line mezője. A beágyazott Object mezője. Korábban ezt kellett írnod: Line{Object: Object{name: "diagonal"}, ...}.

Most jöjjenek az apró betűs részek, amelyeket úgy ellenőriztem, hogy tényleg megpróbáltam mindezt lefordítani.

(a) A kulcs továbbra is egyszerű azonosító. Tetszőleges szelektorutat nem írhatsz.

1_ = Line{Object.name: "x"}   // invalid field name Object.name in struct literal
2_ = Line{p.x: 1}             // invalid field name p.x in struct literal

Tehát a funkció nem azt jelenti, hogy "a kulcsok mostantól úgy működnek, mint a mezőelérés". Pontosan azt jelenti, hogy a implicit módon felemelt mezőnevek megengedettek. Ez valamivel szűkebb, mint amit a címsor sugall.

(b) Nem adhatsz meg egyszerre beágyazott mezőt és egy abból felemelt mezőt.

1obj := Object{"edge", "black"}
2_ = Line{Object: obj, name: "diagonal"}
3// cannot specify promoted field name and enclosing embedded field Object

Ésszerű. Ugyanarra a memóriára két ellentmondó dolgot mondtál, és a fordító nem vállalta a találgatást.

(c) A mutató típusú beágyazás nincs támogatva.

1type PtrEmbed struct {
2	*Object
3	z int
4}
5
6_ = PtrEmbed{name: "x"}
7// invalid implicit pointer indirection to reach name

Ahhoz, hogy egy mutatót követhess, kell egy mutató, a literál létrehozásakor viszont még nincs. Ez is igazságos.

Jó hír: a go fix átírja helyetted a régi literáljaidat. Erről később bővebben.

1.3. A függvénytípus-következtetés kevésbé önkényes lett

A generikus függvények típuskövetkeztetése korábban egyes helyeken működött, másokon nem, és nem volt felismerhető elv, amely eldöntötte volna, melyik eset melyik. Változóba történő értékadásnál működött? Igen. Ugyanazt a függvényt egy struct mezőbe tenni? Fordítóhiba, kérlek, írd úgy, mint 2022-ben: double[int].

A Go 1.27 minden olyan kontextusban működteti a következtetést, ahol a céltípus egyértelműen ismert:

 1func double[T ~int | ~float64](v T) T { return v * 2 }
 2
 3type S struct{ f func(int) int }
 4type A [1]func(int) int
 5
 6func main() {
 7	s := S{f: double}          // 1.26: double[int] kellett
 8	a := A{double}             // 1.26: double[int] kellett
 9
10	c := make(chan func(int) int, 1)
11	c <- double                // 1.26: double[int] kellett
12
13	var fn func(float64) float64 = double  // ez mindig is működött
14
15	fmt.Println(s.f(21), a[0](5), (<-c)(7), fn(1.5))
16	// 42 10 14 3
17}

Egyetlen double, amelyet három helyen func(int) int, a negyedik helyen pedig func(float64) float64 típusra példányosít, kizárólag a kontextusból. Ha függvényértékekkel teli opciós struktúrákat vagy handler táblákat írsz, a kódbázisodból a sok [T] zaj hamarosan eltűnik.

2. Futtatókörnyezet: ingyenes teljesítmény és szivárgásdetektor

2.1. Méretspecifikus allokáció

A fordító mostantól kis objektumok esetén méretspecifikus allokációs rutinok hívását generálja. A kiadási jegyzetek legfeljebb 30%-os gyorsulást ígérnek a 80 bájt alatti allokációknál, és nagyjából 1%-ot az allokációban gazdag programok egészére nézve.

Mérés nélkül nem hiszek a kiadási jegyzeteknek, ezért:

 1type small struct{ a, b, c, d int }
 2
 3var sink any
 4
 5func BenchmarkAlloc(b *testing.B) {
 6	for b.Loop() {
 7		sink = &small{}
 8	}
 9}
10
11func BenchmarkSlice(b *testing.B) {
12	for b.Loop() {
13		sink = make([]byte, 48)
14	}
15}

1# alapértelmezett (méretspecifikus malloc bekapcsolva)
2BenchmarkAlloc-12     3000000     5.358 ns/op
3BenchmarkSlice-12     3000000    13.58 ns/op
4
5# GOEXPERIMENT=nosizespecializedmalloc
6BenchmarkAlloc-12     3000000     8.722 ns/op
7BenchmarkSlice-12     3000000    20.81 ns/op
8

Apple Silicon-on, egy olyan mikrobenchmarkban, amely kizárólag allokál, 30–35%-kal gyorsabb. Vagyis ez a legjobb eset, laboratóriumi körülmények között, olyan benchmarkkal, amelyet azért terveztek, hogy a szám jól nézzen ki. Valódi programban a GC és a tényleges munka a legtöbbjét elnyeli. Az ~1%-os állítás az őszinte.

Az ára a bináris mérete. Hello World:

12413202 bytes  (alapértelmezett)
22361826 bytes  (nosizespecializedmalloc)

Nagyjából 50 KB, fix, a programod méretétől függetlenül. A GOEXPERIMENT=nosizespecializedmalloc beállítással kikapcsolható, de ez a kiskapu a Go 1.28-ban eltávolításra van ütemezve, ezért inkább hibajelentés-megkerülőként kezeld, ne életformaként.

2.2. A goroutine-szivárgási profil már valóban működik

A Go 1.26-ban kísérleti volt, az 1.27-ben általánosan elérhető. A goroutineleakprofile GOEXPERIMENT megszűnt; egyszerűen működik.

 1func leak() {
 2	ch := make(chan int) // soha senki nem küld ide. soha.
 3	go func() {
 4		<-ch
 5	}()
 6}
 7
 8func main() {
 9	for range 3 {
10		leak()
11	}
12	runtime.GC()
13	runtime.GC()
14	pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
15}

1goroutineleak profile: total 3
23 @ 0x104de3f18 0x104d7f0b0 0x104d7ec34 0x104e374f4 0x104dea024
3#	0x104e374f3	main.leak.func1+0x23	/tmp/go127/leak/main.go:12

Három goroutine, végleg elakadva, fájllal és sorszámmal, amely pontosan megmutatja, hol hoztad létre őket.

Az ezt megalapozó trükk valóban okos: újrahasznosítja a szemétgyűjtő elérhetőség-elemzését. Ha a G goroutine a P primitívre vár, a P pedig egyetlen futtatható goroutine-ból sem érhető el (és abból sem, amit ezek a goroutine-ok felébreszthetnek), akkor P-hez soha többé nem nyúl senki, így G soha nem ébred fel. Ez nem heurisztika, hanem bizonyítás.

Ugyanez a tervezés adja a korlátját is: ha a csatorna vagy a mutex egy globális változón, vagy egy még futó goroutine lokális változóján keresztül elérhető, a GC továbbra is látja, így a futtatókörnyezet semmit sem tud megállapítani. Figyelj arra, hogy még a fenti játékpélda is két runtime.GC() hívást igényel a jelentéshez. Nem fog mindent elkapni.

Viszont elkapja a klasszikus esetet, amikor "elfelejtettem megszakítani a contextet, és a worker goroutine örökké él". Ez a legtöbb szivárgás legtöbbször.

Ha importálod a net/http/pprof csomagot, a profil a /debug/pprof/goroutineleak címen is elérhető. Kösd be staging környezetbe, hetente ellenőrizd, és csendben borzadj el.

Ezt a munkát Vlad Saioc az Ubertől járult hozzá, akinek jár egy ital, amit ő választ.

2.3. A visszakövetések mostantól megmondják, melyik kérés hált el

Azoknál a moduloknál, amelyek Go 1.27-et vagy újabbat deklarálnak, a visszakövetés fejléc sorai mostantól tartalmazzák a runtime/pprof goroutine-címkéket.

 1func handle(ctx context.Context) {
 2	var wg sync.WaitGroup
 3	wg.Go(func() {
 4		buf := make([]byte, 4<<10)
 5		os.Stdout.Write(buf[:runtime.Stack(buf, true)])
 6	})
 7	wg.Wait()
 8}
 9
10func main() {
11	labels := pprof.Labels("request", "GET /orders/42", "tenant", "acme")
12	pprof.Do(context.Background(), labels, handle)
13}

1goroutine 3 [running] {request: "GET /orders/42", tenant: acme}:
2main.handle.func1()
3	/tmp/go127/tblabel/main.go:15 +0x40
4sync.(*WaitGroup).Go.func1()
5	...
6goroutine 1 [sync.WaitGroup.Wait] {request: "GET /orders/42", tenant: acme}:
7...

A lényeges részlet: a címkéket a gyermek goroutine-ok örökölik. A 3-as goroutine soha nem állított be címkét. A szülőjétől kapta.

Így legközelebb, amikor az éles rendszer holtpontra jut, és valaki SIGQUIT-et küld a folyamatnak, nem 4000 egyformának látszó goroutine-t fogsz kapni, hanem 4000 olyan goroutine-t, amelyeken rajta van, melyik kérést és melyik tenantot szolgálják. Három sor pprof.Do a kérés-belépési pontodon ezt adja cserébe.

Mivel a címkék olyasmit is tartalmazhatnak, amit nem szeretnél stderr-re kiírni, a GODEBUG=tracebacklabels=0 kikapcsolja a funkciót, és ez a kikapcsolási lehetőség kifejezetten örökre megmarad.

2.4. Az asynctimerchan végleg megszűnt

A Go 1.23 szinkronizálta (nem pufferelt) az időzítő csatornákat, és az asynctimerchan=1 beállítást kínálta a régi viselkedés visszakapcsolására. Az 1.27-ben ez a beállítás véglegesen eltávolításra került. A time csomag csatornái szinkronok, teljesen és alkudozás nélkül.

Érdekes a mellé vezetett szabály. Egy eltávolított GODEBUG, amely a go.mod fájlodban maradt, nem töri el automatikusan a buildet. Csak akkor, ha a régi értékre van állítva:

1# a go.mod tartalmazza: godebug asynctimerchan=1
2go: error loading go.mod:
3go.mod:5: removed GODEBUG "asynctimerchan" set to old value "1" (https://go.dev/doc/godebug#go-127)
4
5# a go.mod tartalmazza: godebug asynctimerchan=0
6(builds fine)

Ez azt jelenti, hogy csak azok kapnak szidást, akik ténylegesen az eltávolított viselkedésre támaszkodtak. Mindenki más, aki a későbbi alapértelmezettre állította és elfelejtette, megtarthatja a figyelmen kívül hagyás kényelmét. Ez az API-régészet elgondolkodtató darabja.

3. Standard könyvtár

3.1. encoding/json/v2: a motort menet közben cserélték le

Ez a nagy. Több mint két év javaslatvitája végre célba ért.

Most három csomag van, és a felosztás megértése a csata nagy része:

Csomag	Feladat
`encoding/json`	Az ismert v1 API. Viselkedése 100%-ban változatlan. Mostantól a v2-re épül
`encoding/json/v2`	Szemantikai feldolgozás. Go értékek ↔ JSON
`encoding/json/jsontext`	Szintaktikai feldolgozás. A JSON tokenfolyamként

A főcím az, hogy az encoding/json teljesen más implementáción alapuló újjáépítést kapott, és azonosan viselkedik. Így:

1// Go 1.27 encoding/json.Unmarshal, rövidítve
2func Unmarshal(data []byte, v any) error {
3	return jsonv2.Unmarshal(data, v, DefaultOptionsV1())
4}

Minden örökölt v1-es sajátosság opcióként lett kódolva, a DefaultOptionsV1() csomagba került, és a v1 API mindig alkalmazza ezt a csomagot. Ez azt jelenti, hogy ez ugyanúgy viselkedik az 1.26-ban és az 1.27-ben:

1var m map[string]int
2json.Unmarshal([]byte(`{"a":1,"a":2}`), &m)  // <nil>, map[a:2]

Igen, a v1 továbbra is csendben elfogadja az ismétlődő kulcsokat, és az utolsót veszi figyelembe. Mindig is így csinálta. Ma is így csinálja. A kompatibilitás a rossz részekkel való kompatibilitást is jelenti.

A v2 ezzel szemben véleményt formál:

1var m map[string]int
2jsonv2.Unmarshal([]byte(`{"a":1,"a":2}`), &m)
3// jsontext: duplicate object member name "a"
4
5var s string
6jsonv2.Unmarshal([]byte("\"\xff\""), &s)
7// jsontext: invalid UTF-8 after offset 1

Az ismétlődő kulcsokat és az érvénytelen UTF-8-at elutasítja. Mindkettő valóban veszélyes, nem csak rendetlen: ha két parser nem ért egyet abban, melyik ismétlődő kulcs érvényes, biztonsági hibák keletkeznek. A CouchDB CVE-2017-12635 sebezhetősége pontosan ez volt: egy JSON törzs két roles kulccsal, ahol a validátor az egyiket, a tárolórétegy a másikat olvasta. Az elutasítás a helyes döntés.

Az opciók variadikusak:

 1type Config struct {
 2	Name    string   `json:"name"`
 3	Tags    []string `json:"tags,omitzero"`
 4	Timeout int      `json:"timeout,omitzero"`
 5}
 6
 7out, _ := jsonv2.Marshal(Config{Name: "api"})
 8// {"name":"api"}
 9
10// rendezett map kulcsok + behúzás
11out, _ = jsonv2.Marshal(map[string]int{"b": 2, "a": 1},
12	jsonv2.Deterministic(true), jsontext.WithIndent("  "))
13// {
14//   "a": 1,
15//   "b": 2
16// }
17
18// ismeretlen mezők elutasítása — korábban Decoder és DisallowUnknownFields() kellett hozzá
19var c Config
20err := jsonv2.Unmarshal([]byte(`{"name":"api","nope":1}`), &c,
21	jsonv2.RejectUnknownMembers(true))
22// json: cannot unmarshal JSON string into Go main.Config:
23//   unknown object member name "nope"

A Deterministic, MatchCaseInsensitiveNames, StringifyNumbers, FormatNilSliceAsNull, OmitZeroStructFields: a legtöbb dolog, amelyet korábban külső könyvtárral vagy kézzel írt MarshalJSON metódussal oldottál meg, most már jelzők.

A migrációs történet pedig a legjobb rész. A későbbi opciók nyernek, így a v2 szigorúságát viselkedésenként, lépésenként vezetheted be:

1// a v1 szemantika megtartása, de az ismétlődő kulcsok elutasítása a v2 módjára
2jsonv2.Unmarshal(data, &v,
3	json.DefaultOptionsV1(),
4	jsontext.AllowDuplicateNames(false))
5// duplicate object member name

Nem kell egy 200 ezer soros kódbázist v2-re portolnod ahhoz, hogy abbahagyd az ismétlődő kulcsok elfogadását. Egy opciót kell átállítanod. Nagy kódbázisoknál ez a reális út.

Teljesítmény: a marshalizálás nagyjából azonos szintű, az unmarshalizálás lényegesen gyorsabb. Ha valami elromlik, a GOEXPERIMENT=nojsonv2 visszaállítja a régi implementációt. Ez a kiskapu szintén előbb-utóbb megszűnik, ezért inkább nyiss issue-t, ahelyett, hogy beletörődnél.

A jsontext az alacsony szintű réteg: az Encoder/Decoder Token-ekként és Value-kként járja be a JSON-t, egy állapotgép tartja tisztességesen. Akkor nyúlj hozzá, ha streamelő transzformert vagy JSON-szűrőt írsz, és nem akarsz Go értékeket létrehozni.

3.2. Szabványos uuid csomag

Végre. RFC 9562, a standard könyvtárban, go get nélkül.

 1import "uuid"
 2
 3func main() {
 4	fmt.Println(uuid.NewV4())
 5	// b97aa695-da08-472c-af81-ff088129019f
 6
 7	// v7: az első 48 bit időbélyeg, így ezek mindig létrehozási sorrendben rendeződnek
 8	a, b := uuid.NewV7(), uuid.NewV7()
 9	fmt.Println(a.Compare(b) < 0) // true
10
11	u, err := uuid.Parse("urn:uuid:0198a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b")
12	fmt.Println(u, err)
13	// 0198a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b <nil>
14
15	fmt.Println(uuid.Nil(), uuid.Max())
16	// 00000000-0000-0000-0000-000000000000 ffffffff-ffff-ffff-ffff-ffffffffffff
17}

A teljes API: New, NewV4, NewV7, Nil, Max, Parse, MustParse, és egy típus: type UUID [16]byte. Ennyi. A teljes csomag dokumentációját el tudod olvasni, mire kihűl a kávéd.

Érdemes tudni a részleteket:

A UUID [16]byte, így a == működik, és közvetlenül kulcsként használható térképekben. Ugyanaz a tervezés, mint a google/uuid-nál.
A Nil és a Max függvények, nem változók. Mert egy csomagszintű var Nil UUID olyan, mint egy megtöltött pisztoly a saját lábadra irányítva, és valakinek előbb-utóbb rá fog írni.
A véletlen biteket kriptográfiailag biztonságos generátor adja.
Megvalósítja az encoding.TextMarshaler/TextUnmarshaler/TextAppender interfészeket, így közvetlenül beilleszthető JSON struktúrákba.
A NewV7 az, amelyet adatbázis-elsődleges kulcsokhoz akarsz. Az idő szerinti rendezés miatt a B-fa indexed nem fragmentálódik, amiben a v4 UUID-k hírhedten rosszak.

Mostantól törölhetsz egy függőséget. Ha v1/v3/v5 vagy bonyolultabb feldolgozási opciók kellenek, a külső könyvtáraknak továbbra is van feladatuk.

3.3. crypto/mldsa: kvantumbiztos aláírások, és hatalmasak

A Go 1.24 a crypto/mlkem csomaggal adott kvantumbiztos kulcscserét. A Go 1.27 hozza a másik felet: az ML-DSA aláírásokat, a FIPS 204 szabvány szerint.

 1sk, _ := mldsa.GenerateKey(mldsa.MLDSA65())
 2pk := sk.PublicKey()
 3
 4msg := []byte("release the gophers")
 5opts := &mldsa.Options{Context: "gosuda.org/blog"}
 6
 7sig, _ := sk.Sign(rand.Reader, msg, opts)
 8
 9fmt.Println("private key seed:", len(sk.Bytes()), "bytes")  // 32
10fmt.Println("public key:", len(pk.Bytes()), "bytes")        // 1952
11fmt.Println("signature:", len(sig), "bytes")                // 3309
12
13fmt.Println(mldsa.Verify(pk, msg, sig, opts))
14// <nil>
15fmt.Println(mldsa.Verify(pk, msg, sig, &mldsa.Options{Context: "other"}))
16// mldsa: invalid signature

Nézd meg ezeket a számokat. Egyetlen aláírás 3309 bájt. Az Ed25519 64. Ez 50-szeres növekedés, és a nyilvános kulcs is közel 2 KB. Ha ezekből pár darabot egy tanúsítványláncba teszel, a TLS-kézfogásodnak saját MTU-stratégia kell.

Ez a kvantumellenállás mai tényleges ára, és ezért nem vált át senki holnap mindenre. De most már a standard könyvtárban van, ami pontosan ott a helye, mielőtt szükséged lenne rá.

Az Options.Context a domain-szétválasztás: ugyanazzal a kulccsal különböző célokra írhatsz alá, mindegyikhez más contextet használva, és az egyik contextben készült aláírás nem ellenőrizhető egy másikban. A fenti példa pontosan ezt mutatja: ugyanaz a kulcs, ugyanaz az üzenet, más context, elutasítva.

A PrivateKey megvalósítja a crypto.Signer interfészt, így beilleszthető a meglévő interfészekbe. A crypto/x509 kezeli az ML-DSA kulcsokat és aláírásokat, a crypto/tls pedig támogatja az MLDSA44/MLDSA65/MLDSA87 aláírási sémákat a TLS 1.3-ban.

Van még egy SignDeterministic is, amely kihagyja a véletlenszerűséget: hasznos tesztekhez és reprodukálható buildekhez.

3.4. simd: vektorutasítások assembly nélkül

A Go 1.26 kísérleti jelleggel bevezette az architektúra-specifikus simd/archsimd csomagot. A Go 1.27 hozzáadja a simd csomagot, amely hordozható és vektorszélesség-független. Engedélyezés: GOEXPERIMENT=simd.

 1// dst = a*x + y
 2func axpy(dst, x, y []float32, a float32) {
 3	va := simd.BroadcastFloat32s(a)
 4	w := va.Len()
 5
 6	i := 0
 7	for ; i+w <= len(x); i += w {
 8		vx := simd.LoadFloat32s(x[i:])
 9		vy := simd.LoadFloat32s(y[i:])
10		vx.MulAdd(va, vy).Store(dst[i:])
11	}
12	// a farok kezelése részleges betöltéssel/tárolással — nincs skaláris takarító ciklus
13	if i < len(x) {
14		vx, _ := simd.LoadFloat32sPart(x[i:])
15		vy, _ := simd.LoadFloat32sPart(y[i:])
16		vx.MulAdd(va, vy).StorePart(dst[i:])
17	}
18}

1$ GOEXPERIMENT=simd go1.27rc3 run ./simddemo
2vector bits: 128 emulated: false
3[4 7 10 13 16 19 22 25 28 31]

A lényeges tervezési döntés: a vektorszélességet soha nincs kódba írva. Futásidőben kérdezed meg a va.Len()-től. A VectorBitSize() megmondja a tényleges szélességet, az Emulated() pedig azt, hogy valódi hardvert kaptál-e, vagy udvarias szoftveres utánzatot. A Macem 128 bites NEON-t jelzett; egy AVX-512-es gép többet; egy olyan gép, amelyen semmi nincs, emulációt jelez, és a kód attól még lefut.

Az LoadFloat32sPart/StorePart külön említést érdemel. A kézzel írt SIMD legbosszantóbb része mindig a tömb végén maradó töredék, és ez a függvény ezt külön skaláris ciklus nélkül kezeli.

Még mindig kísérleti, az API még instabil, ne tedd éles környezetbe. De az, hogy ez Go kód, és nem assembly vagy cgo, valóban nagy dolog.

3.5. hash/maphash.Hasher

Új interfész, amely az érték típus és a hash-alapú tárolók közötti szerződést írja le:

1type Hasher[T any] interface {
2	Hash(*Hash, T)
3	Equal(x, y T) bool
4}

Miért? A Go beépített map típusa csak comparable kulcsokat fogad el. Nem használhatsz slice-t kulcsként. Nem definiálhatsz "egyenlő kis- és nagybetű-érzéketlenül" összehasonlítást. A Hasher mindkét problémát egyszerre oldja meg:

 1type CaseInsensitive struct{}
 2
 3func (CaseInsensitive) Hash(h *maphash.Hash, s string) {
 4	h.WriteString(strings.ToLower(s))
 5}
 6func (CaseInsensitive) Equal(x, y string) bool {
 7	return strings.ToLower(x) == strings.ToLower(y)
 8}
 9
10var seed = maphash.MakeSeed()
11
12func hashOf[T any](hr maphash.Hasher[T], v T) uint64 {
13	var h maphash.Hash
14	h.SetSeed(seed)   // ugyanaz a seed, különben ennek az egésznek nincs értelme
15	hr.Hash(&h, v)
16	return h.Sum64()
17}
18
19fmt.Println(hashOf(CaseInsensitive{}, "Go") == hashOf(CaseInsensitive{}, "GO"))
20// true

Az egyszerű == szemantikához ott van a ComparableHasher[T]:

1hashOf(maphash.ComparableHasher[int]{}, 42)

A csapda: a Hasher interfész, nem adatstruktúra. Még nincs olyan standard hash-tábla vagy Bloom-szűrő, amely használná. Ez egy jövőbeli tárolócsomag alapozása. Ma akkor használnád, ha saját struktúrát építesz, vagy egy meglévő implementációt fogyasztasz, például a go/types.Hasher-t, amely lehetővé teszi, hogy a types.Type térkép kulcsként szerepeljen, az Identical szerint.

A seed kezelése a te felelősséged. Ha a fenti hashOf minden híváskor új seedet generálna, az azonos értékek különböző hash-t kapnának, és a példa false-t írna ki, ami pontosan az a hiba, amelyet az első próbálkozásomnál elkövettem. Egy seed tárolónként. (A seed véletlenszerű, hogy kivédje a hash-árasztásos DoS-támadásokat, ezért nem egyszerű konstans.)

3.6. httptest.NewTestServer + synctest.Sleep: a szundikáló ütés

Ha ebből a kiadásból csak egy dolgot használsz, legyen ez.

A testing/synctest a Go 1.25-ben érte el a stabil állapotot, és egy hamis órát adott a konkurens kód teszteléséhez. Csakhogy abban a pillanatban, amikor a tesztben valódi hálózathoz értél, az illúzió összeomlott. A Go 1.27 httptest.NewTestServer függvénye memóriabeli hamis hálózatot használ, így a buborék sértetlen marad. A synctest.Sleep (= time.Sleep + synctest.Wait) pedig teljessé teszi.

Itt egy teszt exponenciális visszalépéssel újrapróbálkozáshoz:

 1func TestRetryWithBackoff(t *testing.T) {
 2	synctest.Test(t, func(t *testing.T) {
 3		var hits int
 4		srv := httptest.NewTestServer(t, http.HandlerFunc(
 5			func(w http.ResponseWriter, r *http.Request) {
 6				hits++
 7				if hits < 3 {
 8					w.WriteHeader(http.StatusServiceUnavailable)
 9					return
10				}
11				io.WriteString(w, "ok")
12			}))
13
14		client := srv.Client()
15		start := time.Now()
16		var body string
17		for attempt := range 5 {
18			resp, err := client.Get(srv.URL)
19			if err != nil {
20				t.Fatal(err)
21			}
22			b, _ := io.ReadAll(resp.Body)
23			resp.Body.Close()
24			if resp.StatusCode == http.StatusOK {
25				body = string(b)
26				break
27			}
28			synctest.Sleep(time.Duration(1<<attempt) * time.Second)
29		}
30
31		if body != "ok" {
32			t.Fatalf("got %q", body)
33		}
34		// a visszalépésnek pontosan 1s + 2s = 3s kell legyen
35		if elapsed := time.Since(start); elapsed != 3*time.Second {
36			t.Fatalf("elapsed = %v, want 3s", elapsed)
37		}
38		t.Logf("hits=%d elapsed=%v", hits, time.Since(start))
39	})
40}

1=== RUN   TestRetryWithBackoff
2    x_test.go:48: hits=3 elapsed=3s
3--- PASS: TestRetryWithBackoff (0.00s)

Olvasd el kétszer. Három másodperc visszalépést szimulált egy valódi HTTP szerver ellen, és 0,00 másodperc alatt lefutott. Az állítás pedig elapsed == 3*time.Second, vagyis pontosan három másodperc, nem "legalább három másodperc, ütemező-ingadozással együtt". A hamis órák nem ingadoznak.

A synctest.Sleep egy konkrét okból létezik: ha a tesztben ugyanannyit alszol, mint a tesztelt kódban, nem lehet tudni, melyik ébred fel előbb. A synctest.Sleep alszik, majd addig vár, amíg a buborékban lévő többi goroutine maradandóan blokkolttá nem válik, így a rendszert akkor figyeled meg, amikor már megnyugodott.

Időtúllépések, újrapróbálkozások, áramkörmegszakítók, sebességkorlátozók: minden időfüggő HTTP-kliens teszted gyorssá és determinisztikussá válhat. Ha a tesztsorozatodat jelenleg time.Sleep(100 * time.Millisecond) és remény tartja össze, ez a kiút.

3.7. net/http változások, amelyek ténylegesen érintik az éles környezetet

Csendesek, de megjelennek a metrikáidban.

A HTTP/1 választörzsek zárásnál automatikusan kiürülnek. A el nem olvasott tartalom zárásnál kiürül (egy konzervatív határig), így a kapcsolat újra felhasználható. Ez azt jelenti, hogy végre törölheted ezt a varázsigét, amelyet mindenki 2016 óta ugyanarról a Stack Overflow válaszról másol:

1// már nincs szükség rá
2defer func() {
3	io.Copy(io.Discard, resp.Body)
4	resp.Body.Close()
5}()

A legtöbb programnál ez nem tesz semmit, vagy kis nyereség. Ha rosszabbá teszi, valószínűleg abba a kategóriába tartozol, amelyet a kiadási jegyzetek udvariasan leírnak: Transport.MaxIdleConns értéke 0, vagy kérésenként új Client, amely teljesen megkerüli az üresjárati kapcsolatok korlátját. A Transport.DisableKeepAlives = true elfedi a problémát, de a kiadási jegyzetek valódi tanácsa az, hogy "valószínűleg hasznos lenne mélyebben megnézni", ami Go-csapat nyelven azt jelenti: van nagyobb problémád is.

HTTP/2 kliens prioritás (RFC 9218). A szerver mostantól figyelembe veszi a kliens prioritási jelzéseit. Ha a régi körbeforgó ütemezést részesíted előnyben, állítsd a Server.DisableClientPriority = true értékre.

Server.MaxHeaderValueCount. Korlátozza, hány fejlécértéket fogad el a szerver, alapértelmezés szerint a DefaultMaxHeaderValueCount. Egy újabb ajtó záródott be azzal szemben, hogy "küldj tízezer fejlécet, és nézd meg, mi történik".

ALPN felhasználó által biztosított kapcsolatokon. Ha a net.Conn megvalósítja a ConnectionState() tls.ConnectionState metódust, a Transport és a Server elvégzi rajta a TLS ALPN egyeztetést, így a proxyn keresztül futó egyedi dialerek is tudnak HTTP/2-t egyeztetni.

3.8. Az apróságok, amelyek örömet okoznak

strings.CutLast / bytes.CutLast. A Cut az első elválasztónál vág. "Utolsó" változat nem volt, ezért mindenki kézzel írta meg a LastIndex-et és a szeletelést, és nagyjából az emberek 30%-a elsőre egy off-by-one hibát vétett.

1name, ext, ok := strings.CutLast("archive.tar.gz", ".")
2// archive.tar gz true

Kiválóan jó fájlkiterjesztésekhez és a host:port feldolgozásához, ahol az utolsó kettőspontot kell megtalálni, mert az IPv6-címek tele vannak velük.

math/big.Int.Divide. Osztás explicit kerekítési móddal, felváltva a "Quo vagy Div kell nekem?" pénzfeldobással:

1x, y := big.NewInt(-7), big.NewInt(2)
2
3new(big.Int).Divide(x, y, new(big.Int), big.Trunc)  // q=-3 r=-1
4new(big.Int).Divide(x, y, new(big.Int), big.Floor)  // q=-4 r=1
5new(big.Int).Divide(x, y, new(big.Int), big.Round)  // q=-4 r=1
6new(big.Int).Divide(x, y, new(big.Int), big.Ceil)   // q=-3 r=-1

Ha olyan területen dolgozol, ahol a kerekítési szabályt rendelet írja elő, ez neked szól.

url.URL.Clone és url.Values.Clone. Mély másolatok. A régi *u sekély másolat megosztotta a Userinfo mutatót, ami pontosan olyan hibához vezetett, amelynek megtalálása egy napba, javítása öt másodpercbe kerül.

1orig, _ := url.Parse("https://gosuda.org/blog?tag=go&tag=1.27")
2clone := orig.Clone()
3clone.Host = "example.com"
4fmt.Println(orig.Host, clone.Host)  // gosuda.org example.com

A net.UnixConn olvasó metódusai mostantól közvetlenül io.EOF-ot adnak vissza, ahelyett, hogy net.OpError-ba csomagolnák. Az err == io.EOF most működik, ahogy mindig is kellett volna.

database/sql.ConvertAssign és driver.RowsColumnScanner. Meghajtó-fejlesztőknek szóló funkciók. Az első feltárja azokat a típuskonverziókat, amelyeket a Rows.Scan végez; a második lehetővé teszi, hogy a meghajtók közvetlenül felhasználói célba olvassanak, átugorva egy köztes allokációt.

unicode 15 → 17. Két verzió egy ugrással. A karakterosztályozás és a normalizálás viselkedése finoman eltolódhat. Ha vannak erre épülő teszteid, rá fogsz jönni.

A compress/flate gyorsabb lett, és kimeneti bájtjai eltérhetnek a Go 1.26-tól. Ez továbbgyűrűzik az archive/zip, compress/gzip, compress/zlib és image/png csomagokra. Ha olyan golden-file teszteid vannak, amelyek a tömörített kimenet hash-ét ellenőrzik, azok el fognak törni, és ez nem regresszió lesz. Ellenőrizd ezt mielőtt frissítesz, nem az incidens-utólagos elemzés során.

4. Eszköztár

4.1. A go fix több modernizálót kapott

A go fix csendben kódmodernizáló eszközzé válik. A Go 1.27 hozzáadja az atomictypes, embedlit, slicesbackward és unsafefuncs modernizálókat. A -diff kapcsolóval előnézetet nézhetsz:

 1package fixdemo
 2
 3import (
 4	"sync"
 5	"sync/atomic"
 6)
 7
 8type Base struct{ ID int }
 9type User struct {
10	Base
11	Name string
12}
13
14func New() User {
15	return User{Base: Base{ID: 1}, Name: "gopher"}
16}
17
18var counter int64
19
20func Incr() { atomic.AddInt64(&counter, 1) }
21
22func Reverse(s []string) {
23	for i := len(s) - 1; i >= 0; i-- {
24		_ = s[i]
25	}
26}
27
28func Spawn(wg *sync.WaitGroup) {
29	wg.Add(1)
30	go func() {
31		defer wg.Done()
32	}()
33}

1$ go1.27rc3 fix -diff ./fixdemo

 1 import (
 2+	"slices"
 3 	"sync"
 4 	"sync/atomic"
 5 )
 6
 7 func New() User {
 8-	return User{Base: Base{ID: 1}, Name: "gopher"}
 9+	return User{ID: 1, Name: "gopher"}
10 }
11
12-var counter int64
13+var counter atomic.Int64
14
15-func Incr() { atomic.AddInt64(&counter, 1) }
16+func Incr() { counter.Add(1) }
17
18 func Reverse(s []string) {
19-	for i := len(s) - 1; i >= 0; i-- {
20-		_ = s[i]
21+	for _, v := range slices.Backward(s) {
22+		_ = v
23 	}
24 }
25
26 func Spawn(wg *sync.WaitGroup) {
27-	wg.Add(1)
28-	go func() {
29-		defer wg.Done()
30-	}()
31+	wg.Go(func() {
32+	})
33 }

Négy modernizáló futott le egyetlen kis fájlon:

embedlit: a beágyazott literálokat átírja az 1.2. szakaszban bemutatott új szintaxisra
atomictypes: az atomic.AddInt64(&x, 1) átíródik atomic.Int64.Add(1)-re, ami lehetetlenné teszi a nem atomikus hozzáférést, és csendben kijavítja a 32 bites igazítási hibákat, amelyekről nem is tudtál
slicesbackward: a visszafelé futó ciklusokból slices.Backward lesz
waitgroupgo: az Add/go/Done rituálé wg.Go-vá válik (az 1.26-os waitgroup nevet átnevezték a félreértések elkerülése érdekében)

A go tool fix help mind a 26 modernizálót felsorolja; a go tool fix help <név> egyet elmagyaráz. Ezenkívül a fmtappendf "stilisztikai aggályok miatt" eltávolításra került, ami gyönyörűen diplomatikus módja annak leírni, ami abban az issue-szálban történt.

Egy régi kódbázison a go fix ./... futtatása valóban kielégítő délután. Persze előbb olvasd el a diffet.

4.2. A go test alapértelmezés szerint futtatja a stdversion ellenőrzést

Ez az a változás, amely a legvalószínűbben megzavarja a napodat.

A go test mostantól alapértelmezés szerint lefuttatja a stdversion vet-ellenőrzést, amely megjelöli azokat a standard könyvtári szimbólumokat, amelyek újabbak, mint amit a go.mod go direktívája megenged:

1// a go.mod ezt mondja: go 1.24
2package sv
3
4import "strings"
5
6func Ext(name string) string {
7	_, ext, _ := strings.CutLast(name, ".")  // a CutLast egy 1.27-es szimbólum
8	return ext
9}

1$ go1.27rc3 test ./...
2# sv
3./x.go:6:23: strings.CutLast requires go1.27 or later (module is go1.24)
4FAIL	sv [build failed]

Ez kiküszöböli a klasszikus hibát, amikor minden a te gépeden (a legújabb toolchainnel) működik, de a CI-ben vagy egy felhasználó régebbi környezetében elszáll. Ha konzervatív go direktívával publikálsz könyvtárakat, ez ajándék.

4.3. A go test -json kapott OutputType mezőt

Az "Action":"output" sorok mostantól tartalmazhatnak egy opcionális "OutputType" mezőt: "error", "error-continue" vagy "frame" értékkel.

1'frame'  '=== RUN   TestFail\n'
2None     '    x_test.go:6: hello\n'
3'error'  '    x_test.go:7: boom\n'
4'frame'  '--- FAIL: TestFail (0.00s)\n'
5'frame'  'FAIL\n'

A t.Log kimenet (nincs mező), a t.Error kimenet (error) és a keretrendszer által generált sorok (frame) mostantól megkülönböztethetők. Bárki, aki regexet írt azért, hogy kitalálja, mely teszt-kimeneti sorok "valódiak", most törölheti.

4.4. A go doc fejlesztései

package@version szintaxis. Egy adott verzió dokumentációját úgy olvashatod, hogy nem adod hozzá a modulodhoz:

1$ go1.27rc3 doc golang.org/x/sync/errgroup@v0.10.0
2package errgroup // import "golang.org/x/sync/errgroup"
3...

Hasznos, ha frissítés előtt ellenőrizni szeretnéd, mi változott.

-ex és példa-forrás kiírása:

 1$ go1.27rc3 doc -ex strings | grep Example
 2    func ExampleClone()
 3    func ExampleCompare()
 4    func ExampleContains()
 5    func ExampleCut()
 6    func ExampleCutPrefix()
 7    ...
 8
 9$ go1.27rc3 doc strings.ExampleCut
10package main
11
12import (
13	"fmt"
14	"strings"
15)
16
17func main() {
18	show := func(s, sep string) {
19		before, after, found := strings.Cut(s, sep)
20		fmt.Printf("Cut(%q, %q) = %q, %q, %v\n", s, sep, before, after, found)
21	}
22	show("Gopher", "Go")
23	...
24}
25
26Output:
27Cut("Gopher", "Go") = "", "pher", true

A példa forrása és a várt kimenet, a terminálban, anélkül, hogy megnyitnál egy böngészőlapot, amely jövő csütörtökön is nyitva lesz.

4.5. A go mod tidy rendet teremt a require blokkjaidban

Go 1.27-es vagy újabb modulok esetén a go mod tidy a szétszórt require blokkokat legfeljebb kettőre (közvetlen és közvetett) vonja össze, megőrizve a hozzájuk tartozó megjegyzéseket.

 1// Előtte
 2module tidydemo
 3
 4go 1.27
 5
 6require golang.org/x/sync v0.10.0
 7
 8// networking
 9require golang.org/x/net v0.33.0
10
11require (
12	golang.org/x/sys v0.28.0 // indirect
13)
14
15require golang.org/x/text v0.21.0 // indirect

 1// Utána: go mod tidy
 2module tidydemo
 3
 4go 1.27
 5
 6require (
 7	// networking
 8	golang.org/x/net v0.33.0
 9	golang.org/x/sync v0.10.0
10)

Figyeld meg, hogy a // networking megjegyzés megmaradt. Ez főként a Git merge-konfliktusok feloldása utáni takarításban segít, mert ott születnek a szétszórt require blokkok. Ha a csapatodban háromnál többen adnak hozzá függőségeket, a go.mod konfliktusaid észrevehetően csendesebbek lesznek.

4.6. Egyéb apróságok

A bzr támogatás megszűnt. Ha ez téged érint, valóban szívesen hallanám a történetedet.
A go tool trace -http csak portot megadva a localhostra köt. A -http=:6060 már nem hallgat minden interfészen. Használd a -http=0.0.0.0:6060 értéket, ha ezt szánod. Ez most összhangban van a go tool pprof viselkedésével, és megakadályozza a néha véletlen nyilvános profilozót.
A válaszfájlok (@file) támogatottak a compile, link, asm, cgo, cover és pack eszközöknél, GCC-kompatibilis formátumban. Olyan build-rendszereknél, amelyek túllépik a parancssori hosszkorlátokat: üdv, Bazel.

5. Fordító, linker, portok

Fordító. A //line direktívákban a relatív fájlnevek mostantól a tartalmazó fájl könyvtárához képest oldódnak fel, a go/scanner viselkedését követve. Ez akkor fontos, ha kódgenerátorokat írsz.

A függvénylitálok (closure) szimbólumnevei is egyszerűbbek lettek: ugyanaz a név függetlenül az inlinálástól, és ugyanazon literál több példánya megoszthat kódot a binárisban. Funkcionális változás nincs, kivéve: a reflect.Value.Pointer által függvényazonosságot összehasonlító kód gyakrabban fogja "egyenlőnek" látni a függvényeket, mint korábban. Ez az összehasonlítás soha nem volt érvényes, de ha van ilyened, most kezd hangosabban hazudni.

Linker. Az új -macos és -macsdk kapcsolók beállítják az OS- és SDK-verziót a macOS LC_BUILD_VERSION betöltési parancsában.

Portok.

A Darwin mostantól legalább macOS 13 Ventura verziót igényel, ahogy az 1.26-ban be lett jelentve. Ellenőrizd a CI futtatóidat.
A PowerPC (GOOS=linux GOARCH=ppc64) átállt az ELFv2 ABI-ra. Linux kernel 3.13+ szükséges (a RHEL7 3.10-re visszaportolta). A cgo, a PIE és a külső linkelés mostantól támogatott. Ha cgo-t használsz, de statikus, tisztán Go bináris kell, állítsd a CGO_ENABLED=0 értéket.

6. Frissítési ellenőrzőlista

A Go 1.27 komolyan veszi a kompatibilitást, de mielőtt a verziót emeled, ellenőrizd ezeket:

Tömörített kimenetre vonatkozó golden-file tesztek. A compress/flate kódolót váltott; a gzip/zip/png bájtok eltérhetnek.
JSON hibaüzenet-szövegeket illesztő tesztek. A viselkedés azonos; a hibaszöveg nem az.
Eltávolított GODEBUG-ok a go.mod-ban. asynctimerchan, gotypesalias, tlsrsakex, tls3des, tls10server, tlsunsafeekm, x509keypairleaf: ezek csak akkor törik el a buildet, ha a régi értékükre vannak állítva.
stdversion szabálysértések. A go test ezeket mostantól elkapja. Ha konzervatív go direktívájú könyvtárat karbantartasz, futtasd korán.
macOS 12 vagy régebbi CI futtatók. A támogatás megszűnt.
Függvénylitál-szimbólumnevekre állító tesztek, és reflect.Value.Pointer függvény-összehasonlítások.
Transport.MaxIdleConns = 0 vagy kérésenkénti Client. A választörzsek automatikus kiürítésével együtt ez lassulást okozhat.

Záró gondolatok

A Go 1.27 az a kiadás, amelynél egyszerre sok halogatott karbantartási feladat jött el.

A generikus metódusok hiányzó darabja voltak az 1.18-as generikus munkának. A struct literál mezőválasztók lezártak egy tizenegy éves issue-t. Az encoding/json/v2 két év javaslatvitája volt. Az uuid pedig olyan rést tömött be, amelyet szinte minden Go projekt évtizede ugyanazzal a külső függőséggel foltozott.

Ha prioritási sorrendet szeretnél az érték kinyeréséhez:

httptest.NewTestServer + synctest.Sleep: az időfüggő HTTP-tesztek gyorssá és determinisztikussá válnak. A legjobb ráfordítás-hozam arány az egész kiadásban.
A goroutine-szivárgási profil: tegyél ki egy végpontot staging környezetbe, és készülj a megalázkodásra.
A visszakövetés goroutine-címkéi: három sor pprof.Do a kérés-belépési pontodon a következő hajnali 3 órai stack dumpodat olvashatóvá teszi.
go fix ./...: hagyd, hogy az eszköz elvégezze a modernizálást.
encoding/json/v2: nincs sietség. Egyesével, opciónként vezesd be.

Vedd elő a go1.27rc3-at, és futtasd rá most a tesztsorozatodat. Mindez az ellenőrzőlista jóval kellemesebb egy keddi délutánon felfedezni, mint egy incidens közepén.

Hivatkozások