La programlingvo Go, versio 1.22, estas publikigata. Google, kun kontribuo de la komunumo, disvolvas hibridan solvon, kiu kombinas la altan rendimenton de kompilitaj lingvoj kun la avantaĝoj de skriptlingvoj, kiel ekzemple facileco de skribado, rapida disvolviĝo kaj protekto kontraŭ eraroj. La kodo de la projekto estas distribuita sub la BSD-licenco.
La sintakso de Go baziĝas sur konataj elementoj de la lingvo C, kun kelkaj pruntoj de Oberono. La lingvo estas relative konciza, tamen facile legebla kaj komprenebla. La Go-kodo estas kompilita en memstarajn binarajn ruleblajn dosierojn, kiuj funkcias native, sen la bezono de virtuala maŝino (profilado, sencimigado kaj aliaj subsistemoj por detekti problemojn dum rulado estas integritaj kiel rultempaj komponantoj), atingante rendimenton kompareblan al C-programoj.
La projekto estas desegnita de la komenco kun plurfadena programado kaj efika funkciado sur plurkernaj sistemoj en menso, inkluzive de iloj je operatora nivelo por organizi paralelajn komputadojn kaj interagojn inter samtempe funkciantaj metodoj. La lingvo ankaŭ provizas enkonstruitan protekton kontraŭ memor-troŝarĝoj kaj subtenas rubkolekton.
Inter la ŝanĝoj en la nova eldono:
- Subteno por difini intervalojn de entjeroj estis aldonita al "por" bukloj, ekzemple, por iteracii tra valoroj de 0 ĝis 9, vi nun povas uzi la buklon "por i := intervalo 10 {…}".
- Eksperimenta (GOEXPERIMENT=rangefunc) subteno por intervalfunkcioj estis aldonita al por-bukloj, permesante specifi funkcion kiel iteratoron. Ekzemple, "por i, x := intervaltranĉaĵoj.Malantaŭen(s) {…}"
- Delonga problemo kun por-bukloj, kiu kaŭzis, ke gorutinaj alvokoj kunhavigu buklajn variablojn trans iteracioj, estas solvita. Ekzemple, la kodvaloroj := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } nun presos "a", "b", kaj "c", anstataŭ nur "c", kiel antaŭe.
- Optimumigoj pri administrado de rultempa memoro estis faritaj, rezultigante 1-3%-an pliigon de rendimento kaj 1%-an redukton de memorkonsumo en plej multaj aplikaĵoj.
- La laboro daŭris pri efektivigo de profil-gviditaj optimumigoj (PGO) en la kompililo, konsiderante rultempajn funkciojn. La nova versio de la kompililo uzas malvirtualigajn ilojn por anstataŭigi nerektajn metodajn vokojn per plivastigita enlinia efektivigo.
- Kun PGO ebligita, la aldonita ŝanĝo plibonigis la rendimenton de plej multaj programoj je 2-14%.
- Eksperimenta (GOEXPERIMENT=newinliner) plibonigita efektivigo de la enliniiga mekanismo de vokoj estis aldonita al la kompililo, uzante heŭristikojn por apartigi gravajn kaj negravajn operaciojn.
- La pakaĵo "math/rand/v2" estis aldonita al la norma biblioteko, provizante pli koheran API-on kaj pli rapidajn algoritmojn por pseŭdohazardaj nombrogenerado.
- La pakaĵo net/http.ServeMux nun subtenas la specifon de metodoj kaj maskoj en ŝablonoj. Ekzemple, la ŝablono "GET /static/{id}/" estos aplikita al petoj kun la HTTP-metodo "GET" kaj konservos la valoron de la dua segmento de la petita vojo en la identigilo "id".
- La pakaĵo database/sql nun subtenas la tipon Null[T], permesante skanadon de kolumnoj kiuj povas esti nulaj. La pakaĵo slices nun havas funkcion Concat por kunfandi plurajn tranĉaĵojn de iu ajn tipo.
- Komandoj por labori kun laborspacoj (kolektoj de moduloj) nun subtenas la uzon de dosierujo "vendor", kiu enhavas dependecojn de la enhavo de la laborspaco. Ĉi tiu dosierujo estas kreita dum ekzekuto de la komando "go work vendor" kaj estas uzata en konstruaj komandoj kiam la opcio "-mod=vendor" estas specifita (defaŭlte ebligita se la dosierujo "vendor" ekzistas).
Ŝanĝoj en servaĵa konduto.
- `go get` ne plu estas subtenata ekster modulo en hereda GOPATH-reĝimo (t.e., kun GO111MODULE=off). Aliaj konstrukomandoj, kiel `go build` kaj `go test`, daŭre funkcios por heredaj GOPATH-programoj senfine.
- "go mod init" jam ne provas importi modulajn postulojn el agordodosieroj por aliaj vendistaj iloj (kiel ekzemple Gopkg.lock).
- go test -cover nun presas resumajn datumojn pri kovrado por kovritaj pakaĵoj, kiuj ne havas proprajn testdosierojn. Antaŭ Go 1.22, go test -cover raportus resumajn datumojn pri kovrado por tia pakaĵo: mymod/mypack [neniuj testdosieroj]
kaj nun, ekde Go 1.22, funkcioj en pakaĵo estas konsiderataj nekovritaj: mymod/mypack kovro: 0.0% de deklaroj Noto: Se pakaĵo tute ne enhavas efektivigeblan kodon, ni ne povas raporti senchavan kovroprocenton; por tiaj pakaĵoj, gotest daŭre raportos mankantajn testdosierojn.
- La TTT-interfaco de la spurilo estis iomete ĝisdatigita kiel parto de subteno por la nova spurilo. Pluraj problemoj estis solvitaj kaj la legebleco de diversaj paĝoj estis plibonigita. La TTT-interfaco nun subtenas inspektadon de spuroj en faden-sekura vido. La spurspektilo nun ankaŭ montras la plenan daŭron de ĉiuj sistemvokoj. Ĉi tiuj plibonigoj validas nur por spuroj generitaj de programoj konstruitaj kun Go 1.22 aŭ pli posta. En estonta eldono, kelkaj el ĉi tiuj plibonigoj estos faritaj al spuroj generitaj de pli malnovaj versioj de Go.
- La rultempo nun stokas tip-bazitajn rubkolektajn metadatenojn pli proksime al ĉiu stako-objekto. Ĉi tiu ŝanĝo ankaŭ reduktas la memoran spuron de plej multaj Go-programoj je proksimume 1% per senduplikado de redundaj metadatenoj. La plibonigo povas esti pli malgranda en iuj programoj, ĉar ĉi tiu ŝanĝo ĝustigas la grandecklasajn limojn de la memorasignilo, do iuj objektoj povas esti movitaj al pli alta grandecklaso. Sekvo de ĉi tiu ŝanĝo estas, ke la adresoj de iuj objektoj, kiuj antaŭe ĉiam estis vicigitaj je 16-bajtaj (aŭ pli altaj) limoj, nun estos vicigitaj nur je 8-bajtaj limoj. Iuj programoj, kiuj uzas asemblerajn instrukciojn, kiuj postulas, ke memoradresoj estu vicigitaj pli grandaj ol 8 bajtoj kaj dependas de la antaŭa viciga konduto de la memorasignilo, povas malsukcesi, sed ni atendas, ke tiaj programoj estos maloftaj. Tiaj programoj povas esti konstruitaj per GOEXPERIMENT=noallocheaders kun la eblo reveni al la malnova metadatena modelo kaj restarigi la antaŭan vicigan konduton, sed pakaĵposedantoj devus ĝisdatigi sian asembleran kodon por eviti la vicigan supozon, ĉar ĉi tiu solvo estos forigita en estonta eldono.
- Kiel menciite en la notoj pri la eldono de Go 1.20, Go 1.22 nun postulas la finan version de Go 1.20 aŭ pli novan por la komenca konstruo. Ni atendas, ke Go 1.24 postulos la finan version de Go 1.22 aŭ pli novan por la komenca konstruo.
Originala (go.dev)
fonto: linux.org.ru
