LINUX.ORG.RU
Новости — Разработка  

Go 1.24

 ,

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)
← Конфликт между проектами Fedora Linux и OBS Studio
Вышла версия 25.2.11 файлового менеджера Yazi →
  1 2 3 4
Ответ на: комментарий от zg

Поэтому говорить о каком-то легаси на Go довольно смешно.

Нет же, оно уже нарабатывается стахановскими темпами. Сегодняшние студенты туда смачно и вляпаются.

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

Go — это новые проекты с уже новыми подходами к проектированию. А Java — это часто legacy ещё из поздних 90-х, копаться в legacy — удовольствие сильно ниже среднего.

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

Проясняю свою позицию.

  1. В Golang из коробки есть линтер (go vet), унификация кода (go fmt) и фреймворк тестирования. Многие проекты на Java были начаты еще в то время, когда тестирование, линтеры и унификация не были распространены, а разработчики массово особо не изучали такие методологии, как TDD, BDD, SOLID и другие.

  2. Ваше заявление «лапша без партнёров» по моему безосновательно. ООП паттерны реализуются через композицию вместо наследования. Factory, Singleton, Observer, MVC - никаких проблем.

Дело не в языке программирования, дело в комманде и в наследованной кодовой базе.

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

Первый раз ты или кто-то ещё заюзал - это не то. Я говорил о компаниях, которые используют Go как основной ЯП и нанимают программистов именно для этого, а не для иногда между делом. Раньше четырёх - пяти лет назад таких компаний практически не было.

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

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

Нет, или пруфы?

Ваш собеседник буквально на пальцах объяснил что ваши нагугленные претензии к Go немного не в тему.

Он спорол откровенную чушь про «специальную архитектуру» для снижения нагрузки на гц.

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

Нет же, оно уже нарабатывается стахановскими темпами. Сегодняшние студенты туда смачно и вляпаются.

Легаси - это старый код, использующий старые и уже неактуальные технологии. Например EJB, Web Services / SOAP или JSF в мире Java. А то, о чём говоришь и ты и я - это просто говнокод начинающих гошников, даже если они бывшие синьйоры-помидоры в других ЯП. Это временное явление.

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

Так платят же не за сложность языка или количество интеллектуальных усилий для написания программ (тогда бы Хаскель уже бы пытались выучить примерно все). Типа за бизнес-приложения бизнес и платит. Платят не за язык, а за знание предметной области. К деньгам близко. Гошечку тоже одно время полюбили всякие блокчейностроители и смартконтракторганизаторы, там тоже платили много.

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

Гошечка не лучше Джавы, он нишевый. Если есть задача, хорошо подходящая под концепцию Го-рутин, то бери Го и пиши.

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

Он спорол откровенную чушь про «специальную архитектуру» для снижения нагрузки на гц.

Что не так? Чем чаще выделяется память, тем больше её надо чистить. У процесса в ОС есть два места, куда выделяется память: Cтек и Куча (HEAP). Память в Cтеке выделяется и освобождается автоматически при вызове и завершении функций и не требует GC, а вот выделение памяти в HEAP как раз нагружает сборщик мусора.

Если вы расшариваете память между функциями, то каждое выделение заставляет работать GC. Поэтому программу надо проектировать так, чтобы выделять память в HEAP как можно реже. Под эту задачу и спроектирован io.Reader.

Это и есть «специальная архитектура» программы: когда в HEAP один раз выделяется буфер, и потом он используется на протяжении работы программы.

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

Гошечка не лучше Джавы, он нишевый.

Джаву разрабатывали во времена сплошных монолитов и множества архитектур. Сейчас гораздо актуальнее микросервесная архитектура и облака. Таким образом мультиплатформенность стала невостребованной - хочешь Linux на x86, бери в облаке. Хочешь на ARM, бери там же. Хочешь Винду, и такое там тоже есть. Поэтому компилируешь под ровно одну архитектуру и живёшь спокойно. А что стало востребованным? Например скорость поднятия и разогрева микросервиса. В этом плане Java, тем более с каким нибудь монструозным фреймворкок вроде Spring Boot, нервно курит в сторонке. Именно поэтому в Go нет фреймворков, а есть лишь стандартная и несколько легковесных библиотек со стороны. По той же причине там нет виртуальной машины, байткода и тормозящего разогрев JIT. Ещё Spring Boot - это декларативное программирование на аннотациях и интерфейсах с автоматической реализацией. Пока нет потребности в каком-то нестандартном поведении это работает хорошо, но как только нужно сделать шаг в сторону, тут же начинается возня и чёрная магия. В Go этого безобразия нет и не будет. Кроме того современная Java, из некогда простого языка, превращается в помойку технологий с кучей старого легаси, часть из которого официально появилось совсем недавно, но сразу и до сих пор никому не нужно. Например модули, в том виде, в котором они их сделали после овер 10 лет мучений!

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

успех golang с очевидной семантике изначального «мастерплана»(?!)

ща уже во многом не так

но если придерживатся изначальных интенций то golang и прост и сверхпроизводителен - а в остальном классическое закатывание солнца в ручную ( фОнаты ся оценят) отягощённое конкурентностью и сходкой мусоров в неожиданных пространство-временные точки

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

Чем чаще выделяется память, тем больше её надо чистить.

Твоя фамилия не Цзедун случаем?

Ты привёл пример с буфером который не делает ничего. Я тебе говорил об интенсивных нагрузках на которых этот gc очень даже заметен. Про волшебную передачу по значению…

func main() {
	var i int
	debug.SetGCPercent(-1) // выключаем GC кх#ям
	for i=0; i < math.MaxInt64; i ++ {
		fmt.Printf("%d, bottles of beer\n",i)
	}
}

Эта программа досчитает до MaxInt64 или сдохнет по ООМ?

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

и " поэтому " синтаксис ассоциативных массивов крив на оба глаза

если синтаксис крив то и семантика не до кручена

так и живут и даже урожаи колосятся

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

Ужоскакой! Если мне надо программировать с оглядкой на особенности рантайма, то ну его нафик, такое развлечение...

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

У тебя там нет интенсивного использования кучи. Твоя программа работает у меня уже какое-то время и использование памяти выросло с 0.1% до 0.5% и продолжает расти довольно медленно. Да, у меня 128 гектаров, что нетипично, но даже если умножить данный процент на 4, всё равно достаточно медленный рост.

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

Речь шла об оптимизациях. Можно и без оглядок. Для прикладного софта это некритично.

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

Да оба языка от меня далеки. Управляемых языков я вообще не признаю, ибо зачем мне интеллектуальная прокладка между рулем и колесами? Привод должен быть жестким, желательно механическим. Гидравлический тоже сойдет. :) А прикладных задач я не решаю. Идея языка мне понравилась, синтаксис читаем с первого раза. Выглядит симпатичнее руста... Может, когда и пригодится. Вот только размер helloworld.go в скомпилированном виде меня расстроил. :( Полтора мега — это перебор.

gns ★★★★★
()

Время исполнения
...
на основе Шведских Таблиц

По ссылке: «Swiss Tables». Как говорилось в рекламной кампании одного [ныне недействующего] латвийского банка, -«Мы ближе, чем Швейцария!» ;)

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

Да оба языка от меня далеки. Управляемых языков я вообще не признаю, ибо зачем мне интеллектуальная прокладка между рулем и колесами?

Для того чтобы сосредоточиться на решении прикладной задачи и не заниматься борьбой с памятью. Очевидно же!

Вот только размер helloworld.go в скомпилированном виде меня расстроил. :( Полтора мега — это перебор.

Оно от тебя денег просит или что-то ещё?

zg
()

Ну, признавайтесь:

  • полезная иллюстрация, сохранили себе копию на всякий случай?
  • прочитали эту простыню до конца?
  • нашли в тексте два нецензурных слова и одно оправдание терроризма?
frob ★★★★★
()

Какая же картинка уродская, можно было же векторной графикой нарисовать нормально.

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

и не заниматься борьбой с памятью. Очевидно же!

Это единственный аргумент? Слабовато что-то. И плата за это сомнительное удобство «велика еси» :(

Оно от тебя денег просит или что-то ещё?

Что-то еще. Напоминает анекдот про новый Боинг-777. «А теперь со всей этой херней мы попытаемся взлететь». Не понимаю, что они в бинарь напихали, что бы одну простую строчку вывести на экран.

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

Ничего из этого. Но некоторое мнение об авторе новости составили :)

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

У тебя там нет интенсивного использования кучи.

Там просто маленький подвох, с одной стороны FPrintf в std выглядит вот так:

func Fprintf(w io.Writer, format string, a ...any) (n int, err error) {
	p := newPrinter()
	p.doPrintf(format, a)
	n, err = w.Write(p.buf)
	p.free()
	return
}

Казалось бы всё «щикарно», но вот этот самый Printer{} внутри вызывает форматер, который объявляет внутри себя переменные, которые ни разу не высвобождаются без gc. И если не гонять книжные примеры а именно что-то делать на go - таких неявных моментов куча. А если ещё в исходники зарыться… вобщем «никакого праздника, и закрыли и шарик не дали»

у меня 128 гектаров

MaxInt64 9223372036854775807 - даже по байтику рано или поздно убъётся. :)

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

Вот только размер helloworld.go в скомпилированном виде меня расстроил. :( Полтора мега — это перебор.

tinygo делает исполняемые файлы меньшего размера:

$ cat hw.go 
package main

import (
    "fmt"
)

func main() {
    fmt.Println("Hello world!")
}
$ tinygo build -opt s hw.go
$ strip -s hw
$ stat -c%s hw
25304
$ file hw
hw: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
$ ./hw 
Hello world!
No ★★
()
Ответ на: комментарий от gns

Вот только размер helloworld.go в скомпилированном виде меня расстроил.

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

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

Ну он же, вероятно, имеет свои ограничения. Это как сказать, что в кредитную карту с чипом Java тоже помещается. Да, помещается, но какая там Джава?

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

Go — это новые проекты с уже новыми подходами к проектированию.

Какие новые подходы к проектированию, микросервисы что ли? Если новый проект начинается с микросервисов, значто техлида надо гнать за профнепригодность.

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

Если новый проект начинается с микросервисов, значто техлида надо гнать за профнепригодность.

С чего вдруг? Гнать его надо когда монолит пилится на микросервисы переписыванием.

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

Это единственный аргумент? Слабовато что-то. И плата за это сомнительное удобство «велика еси» :(

А тебе этого аргумента мало? Из-за ручной борьбы с памятью типичный Си-плюс-плюсник боится бросать исключения в конструкторе. Забыл освободить или освободил дважды - типичные проблемы вашего кода.

Что-то еще. Напоминает анекдот про новый Боинг-777. «А теперь со всей этой херней мы попытаемся взлететь». Не понимаю, что они в бинарь напихали, что бы одну простую строчку вывести на экран.

Как что, рантайм они туда запихнули. Потому что обычно программы пишут для гораздо более сложных вещей, нежели просто вывести строку на экран. Нетривиальные программы на C/C++ так же компилируются в немаленькие бинарники. Размер рантайма при этом составляет довольно маленький процент от общего размера. Например Git более 4-х мегабайт.

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

Казалось бы всё «щикарно», но вот этот самый Printer{} внутри вызывает форматер, который объявляет внутри себя переменные, которые ни разу не высвобождаются без gc. И если не гонять книжные примеры а именно что-то делать на go - таких неявных моментов куча. А если ещё в исходники зарыться… вобщем «никакого праздника, и закрыли и шарик не дали»

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

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

Один проект из миллиона доживёт до этапа

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

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

Речь шла лишь о снижении нагрузки на него.

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

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

А тебе этого аргумента мало? Из-за ручной борьбы с памятью типичный Си-плюс-плюсник боится бросать исключения в конструкторе. Забыл освободить или освободил дважды - типичные проблемы вашего кода.

Утечки памяти — не самая большая проблема современного С++. Для этого есть valgrind или segfault при первом запуске. Обычно команды backtrace в gdb хватает при наличии коры. Навороты абстракций в современной стандартной библиотеке являются проблемой гораздо более сложной для понимания. Код становится «шаблонным» не в смысле применения темплейтов, а в смысле «программистских штампов». Я буду писать так, потому, что все так пишут. И чего стоит раскрытие всех этих шаблонных классов программист перестает понимать. Исключения в конструкторах опасны тем, что деструкторы не до конца сконструированных объектов вызываться будут. Это не про память, это про consistency.

Ну или человек заболевает Александреску головного мозга.

Как что, рантайм они туда запихнули.

Да понятно, что рантайм. Я ж говорю, — нишевый язык. Или есть под него задача в асинхронной парадигме с процедурами завершения, или не надо этим пользоваться. Рантайм навязывает стиль программирования.

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

на хайлоаде

На хайлоаде у тебя просто произойдёт scale up нужного микросервиса.

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

Ерунда какая то. Это вообще то интерфейс …

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

С другой стороны проблема говнокода таки существует. Прежде всего потому, что многие Go проекты начинались людьми без серьёзного опыта в нём.

Я не знаю где такой проблемы нет, если взять к примеру Python то там такого 1 к 10 …

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

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

alysnix ★★★
()

@lbvf50txt любопытства ради, а что ты скажешь вот об этой истории? https://habr.com/ru/articles/487116/

TL;DR: у дискорда был микросервис очистки данных, и он тормозил из-за периодически запускающегося GC. Вылечить это не смогли, переписали на расте.

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

TL;DR: у дискорда был микросервис очистки данных, и он тормозил из-за периодически запускающегося GC. Вылечить это не смогли, переписали на расте.

В статье написано что они нашли решение но так как пихали Rust во все щели то решили и это переделать.

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

Но я бы на их месте покапал в сторону Cassandra, что это еще за БД которая написана на JAVA … вон тот же Prometeus молотит по черному на дохлом железе без проблем.

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

Чего это не кажет? Даже у пенсионеров кажет. У лентяев только не кажет.

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

Подкрутили кеши, да. Но все равно проблема осталась.

Я не за то, чтобы всё переписывать на расте, просто хочу услышать разные мнения.

liksys ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
  1 2 3 4
← Конфликт между проектами Fedora Linux и OBS Studio
Разработка
Вышла версия 25.2.11 файлового менеджера Yazi →