LINUX.ORG.RU

Go 1.24

 ,


0

7

Новый выпуск языка Go, версия 1.24, выходит спустя шесть месяцев после Go 1.23. Большинство изменений в реализации тулчейна, рантайма и библиотек. Как всегда, релиз обеспечивает обещание совместимости Go 1. Разработчики языка ожидают, что почти все программы Go продолжат компилироваться и работать как прежде.

Изменения в языке

Go 1.24 теперь полностью поддерживает обобщённые алиасы типов: алиас типа может быть параметризирован как объявленный тип. Подробности в спецификации языка. Пока возможность может быть отключена установкой GOEXPERIMENT=noaliastypeparams; однако опция aliastypeparams будет удалена в Go 1.25.

Инструменты

Команда go

Модули go теперь могут отслеживать исполняемые зависимости используя директиву tool в go.mod. Это убирает необходимость в предыдущем обходном решении по добавлению инструментов как пустых импортов в файл, обычно называемый “tools.go”. Команда go tool теперь может запускать эти инструменты в добавок к инструментам поставляемым вместе с Go. Больше информации можно увидеть в документации.

Новый флаг -tool для go get приводит к добавлению директивы инструмента в текущий модуль для указанных пакетов в добавок к добавлению директив требования.

Новый мета-паттерн tool ссылается на все инструменты в текущем модуле. Это может быть использовано для обновления их всех через go get tool или для установки их в свою GOBIN директорию через go install tool.

Исполняемые файлы созданные через go run и новое поведение go tool теперь кэшируются в кэше сборки Go. Это делает повторяющиеся запуски за счёт увеличенного кэша. #69290.

Команды go build и go install теперь принимают флаг -json, который сообщает вывод и ошибки сборки как структурированный вывод JSON в стандартном выводе. Детали формата можно увидеть в go help buildjson.

Более того, go test -json теперь сообщает вывод и ошибки сборки в JSON, вперемешку с JSON’ом результата тестирования. Их можно различить по новым типам Action, но если они вызывают проблемы в системе интеграции тестов, можно откатиться к текстовому выводу сборки через настройку GODEBUG gotestjsonbuildtext=1.

Новая переменная окружения GOAUTH предоставляет гибкий способ авторизовывать приватные стягивания модулей. Увидеть подробности можно в go help goauth.

Команда go build теперь устанавливаем версию основного модуля в скомпилированном бинарнике, основываясь на теге и/или коммите системы контроля версии. Суффикс +dirty будет добавлен при наличии незакоммиченных изменений. Можно использовать флаг -buildvcs=false для того, чтобы опустить информацию контроля версии из бинарника.

Новая настройка GODEBUG toolchaintrace=1 теперь может быть использована для отслеживания процесса выбора тулчейна в команде go.

Cgo

Cgo поддерживает новые аннотации для функций C для улучшения производительности времени выполнения. #cgo noescape cFunctionName говорит компилятору, что переданная в функцию C cFunctionName память не ускользает. #cgo nocallback cFunctionName говорит компилятору, что функция C cFunctionName обратно не вызывает никаких функций Go. Большую информацию можно увидеть в документации cgo.

Cgo на данный момент отказывается компилирован вызовы С функции, которая имеет несколько несовместимых объявлений. Например, если f объявлен как одновременно void f(int) и void f(double), cgo сообщит ошибку вместо возможной генерации неправильной последовательности вызова f(0). Новым в этом релизе является улучшенное обнаружение этого условия ошибки, когда несовместимые объявления проявляются в разных файлах. #67699.

Objdump

Инструмент objdump теперь поддерживает дизассемблирование на 64-битном LoongArch (GOARCH=loong64), RISC-V (GOARCH=riscv64) и S390X (GOARCH=s390x).

Vet

Новый анализатор tests сообщает распространённые ошибки в объявлениях тестов, фаззеров, бенчмарков и примеров в тестовых пакетах, такие как неправильно сформированные имена, неверные сигнатуры или примеры, которые документируют несуществующие идентификаторы. Некоторые из этих ошибок могут привести к невыполнению тестов.

Существующий анализатор printf теперь сообщает диагностику вызовов формы fmt.Printf(s), где s — строка неконстантного формата, без других аргументов. Такие вызовы почти всегда являются ошибкой, поскольку значение s может содержать символ %; взамен используйте fmt.Print. 60529. Эта проверка имеет тенденцию делать находки в существующем коде, и поэтому применяется только когда версия языка (как указано директивой go файла go.mod или комментариями `//go:build) по крайне мере Go 1.24, чтобы избежать возникновения сбоев продолжительной интеграции при обновлении на тулчейн Go 1.24.

Существующий анализатор buildtag теперь сообщает диагностику, когда есть неправильное ограничение сборки старшей версии Go в директиве //go:build. Например, //go:build go1.23.1 ссылается на точечный релиз; взамен используйте //go:build go1.23. #64127.

Существующий анализатор copylock теперь сообщает диагностику, когда переменная, объявленая в тройном “for” цикле, таком как for i := iter(); done(i); i = next(i) { … }, содержит sync.Locker, такой как sync.Mutex. Go 1.22 изменил поведение таких циклов на создание новой переменной на каждую итерацию, копируя значения с предыдущей итерации; это копирование небезопасно для локов. #66387.

GOCACHEPROG

Внутренний бинарник cmd/go и механизм кэширования тестов теперь могут быть реализованы дочерними процессами, реализующими протокол JSON между инструментом cmd/go и дочерним процессом, названным переменной окружения GOCACHEPROG. Прежде это была за GOEXPERIMENT. Детали протокола можно увидеть в документации.

Время исполнения

Несколько улучшений производительности в рантайм сократили накладные расходы на CPU на 2-3% в среднем среди набора репрезентативных бенчмарков. Результаты могут варьироваться в зависимости от приложения. Эти улучшения включают новую встроенную реализацию map на основе Шведских Таблиц, более эффективного выделения памяти маленьких объектов и новой внутренней рантаймовой реализации мьютекса.

Новая встроенная реализация map и новый внутренний рантаймовый мьютекс могут быть отключены настройками GOEXPERIMENT=noswissmap и GOEXPERIMENT=nospinbitmutex во время сборки соответственно.

Компилятор

Компилятор уже запрещал определять новые методы с типами получателя, которые были сгенерированы cgo, но было возможно обойти это ограничение через алиас типа. Go 1.24 теперь всегда сообщает ошибку, если получатель обозначает сгенерированный cgo тип, напрямую или косвенно (через тип алиаса).

Линкер

Линкер теперь генерирует идентификатор сборки GNU (запись ELF NT_GNU_BUILD_ID) на платформах ELF и UUID (команда загрузки Mach-O LC_UUID) на macOS по-умолчанию. Идентификатор сборки или UUID выводится из идентификатора сборки Go. Это может быть выключено флагом линкера -B none, либо переопределено флагом линкера -B 0xNNNN с указанным пользователем шестнадцатеричным значением.

Раскрутка

Как было указано в заметках релиза Go 1.22, Go 1.24 теперь требует для раскрутки Go 1.22.6 или позже. Разработчики ожидают, что Go 1.26 будет требовать для раскрутки точечный релиз Go 1.24 или позже.

Стандартная библиотека

Ограниченный директорией доступ к файловой системе

Новый тип os.Root предоставляет возможность выполнять операции файловой системы в рамках определённой директории.

Функция os.OpenRoot открывает директорию и возвращает os.Root. Методы на os.Root оперируют в этой директории и не позволяют путям ссылаться на локации за пределами директории, включая те, которые следуют символическим ссылкам за пределы директории. Методы на os.Root отражают большинство операций файловой системы доступных в пакете os, включая, к примеру, os.Root.Open, os.Root.Create, os.Root.Mkdir и os.Root.Stat.

Новая функция бенчмарка

Бенчмарки теперь могут использовать более быстрый и менее подверженный ошибкам метод testing.B.Loop для совершения итераций бенчмарка вроде for b.Loop() { … } заместо типичных циклических структур с участием b.N вроде for range b.N. Это предлагает два значительных преимущества:

  • Функция бенчмарка исполняется точно один раз на каждый -count, таким образом дорогостоящие шаги установки и очистки исполняются только единожды.
  • Параметры вызова функции и результаты продолжают жить, предотвращая компилятор от полной оптимизации тела цикла.

Улучшенные финализаторы

Новая функция runtime.AddCleanup является механизмом завершения, который более гибок, более эффективен и менее подвержен ошибкам чем runtime.SetFinalizer. AddCleanup прикрепляет функцию очистки к объекту, которая запустится как только объект станет недоступным. Однако, в отличие от SetFinalizer, несколько очисток могут быть прикреплены к одному объекту, очистки могут быть прикреплены к внутренним указателям, очистки обычно не вызывают утечки, когда объекты формируют цикл, и очистки не откладывают освобождение объекта или объектов, на которые тот указывает. Новый код должен предпочитать AddCleanup перед SetFinalizer.

Новый пакет weak

Новый пакет weak предоставляет слабые указатели.

Слабые указатели являются низкоуровневым примитивом, предоставляемым для создания структур, эффективно использующих память, таких как слабые словари для сопоставления значений, словарей канонизации для чего угодно, что не покрыто пакетом unique, и различных видов кэшей. Для поддержки этих юзкейсов, данный релиз также предоставляет runtime.AddCleanup и maphash.Comparable.

Новый пакет crypto/mlkem

Новый пакет crypto/mlkem реализует ML-KEM-768 и ML-KEM-1024.

ML-KEM является пост-квантовым механизмом обмена ключом, ранее известный как Kyber и специфицированный в FIPS 203.

Новые пакеты crypto/hkdf, crypto/pbkdf2 и crypto/sha3

Новый пакет crypto/hkdf реализует основанную на HMAC функцию вывода ключа “Extract-and-Expand” HKDF, как определено в RFC 5869.

Новый пакет crypto/pbkdf2 реализует основанную на пароле функцию вывода ключа PBKDF2, как определено в RFC 8018.

Новый пакет crypto/sha3 реализует хэш-функцию SHA-3 и SHAKE и cSHAKE функции расширяемого вывода, как определено в FIPS 202.

Все три пакета основаны на существующих ранее пакетах golang.org/x/crypto/….

Комплаенс FIPS 140-3

Этот релиз включает новый набор механизмов для обеспечения комплаенса FIPS 140-3.

Криптографический модуль Go является набором внутренних пакетов стандартной библиотеки, которые прозрачно используются для реализации одобренных FIPS 140-3 алгоритмов. Приложения не требуют изменений для использования криптографического модуля Go для одобренных алгоритмов.

Новая переменная окружения GOFIPS140 может быть использована для выбора версии криптографического модуля Go для использования в сборке. Новая настройка GODEBUG fips140 может быть использована для включения режима FIPS 140-3 во время исполнения.

Go 1.24 включает криптографический модуль Go версии v1.0.0, который в текущий момент тестируется с аккредитованной CMVP лабораторией.

Новый экспериментальный пакет testing/synctest

Новый экспериментальный пакет testing/synctest предоставляет поддержку тестирования конкурентного кода.

  • Функция synctest.Run запускает группу горутин в изолированном «пузыре». В пузыре функции пакета time оперируют на ложных часах.
  • Функции synctest.Wait ждут когда все горутины заблокируются в текущем пузыре.

Подробности можно увидеть в документации пакета.

Пакет synctest является экспериментальным и должен быть включен установкой GOEXPERIMENT=synctest. API пакета может измениться в будущих релизах. В #67434 можно увидеть больше подробностей и предоставить обратную связь.

Минорные изменения в библиотеке

archive

Реализации (*Writer.AddFS) в archive/zip и archive/tar теперь пишут заголовок директории для пустой директории.

bytes

Пакет bytes добавляет несколько функций, которые работают с итераторами:

  • Lines возвращает итератор по разделённым новой линией строкам в слайсе байтов.
  • SplitSeq возвращает итератор по всем подслайсам слайса байтов, разделённого сепаратором.
  • SplitAfterSeq возвращает итератор по подслайсам слайса байтов, разделённого после каждого вхождения сепаратора.
  • FieldsSeq возвращает итератор по подслайсам слайса байтов вокруг последовательностей символов пробела, как определено unicode.IsSpace
  • FieldsFuncSeq возвращает итератор по подслайсам слайса байтов вокруг последовательностей кодовых точек юникода, удовлетворяющих предикату.

crypto/aes

Значение, возвращаемое NewChipher больше не реализует методы NewCTR, NewGCM, NewCBCEncrypter и NewCBCDecrypter. Эти методы были незадокументированы и не были доступны на всех архитектурах. Теперь значение Block должно передаваться напрямую в соответствующие функции crypto/cipher. На данный момент crypto/cipher всё ещё проверяет эти методы на значениях Block, даже если они больше не поддерживаются стандартной библиотекой.

crypto/cipher

Новая функция NewGCMWithRandomNonce возвращает AEAD, который реализует AES-GCM, генерируя случайный одноразовый номер во время Seal и добавляя его в начало зашифрованного текста.

Реализация Stream, возвращаемая NewCTR при использовании с crypto/aes теперь в несколько раз быстрее на amd64 и arm64.

NewOFB, NewCFBEncrypter и NewCFBDecrypter теперь объявлены устаревшими. Режимы OFB и CFB неаутентифицированы, что в общем случае позволяет активным атакам манипулировать и восстанавливать открытый текст. Приложениям рекомендуется использовать AEAD взамен. Если неаутентифицированный режим Stream необходим, можно использовать NewCTR взамен.

crypto/ecdsa

PrivateKey.Sign теперь создаёт детерминистичную сигнатуру в соответствии с RFC 6979, если источник случайности nil.

crypto/md5

Значение, возвращаемое md5.New, теперь также реализует интерфейс encoding.BinaryAppender.

crypto/rand

Функция Read теперь гарантирует отсутствие неудач. Если Read встретит ошибку во время чтения Reader, программа безвозвратно завершит работу. Обратите внимание, что умолчальный Reader задокументирован всегда работать успешно, поэтому это изменение должно затронуть только те программы, которые переопределяют переменную Reader. Одним исключением являются ядра Linux до версии 3.17, где умолчальный Reader всё ещё открывает /dev/urandom и может потерпеть неудачу.

На Linux 6.11 и позже Reader теперь использует системный вызов getrandom через vDSO. Это в несколько раз быстрее, обычно для небольших чтений.

На OpenBSD Reader теперь использует arc4random_buf(3).

Новая функция Text теперь может генерировать криптографически безопасные случайные строки текста.

crypto/rsa

GenerateKey теперь возвращает ошибку если запрошен ключ длинной менее 1024 битов. Все методы Sign, Verify, Encrypt и Decrypt теперь возвращают ошибку, если используются с ключом размера менее 1024 битов. Такие ключи небезопасны и не должны использоваться. Настройка GODEBUG rsa1024min=0 восстанавливает старое поведение, но разработчики Go рекомендуют делать это только при необходимости и только в тестах, например добавляя строку //go:debug rsa1024min=0 в файл теста. Новый пример GenerateKey предоставляет простой для использования стандартный 2024-битный тестовый ключ.

Теперь безопасно и более эффективно вызывать PrivateKey.Precompute до PrivateKey.Validate. Precompute теперь быстрее в присутствии частично заполненного PrecomputedValues, например при извлечении ключа из JSON.

Пакет теперь отклоняет больше неправильный ключей, даже когда Validate не вызывается, и GenerateKey теперь может вернуть новые ошибки для сломанных источников случайности. Поля Primes и Precomputed структуры PrivateKey теперь используются и валидируются даже когда некоторые значения отсутствуют. Также внесены изменения в crypto/x509 по разбору и извлечению ключей RSA, описанные ниже.

SignPKCS1v15 и VerifyPKCS1v15 теперь поддерживают SHA-512/224, SHA-512/256 и SHA-3.

GenerateKey теперь использует немного другой метод для генерации приватной экспоненты (функция Кармайкла вместо функции Эйлера). Редкие приложения, которые извне пересоздают ключи только из простых чисел, могут создать разные, но совместимые результаты.

Операции над публичными и приватными ключами теперь до двух раз быстрее на wasm.

crypto/sha*

crypto/subtle

Новая функция WithDataIndependentTiming позволяет пользователю исполнять функцию с включенными функциями, специфичными для архитектуры, которые гарантируют неизменность определённых инструкций относительно времени значения данных. Это может быть использовано для того, чтобы убедиться в том, что код, созданный для работы за константное время, не был оптимизирован функциями уровня процессора таким образом, что он работает в переменное время. На данный момент WithDataIndependentTiming использует бит PSTATE.DIT на arm64 и ничего не делает на всех остальных архитектурах. Настройка GODEBUG dataindependenttiming=1 включает режим DIT на всю программу Go.

Вывод XORBytes должен перекрываться полностью или никак с вводом. Ранее поведение было неопределено в противном случае, тогда как сейчас XORBytes будет паниковать.

crypto/tls

Сервер TLS теперь поддерживает Encrypted Client Hello (ECH). Эта возможность может быть включена заполнением поля Config.EncryptedClientHelloKeys.

Новый пост-квантовый механизм обмена ключом X25519MLKEM768 теперь поддерживается и включен по умолчанию когда Config.CurvePreferences является nil. Настройка GODEBUG tlsmlkem=0 возвращает дефолт.

Поддержка экспериментального обмена ключом X25519Kyber768Draft00 была убрана.

Порядок обмена ключом теперь обрабатывается полностью пакетом crypto/tls. Порядок Config.CurvePreferences теперь игнорируется, а содержимое используется только для определения того, какие обмены ключом включить, когда поле заполнено.

Новое поле ClientHelloInfo.Extensions перечисляет список идентификаторов расширений, полученных в сообщении Client Hello. Это может быть полезно для снятия отпечатков клиентов TLS.

crypto/x509

Настройка GODEBUG x509sha1 была убрана. Certficicate.Verify больше не поддерживает подписи, основанные на SHA-1.

OID теперь реализует интерфейсы encoding.BinaryAppender и encoding.TextAppender.

Умолчальное поле политик сертификата было изменено с Certificate.PolicyIdentifiers на Certificate.Policies. При разборе сертификатов оба поля будут заполнены, но при создании политики сертификатов будут взяты из поля Certificate.Policies вместо Certificate.PolicyIdentifiers. Это изменение может быть возвращено настройкой GODEBUG x509usepolicies=0.

CreateCertificate теперь будет генерировать серийный номер используя RFC 5280 совместимый метод при передаче шаблона полем Certificate.SerialNumber nil, вместо сбоя.

Certificate.Verify теперь поддерживает валидацию политики, как определено в RFC 5280 и RFC 9618. Новое поле VerifyOptions.CertificatePolicies может быть установлено на приемлемый набор политик OIDs. Только цепи сертификатов с валидными графами политик будут возвращены из Certificate.Verify.

MarshalPKCS8PrivateKey теперь возвращает ошибку вместо извлечения неправильного ключа RSA. (MarshalPKCS1PrivateKey не имеет возвращения ошибки и его поведение при предоставленных неправильных ключах продолжает быть неопределено.)

ParsePKCS1PrivateKey и ParsePKCS8PrivateKey теперь используют и валидируют закодированные значения CRT, поэтому могут отклонять неверные ключи RSA, которые были ранее принятыми. Использование настройки GODEBUG x509rsacrt=0 возвращает к пересчитыванию значений CRT.

debug/elf

Пакет debug/elf добавляет поддержку обработки версий символов в динамичных файлах ELF (Executable and Linkable Format). Новый метод File.DynamicVersions возвращает список динамичных версий, определённых в файле ELF. Новый метод File.DynamicVersionNeeds возвращает список динамических версий, требуемых этим файлом ELF, которые определены в других объектах ELF. Наконец, новые поля Symbol.HasVersion и Symbol.VersionIndex указывают версию символа.

encoding

Два новых интерфейса TextAppender и BinaryAppender были введены для добавления текстового или бинарного представления объекта к слайсу байтов. Эти интерфейсы предоставляют такую же функциональность, что и TextMarshaler и BinaryMarshaler, но вместо выделения нового слайса каждый раз, они добавляют данные напрямую в существующий слайс. Эти интерфейсы сейчас реализованы типами стандартной библиотеки, которые уже реализуют TextMarshaler и/или BinaryMarshaler.

encoding/json

При сборке поле структуры с новой опцией omitzero в теге поля структуры будет опущено, если его значением является ноль. Если тип поля имеет метод IsZero() bool, он будет использован для определения, является ли значение нулём. Иначе значение будет нулём если оно нулевое значение для его типа. Тег поля omitzero чище и менее подвержен ошибкам чем omitempty, когда намерением является опустить нулевые значения. В частности, в отличие от omitempty, omitzero опускает нулевые time.Time значения, что является частым источником проблем.

Если указаны оба omitempty и omitzero, поле будет опущено если значение пустое или нулевое (или сразу вместе).

UnmarshalTypeError.Field теперь включает встроенные структуры для предоставления более детальных сообщений ошибки.

go/types

Все структуры данных go/types, которые раскрывают последовательности пары методов, как Len() int и At(int) T, теперь также имеют методы, которые возвращают итераторы, позволяя упростить код подобный этому:

params := fn.Type.(*types.Signature).Params()
for i := 0; i < params.Len(); i++ {
  use(params.At(i))
}

На этот:

for param := range fn.Signature().Params().Variables() {
  use(param)
}

Методы: Interface.EmbeddedTypes Interface.ExplicitMethods Interface.Methods MethodSet.Methods Named.Methods Scope.Children Struct.Fields Tuple.Variables TypeList.Types TypeParamList.TypeParams Union.Terms

hash/*

log/slog

Новый DiscardHandler является обработчиком, который никогда не включен и всегда отбрасывает свой вывод.

Level и LevelVar теперь реализуют интерфейс encoding.TextAppender.

math/*

net

ListenCondig теперь использует MPTCP по умолчанию на системах, где это поддерживается (пока только Linux).

IP теперь реализует интерфейс encoding.TextAppender.

net/http

Изменилось ограничение Transport на полученные информационные ответы 1xx в ответ на запрос. Ранее это останавливало запрос и возвращало ошибку после получения более 5 ответов 1xx. Теперь это возвращает ошибку только если весь размер всех ответов 1xx превышает настройку конфигурации Transport.MaxResponseHeaderBytes.

Кроме того, когда запрос имеет хук для отслеживания net/http/httptrace.ClientTrace.Got1xxResponse, теперь нет ограничения на общее число ответов 1xx. Хук Got1xxResponse может вернуть ошибку для остановки запроса.

Transport и Server теперь имеют поле HTTP2, которое разрешает конфигурирование настроек протокола HTTP/2.

Новые поля Server.Protocols и Transport.Protocols предоставляют простой способ сконфигурировать какие протоколы HTTP сервер или клиент используют.

Сервер и клиент могут быть сконфигурированы поддерживать незашифрованные подключения HTTP/2.

Когда Server.Protocols содержит UnencrypterHTTP2, сервер примет подключения HTTP/2 на незашифрованные порты. Сервер может принять сразу HTTP/1 и незашифрованный HTTP/2 на один и тот же порт.

Когда Transport.Protocols содержит UnencryptedHTTP2 и не содержит HTTP1, траспорт будет использовать незашифрованный HTTP/2 для адресов http://. Если транспорт сконфигурирован использовать сразу HTTP/1 и незашифрованный HTTP/2, он будет использовать HTTP/1.

Поддержка незашифрованного HTTP/2 использует «HTTP/2 с предварительным знанием» (RFC 9113, секция 3.3). Устаревший заголовок “Upgrade: h2c” не поддерживается.

net/netip

Addr, AddrPort и Prefix теперь реализуют интерфейсы encoding.BinaryAppender и encoding.TextAppender.

net/url

URL теперь также реализует интерфейс encoding.BinaryAppender.

os/user

В Windows Current теперь может быть использован в Windows Nano Server. Реализация была обновления для избежания использования функций из библиотеки NetApi32, которая отсутствует в Nano Server.

В Windows Current, Lookup и LookupId теперь поддерживают следующие встроенные сервисные аккаунты пользователя:

  • NT AUTHORITY\SYSTEM
  • NT AUTHORITY\LOCAL SERVICE
  • NT AUTHORITY\NETWORK SERVICE

В Windows Current был значительно ускорен, когда текущий пользователь присоединён к медленному домену, что является обычным случаем для многих корпоративных пользователей. Новая производительность реализации теперь в порядке миллисекунд, в сравнении с предыдущей реализации, которая могла занять несколько секунд, даже минут, до завершения.

В Windows Current теперь возвращает пользователя владельца процесса, когда текущий поток выдаёт себя за другого пользователя. Ранее это возвращало ошибку.

regexp

Regexp теперь реализует интерфейс encoding.TextAdapter.

runtime

Функция GOROOT теперь объявлена устаревшей. В новом когде следует предпочесть использование системного пути для определения бинарника “go”, и использовать go env GOROOT для определения GOROOT.

strings

Пакет strings добавляет несколько функций для работы с итераторами:

  • Lines возвращает итератор по разделённым новой линией строкам в строке.
  • SplitSeq возвращает итератор по всем подстрокам строки, разделённой сепаратором.
  • SplitAfterSeq возвращает итератор по подстрокам строки, разделённой после каждого вхождения сепаратора.
  • FieldsSeq возвращает итератор по подстрокам строки вокруг последовательностей символов пробела, как определеноunicode.IsSpace
  • FieldsFuncSeq возвращает итератор по подстрокам строки вокруг последовательностей кодовых точек юникода, удовлетворяющих предикату.

sync

Реализация sync.Map была изменена, улучшая производительность, в особенности для изменений словаря. Например, менее вероятно соперничество изменений непересекающихся множеств на больших словарях, и больше не требуется время наращивания для достижения от словаря нагрузки низкого соперничества.

Если вы встретите какие-либо проблемы, установите GOEXPERIMENT=nosynchashtriemap во время сборки, чтобы вернуться назад к старой реализации и, пожалуйста, заполните форму проблемы.

testing

Новые методы T.Context и B.Context возвращают контекст, который отменяется после завершения теста и до выполнения функций очистки теста.

Новые методы T.Chdir и B.Chdir могут быть использованы для изменения рабочий директории на период работы теста или бенчмарка.

text/template

Шаблоны теперь поддерживают range-over-func и range-over-int.

time

Time теперь реализует интерфейсы encoding.BinaryAppender и encoding.TextAppender.

Ports

Linux

Как было объявлено в заметках релиза Go 1.23, Go 1.24 требует ядро Linux версии 3.2 или позже.

Darwin

Go 1.24 является последним релизом, который будет работать на macOS 11 Big Sur. Go 1.25 будет требовать macOS 12 Monterey или позже.

WebAssembly

Директива компилятора go:wasmexport добавлена в программы Go для экспорта функций в хост WebAssembly.

В WebAssembly System Interface Preview 1 (GOOS=wasip1 GOARCH=wasm) Go 1.24 поддерживает сборку программы Go как reactor/library через указание флага сборки -buildmode=c-shared.

Больше типов теперь разрешены как тип аргумента или результата для функций go:wasmimport. В особенности, bool, string, uintptr и указатели на определённые типы разрешены (подробности можно увидеть в документации), вместе с 32-битными и 64-битными типами целых чисел и с плавающей точкой, и unsafe.Pointer, которые уже разрешены. Эти типы также разрешены как типы аргумента или результата для функций go:wasmexport.

Файлы поддержки для WebAssembly были перемещены в lib/wasm из misc/wasm.

Исходный размер памяти значительно сокращён, особенно для маленьких приложений WebAssembly.

Windows

32-битный порт windows/arm (GOOS=windows GOARCH=arm) был отмечен как сломанный. Подробности в #70705

>>> Go 1.24 Release Notes



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 4)
Ответ на: комментарий от bdrbt

Go не только в вебе, в бэке который не наружу, json вообще самое отвратное решение.

Да, если проект ни с кем по сети не общается то нет общения - json не нужен. Но таких не больше 10%. Хотим мы этого, не хотим, Go - язык для веба - апишки пилить. И создавался он как замена сям с заходом на web поляну.

Obezyan
()
Ответ на: комментарий от lbvf50txt

Я думал, речь идёт не только про Read, а что-то другое, то есть что угодно выносим в буферы. Ну ладно.

kaldeon
() автор топика
Ответ на: комментарий от Obezyan

Да, если проект ни с кем по сети не общается то нет общения - json не нужен.

Ещё как общается. Классика жанра на данный момент:

WEB-(json)->HTTP Gateway->(GRPC,NATS,*MQ, Собственна приблуда)->Куча всякой хероборы которая вообще не знает ни про http, ни про json.

bdrbt
()
Ответ на: комментарий от bdrbt

Go не только в вебе, в бэке который не наружу, json вообще самое отвратное решение.

@

WEB-(json)->HTTP Gateway->(GRPC,NATS,*MQ, Собственна приблуда)->Куча всякой хероборы которая вообще не знает ни про http, ни про json.

@

WEB-(json)->HTTP Gateway

Скорее «в вебе и не только». Чтд.

Obezyan
()
Ответ на: комментарий от kaldeon

Притянутый за уши паттерн — антипаттерн

Бывает. Но лучше так, чем народное творчество кодеров, которые вообще не слышали о паттернах. Хотя в го небось уже свои паттерны наработали. Но первое поколение оторвалось конечно по полной. Так что не позавидуешь будущим копателям этого легаси.

bread
()
Ответ на: комментарий от bdrbt

Ты рассуждал про веб - получил ответ про веб. Что не так?

Все. Потому что сначала я написал что На 90% всех проектов сейчас на Go - гонять jSONы в апишке

Затем написал Да, если проект ни с кем по сети не общается то нет общения - json не нужен.

вы в ответ написали: Ещё как общается. и привели пример где json есть и идет работа с Web апи.

Те не только не опровергли, а буквально подтвердили мой первый тезис хотя пытались привести контрпример на второй, что тоже не вышло.

После чего спрашиваете «что не так?». Признавайтесь, вы - рыбка гуппи?

Obezyan
()
Ответ на: комментарий от Obezyan

Хотим мы этого, не хотим, Go - язык для веба - апишки пилить.

Прикол в том, что он дико неудобный для таких задач. Опять индустрия породила какую-то херню, которую все радостно хрумкают. Теперь уже php не кажется таким уж плохим.

bread
()
Ответ на: комментарий от Obezyan

и привели пример где json есть и идет работа с Web апи.

Вот этот промежуток с json это где-то 2% от всего проекта на go (который процентах в 80 никто руками не пишет), во всей остальной «хероборе» никаким вебом не пахнет.

bdrbt
()
Ответ на: комментарий от bread

Прикол в том, что он дико неудобный для таких задач.

Я с вами полностью согласен, как веб макака. А для С++ программистов это «ух ты горутины и каналы, многопоточность без UB» и слюна капает. Все зависит от точки зрения.

Опять индустрия породила какую-то херню, которую все радостно хрумкают.

Надо было пересадить С++ программистов средней руки за web (многопоточно гонять json/protobuf/etc по сети без UB) дав им статически типизированный компилируемый язык с жесткой ортогональностью. Go закрыл эту потребность, не идеально, но лучше (проще+быстрее) чем писать тоже самое на сях.

Теперь уже php не кажется таким уж плохим.

С 7й версии уже не плох.

Obezyan
()
Ответ на: комментарий от bdrbt

Вот этот промежуток с json это где-то 2% от всего проекта на go

Я говорил о проектах в целом. Вы говорите о структуре конкретного проекта в частности. Мы не одинаковые.

Obezyan
()
Ответ на: комментарий от hobbit

Вот развёрнутый ответ на вопрос «Чем оно лучше Java» я бы сам с удовольствием почитал (ну кроме того, что ему не нужна JRE и нет лишней сущности в виде промежуточного кода, разумеется).

Первый плюс это размер небольшого сервиса (образа). В Java базовый образ это около 70 MB самый урезанный, а большинство скорей всего будут использовать полный на 250 MB. Прибавить сюда ещё несколько десятков мегабайтов jar-ок типичных spring boot зависимостей. В Go ничего этого нет, там буквально 10-15 MB будет небольшой сервис весить, насколько я помню.

Второй плюс это потребление оперативной памяти на небольшой нагрузке. В Java я бы не рассчитывал на меньше, чем 500 MB даже для простого сервиса на спринг буте. В Go это десятки MB от силы.

Третий плюс это скорость запуска. В Go она моментальная. В Java Spring на практике - около нескольких секунд. Для некоторых юз-кейсов это может быть важно.

Четвёртый плюс (ну скорей особенность, но лично для меня плюс) это культура разработки. В Go отказываются от зависимостей, стараются обходиться стандартной библиотекой. В Java упомянутый два раза спринг бут встречается чуть менее, чем во всех проектах. В Go пропагандируется простой подход с минимумом магии. В Java пропагандируется декларативный подход с АОП (аспектно-ориентированное программирование).

Пятый плюс это унифицированная экосистема. Есть один инструмент для сборки, есть один кодовый стиль. В Java инструментов для сборки как минимум два, популярных стилей как минимум два. Это, конечно, всё ещё несоизмеримо лучше, чем в каком-нибудь C++, но хуже, чем в Go.

Что интересно - второй, третий, четвёртый минусы Java не являются несомненными. В Java никто не мешает взять какой-нибудь Helidon SE и писать код без упарывания, или вообще через com.sun.net.httpserver из стандартной библиотеки, но никто так не делает, тебя не поймут и попросят сделать «как все». Поэтому я всё же их записываю в минусы, язык это не теория, а принятые практики в первую очередь.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

странные пункты. даже в далекой России одноклассники брали джаву и выпиливали GC где им не нужен был, вполне не «как все». мне интересно про GO, раз уж встретилась задача, где типичный GO проигрывает, нельзя ли как в жава взять и выдать кусок память в off-heap и вынести высоконагруженную часть из-под контроля GC ?

iDesperado
()
Последнее исправление: iDesperado (всего исправлений: 1)
Ответ на: комментарий от vbr

популярных стилей как минимум два.

А второй - это какой? А то я как-то во всех проектах, кроме одного, видел только Sun'овский Java Code Conventions. В одном проекте был свой специфичный стиль, но там команда оптимизировала все для скорости разработки («2 пробела, вместо 4»; «все поля - публичные, отказываемся от getter'ов/setter'ов» и пр.). Выглядело, конечно, диковато, но работало для них, а нам как унаследовавшим код приходилось следовать этому стилю. Или речь про Lombok, который корёжит синтаксис так, что это фактически диалект? Edit: или речь про Google'овский стиль? [вот его я в живых промышленных проектах не видел ни разу]

X-Pilot ★★★★★
()
Последнее исправление: X-Pilot (всего исправлений: 1)
Ответ на: комментарий от iDesperado

даже в далекой России одноклассники брали джаву и выпиливали GC где им не нужен был, вполне не «как все».

Это исключение из правил

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

Это исключение из правил

но их то больше чем всего, что написано на GO. одних лямда функций на жава в облаках явно в разы больше.

iDesperado
()
Ответ на: комментарий от bread

за скорость ему можно многое простить

flant ★★★★
()
Ответ на: комментарий от LamerOk

Ну тут писать долго. Возьми какой-нибудь класс, создай в нем что угодно. В деструкторе этого чего угодно подели константу на переменную в этом что угодно, которая по началу ноль, но должна быть как-то проинициализирована. Ну и кинь исключение перед явным вызовом конструктора этого чего угодно.

Я это так себе как-то представляю. Ну или в деструкторе класса надо скинуть какой-то буфер во внешний файл, А имя этого файла еще не сконструировали. Оно, конечно да, надо проверять, а есть ли корректное имя, а есть ли буфер... Но круг проблем примерно таков.

gns ★★★★★
()
Ответ на: комментарий от gns

не до конца сконструированных объектов
которая по началу ноль, но должна быть как-то проинициализирована.
В деструкторе этого чего угодно

Тут какой-то мухлёж с терминологией. "Не до конца сконструированные объекты" - объекты, чей конструктор ещё не завершился. Если переменную в конструкторе проинициализировали в ноль, с намерением потом записать ещё что-то, но не сделали этого, а потом поделил на этот ноль в деструкторе - это точно не проблема С++ и не проблема "не до конца сконструированного объекта".

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от lbvf50txt

Столяров свои книги не с потолка взял. Это последовательное изложение одного курса лекций за другим.
разбераясь с ним, я понял что: Возможно обратиться по указателю к переменной в Стеке метода родителя.

Никогда ещё я не видел такой сильной антирекламы.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Никакого мухлежа. Я ж не утверждаю, что так будет всегда. Поинт был в том, что нельзя звать исключения из конструкторов, ибо память утечет. Ну да, и она тоже может , но не только в этом проблема.

У тебя в объекте лежит куча полей, чьи конструкторы еще даже и не вызывались (или вызвались какие-то по двоеточию). Но их деструкторы про это не знают в общем случае. Ты бросаешь исключение из конструктора и вызываются деструкторы подобъектов и деструктор твоего класса, а он про окружающий мир тоже что-то может знать. А мир для него не полон.

gns ★★★★★
()
Ответ на: комментарий от gns

Поинт был в том, что нельзя звать исключения из конструкторов, ибо память утечет.

Да, такой поинт был, но на эту чушь даже отвечать не имеет смысла.

У тебя в объекте лежит куча полей, чьи конструкторы еще даже и не вызывались (или вызвались какие-то по двоеточию). Но их деструкторы про это не знают в общем случае.

Я даже не знаю, как это комментировать. Наверно, только вспомнить первый класс, портфель и тот общеизвестный факт, что для объектов, для которых не был вызван конструктор, не будет вызван и деструктор.

Ты бросаешь исключение из конструктора и вызываются деструкторы подобъектов

Я даже не буду выяснять, кто такие "подобъекты" - базовые классы или члены класса, т.к. один хер сработает правило выше.

Ты бросаешь исключение из конструктора и вызываются деструктор твоего класса

При выбросе исключения из конструктора деструктор не вызывается.

Прочтите уже букварь по С++.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Да, наверное, пора перечитывать, спасибо, не буду спорить

gns ★★★★★
()
Ответ на: комментарий от LamerOk

Никогда ещё я не видел такой сильной антирекламы.

За то я много встречал подобных передергиваний, хамства, напыщености и чери пикинга.

lbvf50txt
()
Ответ на: комментарий от LamerOk

Кроме дизлайков и цепляния к словам, я что-то не наблюдаю у вас конструктивной критики по поводу единичного выделения буфера для сокращения нагрузки на сборщик мусора.

@LamerOk, вы наставили дизлайков (тут, тут), т.е. вы утверждаете, что выделать отдельную память для каждого чтения это более оптимально чем выделить память единожды?

Бенчмарк показывает обратное, использование одного буфера повышает скорость работы на порядок.

Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию. Объясите почему интерфейс io.Reader сконструирован именно так как он сконсртурирован. Объясните почему *os.File и *gzip.Reader удовлетворяют интерфейсу io.Reader, какой патерн используют в Golang для связывания всех этих разноплановых типов в единый работающих механизм.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 4)
Ответ на: комментарий от lbvf50txt

Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию.

Да не сможет он, зря тратите свое время. Я также сначала подумал что за его словами есть какой-то опыт, в итоге просто потерял время в другой теме.

Obezyan
()
Ответ на: комментарий от lbvf50txt

т.е. вы утверждаете

Прекрати разговаривать с голосами в своей голове. Я утверждаю, что ты пафосно устроил тут клоунаду про общеизвестную вещь, о которой знает любой, кто хоть раз в жизни открывал книжку по программированию(1) или операционным системам. Вместо клоунады потрать время с пользой если не для окружающих, то хотя бы для себя - открой такую книжку.

1. Учебники по веб-разработке книжками по программированию не являются.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Я утверждаю, что ты пафосно устроил тут клоунаду про общеизвестную вещь, …

У вас очень высокие стандарты. Для меня идиоматика Reader/Writer в Golang не была тривиальной и потребовала времени на понимание и изучение. При том я читал в двух книгах: у William Kennedy и у Jon Bodner. И вот только после Jon Bodner мне стало комфортно с io в Golang.

  1. Учебники по веб-разработке книжками по программированию не являются.

Всё понятно. Спасибо. Ваша позиция предельно ясна.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 4)
Ответ на: комментарий от lbvf50txt

А смысл делать бенчмарки, которые только в однопотоке быстрее, если Go делался в первую очередь под многопоток. Функцию с одним внешним буфером нельзя запускать одновременно в разных потоках.

fumanchez
()
Ответ на: комментарий от lbvf50txt

Извините что вмешиваюсь но тест по моему мнению какой то странный.

Разве в func BenchmarkReadWithNewBuffer

строка buffer := make([]byte, 1024)

должна быть внутри цикла : for { ?

По моему она должна быть внутри цикла : for i := 0; i < b.N; i++ {

mx__ ★★★★★
()
Ответ на: комментарий от mx__

строка buffer := make([]byte, 1024)

Архитектура io.Reader такая, что на каждое чтение НЕ выделяется отдельный буфер. Буфер выделяется один раз, передается в метод Read и там заполняется. Слайс в Golang — это практически указатель на массив.

должна быть внутри цикла : for { ?

В бенчмарке специально на кадждое чтение выделяется отдельный буфер, так как БЫЛО БЫ при НЕ правильной архитектуре программы, ЕСЛИ БЫ io.Reader возвращал новый слайс (на новое выделение памяти), а не количество прочитанных байт.

Новый буфер выделяется на каждой итерации внутреннего for перед вызовом метода Read, чтобы эмулировать поведение ошибочной архитектуры.

type NotHowReaderIsDefined interface {
    Read() (p []byte, err error)
}

Что описано в первом комментарии про буферы и сборщик мусора.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 3)
Ответ на: комментарий от iDesperado

А про GC я и не говорил. Честно говоря не квалифицирован рассуждать про отличия GC у Java и Go. Знаю лишь то, что «крутилок» у Java куда больше, но на практике мне это не пригождалось.

И речь не про компании типа одноклассников, а про более массовый софт. Одноклассники могут себе всё сами написать, их опыт на других распространять смысла нет. У яндекса вон аркадия - их своя система управления версиями, это же не значит, что можно сказать любой компании - бери и пиши свою систему, зачем тебе git. Нет, ты в 99% компаний будешь использовать git. Так и тут. Если кто-то на Java имеет возможность писать не как все, то это исключение, а не правило. Когда у тебя есть возможность любую проблему завалить кучей квалифицированных программистов, то проблемы другие, да. Но обычно такой возможности нет.

vbr ★★★★★
()
Ответ на: комментарий от X-Pilot

Второй это стиль Google. Нередко встречается, да я и сам его предпочитаю.

vbr ★★★★★
()
Ответ на: комментарий от lbvf50txt

В бенчмарке специально на кадждое чтение выделяется отдельный буфер,

Это не каждое чтение, это чтение кусочками (ну я хз как объяснить).

Короче если вам интересно то переделайте тест как я сказал и увидите разницу, если нет то извините что влез.

У меня один вопрос, (если влом то можно не отвечать) Вы до Go на чем программировали?

mx__ ★★★★★
()
Ответ на: комментарий от fumanchez

Просто тогда в каждом потоке/горутине будет свой буфер.

kaldeon
() автор топика
Ответ на: комментарий от mx__

Это не каждое чтение, это чтение кусочками (ну я хз как объяснить).

Наверное, вы хотите сказать, что при чтении из источника, размер которого больше буфера, метод Reader срабатывает несколько раз до того момента, когда будет встречен EOF.

И выделение нового маленького буфера на каждый вызов Reader — это еще большее расточение времени, чем на каждый источник раз выделять фрагмент памяти, равный размеру источника.

https://go.dev/tour/methods/21

https://go.dev/play/p/zXYc3YYjLEr

Согласен с вами. Это верное замечание.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 5)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.