LINUX.ORG.RU

Go 1.26

 , ,

Go 1.26

0

5

После полугода разработки состоялся выпуск 1.26 компилятора и стандартной библиотеки языка программирования Go.

Основные изменения:

  • Встроенная новая функция, создающая новую переменную, позволяет использовать в качестве операнда выражение, указывающее начальное значение переменной. Простой пример такого изменения — это код, подобный этому:
    x := int64(300)
    ptr := &x
    

    Можно упростить до:
    ptr := new(int64(300))
    
  • Обобщенные типы могут ссылаться сами на себя в собственном списке параметров типа. Это изменение упрощает реализацию сложных структур данных и интерфейсов.

Улучшение производительности:

  • Экспериментальный сборщик мусора Green Tea теперь включен по умолчанию.
  • Накладные расходы на CGO были сокращены примерно на 30%.
  • Компилятор может выделять резервную память для Slice-структур в стеке в большем количестве ситуаций, что повышает производительность.

Инструментарий:

  • Команда go fix была полностью переписана с использованием фреймворка analysis и теперь включает в себя несколько десятков «модернизаторов», которые предлагают безопасные исправления, помогающие вашему коду использовать преимущества новых возможностей языка и стандартной библиотеки.

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

  • Пакет archsimd для доступа к архитектурно-зависимым операциям SIMD. На данный момент поддерживается только AMD64.
  • Пакет secret со вспомогательными функциями для обнуления памяти.
  • В пакет профилирования pprof добавлена поддержка опции GOEXPERIMENT=goroutineleakprofile для обнаружения утечек goroutine.


>>> Полный список изменений

>>> Подробности на go.dev/blog

★★★★★

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

Мне кажется у тебя request и response никак не связаны )

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

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

Да, request первым параметром передаётся в send, по памяти писал, извиняюсь.

В несколько классов пишут, т.к. принято маппить запросы и ответы в классы. Но никто не заставляет это делать, можно и с JSON работать в «сыром» виде, через List и Map. Конечно в Java это будет не так лаконично, как в нетипизированном пайтоне или JS по очевидным причинам, но в целом терпимо.

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

Я не знаю какой именно его вклад, но в Unix появились новые, практичные идеи, которые сильно развились в Plan 9 типа файлов как универсального интерфейса. Насколько я знаю даже в линуксе идея контейнеров и ограничения возможностей программ была перенята из Plan 9.

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

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

Чисто для сравнения. В лаконичном языке

var client = newHttpClient();
var request = HttpRequest.newBuilder().uri(uri).GET().build();
var response = client.send(BodyHandlers.ofString());

превращается в

user> (-> "https://linux.org.ru"
          http/get
          :body)
"<!DOCTYPE html>\n<html lang=ru>\n<head>\n<link rel=\"stylesheet\" type=\"text/css\" href=\"/tango/combined.css?20260216-1946\">\n<link rel=\"preload\" href=\"/js/lor.js?20260216-1946\" as=\"script\">\n\n<lin…
ugoday ★★★★★
()
Ответ на: комментарий от loz

В Go интересен не общий объём возможностей, тут вы правы, а то, как они упакованы, согласованы и соединены меж собой. Это особый вид инженерного творчества, требующий настоящего профессионализма и чувства вкуса. Тут можно провести аналогию с книжной вёрсткой. Если в процессе чтения ты замечаешь работу типографа, всё очень плохо, он провалился. Шрифты, поля, отступы должны располагаться настолько естественно, что глаз читателя будет скользить по ним, не замечая.

Для сравнения, С++ известен тем, что многие выбирают некое его подмножество и пишут на нём как на разных языках: кто-то упарывается по STL, кто-то пишет на С с классами, другие пишут без исключений и т.п. В Go такого и близко нет, это единый, слитный язык программирования.

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

Я плохо понял, что за код ты написал.

Но вообще это всё ерунда. Ничего не мешает мне написать метод String httpGet(String url) на Java или на любом другом языке программирования. Это всё к, непосредственно, языку программирования отношения не имеет, уж функции и строки поддерживают все языки.

Сложность освоения языка как правило обусловлена во-первых концептуальной сложностью конструкций, которые в нём представлены (какие-нибудь continuations вроде выглядят просто, интерфейса там пара функций, а вот в голове у себя их уложить ой как непросто); во-вторых просто числом этих конструкций (как пример - C#, по отдельности каждая фича простая и понятная, но их там очень уж много), в-третьих нюансами применения (как пример - C++, с его UB порой сдуреть можно, когда казалось бы простой код оказывается неправильным).

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

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

Я из-за вас кофе поперхнулся сейчас.

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

Отдельная боль это парсинг json-чиков: encoding/json построен вокруг reflect, что сразу добавило неуклюжести cтруктурам и замусорило все кучей тегов.

От такого вкуса скулы сводит, когда нужно собрать или распарсить json с вложенными массивами.

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

Я плохо понял, что за код ты написал.

(-> param func1 func2) более выразительный способ записать (func2 (func1 param)), значение как бы проталкивается сквозь набор функций как в shell pipeline.

http/get делает Get запрос и возвращает Response в виде ассоциативного массива. :body извлекает значение одноимённого ключа из него. Всё просто и ничего лишнгего.

Ничего не мешает мне написать метод

Именно. Ничто не мешало, но вы не написали. Потому что мозги у вас по другому устроены. Кроме того стрелочных макросов в яве нет и не будет никогда.

Сложность освоения языка …

Это всё безусловно так, но кроме этого есть ещё и стиль, некий принятый подход в рамках которого весь промышленный код и пишется. И если вдруг этот стиль тобой не унутрен, то постоянно возникает ощущщение: „ДА НАХРЕНА ВЫ Ж ВСЁ ЭТО ПОНАПИСАЛИ, ГАДЫ!!!! ЗАЧЕМ ТАК СЛОЖАН!!!1!“. При этом в яве и хаскелле такой позыв возникает сплошь и рядом, хотя и по совершенно разным причинам, а в Go, вот, нет совсем. Там простыни очень понятного и простого кода.

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

парсинг json-чиков: encoding/json построен вокруг reflect,

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

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

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

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

Go конечно лучше плюсов, более стандартный и четкий подход это хорошо, но ведь это не противоречит тому чтобы сделать язык в том числе практичным и удобным. Те же дженерики насколько я знаю все-таки ввели позже, для меня сам факт того что при создании языка было решено «забить» на такую фундаментальную вещь уже вызывает вопросы. Это собственно о Кене Томпсоне и проектировании Go.

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

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

Решение простое и в C# он сделано с помощью dynamic. Парсим JSON в map/array и даём возможность обращаться к нему, как будто это объект с полями.

dynamic user = httpGet(url).json()
return (String) user.name

А вот если в коде уже хочется полновесный объект типа User, тогда да, какой-то маппинг надо делать. Но в общем-то и в динамических языках просто пулять внутрь какой-то непроверенный распарсенный JSON тоже не стоит, там есть свои библиотеки и технологии.

Тут, кстати, ЯП тоже мог бы предоставить какой-то простой синтаксис. Например возможность прикастовать dynamic к статическому типу, что вставит автоматом код конвертации, компилятору-то это раз плюнуть. Хотя это можно и библиотекой через reflection сделать, так что не критично (если reflection есть, конечно).

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

Варианты?

Не изобретать велосипед, а нормально реализовать RFC 7159 как это сделано, например, в PHP (php.net).

Вот, хочется впендюрить в строгий статический язык джейсонину из интернета,

Go как раз и создали для непонимающих веб С-программистов. Если бы они понимали то и язык бы не пришлось изобретать.

в которой в принципе может быть что угодно.

Нет, не может. Есть четкие типы данных которые представляет JSON и они имеют четкий синтаксис. Там всего 4 примитивных типа (string, number, boolean, null) и 2 структурных (array, object).

Это логически самопротиворечивая задача, тут красивого решения не предвидится.

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

Строка всегда обрамлена в кавычки, число не обрамлено ничем, boolean бывает только true или false, null всегда null, массив обрамлен квадратными скобками, а объект - фигурными. Один рекурсивный алгоритм красиво размотает любой JSON.

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

Мне, напротив, понравилось как это было сделано. Безусловно о существовании дженериков было известно. Но добавили их в язык только тогда, когда поняли как это сделать не помешав уже имеющимся возможностям. Это на порядок лучше нежели «О, крутая фича, давай запихнём как-нибудь, а кто скажет, что пользоваться неудобно, тот лалка и ниасилил».

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

Оно не будет работать для сложных конструкций. Т.е. нельзя написать response["users"][i]["name"], не говоря уже о том, что это добавляет три мусорных символа на каждый доступ к полю и смотрится куда хуже, чем response.users[i].name.

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

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

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

Т.е. нельзя написать response[«users»][i]["name"]

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

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

Так это вообще не то. Надо чтоб функция getUsers(storage) возвращала []Users. У нас тут статическая типизация или где? Не «4 примитивных типа (string, number, boolean, null) и 2 структурных (array, object)», а массив структур строго определённого типа. А если вдруг нет, то это должно рубиться на этапе компиляции. Иначе зачем вообще это всё?

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

Пишите на PHP. Его у вас никто не забирает.

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

Так это вообще не то.

Именно то, во вложенной структуре поля могут быть, а могут и не быть. Поэтому разматываются примитивные типы, а не готовые структуры.

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

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

Перед вами три пути водка, рейвы и айти:

  1. Как в Go, приводим что пришло к чему нужно и не забываем писать if err != nil

  2. Как в Хаскеле, Get-запрос возвращает Maybe массив пользователей, а там дальше ехала монада через монаду …

  3. Взять динамический язык и не мучиться.

Всё остальное довольно странное.

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

Взять динамический язык и не мучиться.

чем это отличается от сериализации в хеш-таблицу кроме небольшого синтаксического сахара? Любой объект питона это просто словарь его членов. Когда вы пишете obj.dep.method() вы делаете по сути тоже самое что obj.__dict__["dep"].__dict__["method"]() и даже еще хуже, потому что там будет куча обращений к getattr.

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

Если нет гарантий насчёт содержимого оной таблицы, то ничем. Вы протащили кусок динамики в статический мир. А вот баг это или фича — считай сам.

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

Go как раз и создали для непонимающих веб С-программистов

Интересная версия... :))

Google, вроде бы, как-то иначе объяснял появление Go. ;)

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

Интересная версия… :))

А Rust создали потому что С-программисты не умеют в многопоточность и безопасную работу с памятью.

Google, вроде бы, как-то иначе объяснял появление Go. ;)

Я просто называю вещи своими именами. Если бы в корпорациях индусы из касты неприкасаемых писали нормальный Си-код, то не было бы ни Go, ни Rust.

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

Я просто называю вещи своими именами

Аха, аха... :) И называется это действо «набросом»...

Если бы в корпорациях индусы из касты неприкасаемых писали нормальный Си-код, то не было бы ни Go, ни Rust.

Глупость... Возможно, что и благоглупость, но всё равно чушь несусветная...

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

«Нет предела человеческой глупости, потому что мысль остановить невозможно» — К. Прутков, кажется...

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

Если бы в корпорациях индусы из касты неприкасаемых писали нормальный Си-код

На Земле нет и не будет потребного количества программистов, способных на С выдавать качественный код. С этим фактом ничего не поделать. Господь создал людей вот такими и не следует Гневить его своим нытьём.

Язык программирования должен учитывать «архитектуру» человеческого мозга точно так же, как и архитектуру процессора. Что Go с успехом и делает.

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

На Земле нет и не будет потребного количества программистов, способных на С выдавать качественный код. С этим фактом ничего не поделать

Ровно то же самое верно и для любого другого языка...

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

Да. И разойдёмся на этом. Количество толковых, грамотных специалистов в любой области никогда не было и не будет достаточным и, уж тем более, преобладающим над посредственными...

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

Количество толковых, грамотных специалистов в любой области никогда не было и не будет достаточным

И охота вам ударяться в мегаломанию. Для производства достаточно качественного, надёжного, безопасного и быстрого кода на Go достаточно наловить мартышек из ближайших джунглей. Ключевое слово здесь — достаточно. А гениев, конечно, завсегда не хватает. Только вам точно нужны гении, чтобы json’ы перекладывать?

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

И охота вам ударяться в мегаломанию.

Клеить ярлыки — то такое себе...

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

То же самое верно для любого другого языка. Только замечу, что «качественный, надёжный, безопасный и быстрый» — характеристики оценочные, они у каждого очень свои... Ну да баг с вами...

Только вам точно нужны гении, чтобы json’ы перекладывать?

Что нужно мне, я тебе рассказывать не буду, не о том речь. А приписывание оппоненту своих фантазий о нём — ...

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

Язык программирования должен учитывать «архитектуру» человеческого мозга точно так же, как и архитектуру процессора. Что Go с успехом и делает.

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

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

То же самое верно для любого другого языка.

Нет.

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

Go это буквально шоры для лошади.

Шоры это полезная штука (иначе зачем бы их придумали).

очарование языком пройдет.

Очарование Go это как очарование молотком или отвёрткой (не коктейлем). Это тупо инструмент для работы работы на работе. За деньги. Для очарования есть более другие вещи.

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

Но добавили их в язык только тогда, когда поняли как это сделать не помешав уже имеющимся возможностям

Ну вот и вопрос - больше 10 лет (2009-2022) чтобы добавить такую важную вещь, как я должен доверять такому проекту? Сколько еще похожих вещей может вскрыться в языке? Сколько лет еще понадобится чтобы он был сравним по удобству и практичности с конкурентами?

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

Тоже самое я могу сказать например об Эрланге - там отлично сделана параллельность но ужасно сделаны типы данных через тегированные tuple и кучи макросов вокруг них. Это то что пытаются пофиксить в производных типа Elixir, то есть приходится создавать целые отдельные языки потому что оригинальный не может никуда двигаться.

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

с конкурентами?

Это, например, с кем?

качественно добавлять новые фичи

Вот, как раз этот параметр и оптимизируется. Лучше не добавлять новую возможность, чем делать это плохо. Такая философия языка.

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

Это, например, с кем?

Плюсы, раст, питон.

Лучше не добавлять новую возможность, чем делать это плохо. Такая философия языка.

А почему не взять такую философию чтобы добавлять и делать это хорошо? С какой стати это взаимоисключающие вещи?

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

Плюсы

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

раст

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

питон

Когда из него GIL уберут? В каком виде однопоточный тормоз может вообще быть конкурентом Go?

Обобщая: продукт не должен быть лучше всех во всём. У него должна быть своя философия, своё видение идеала и цели, который он должен воплотить. Вот, у Go это есть, он идёт к идеалу, хотя ещё не дошёл. Но судя по коммерческому успеху и того, что есть — достаточно.

С какой стати это взаимоисключающие вещи?

Из быстро, хорошо и дёшево можно выбрать любые два пункта.

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

раст это язык без сборщика мусора, каналов и горутин? Тогда в каком виде он вообще является конкурентом гошке?

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

Но судя по коммерческому успеху и того, что есть — достаточно.

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

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

Когда из него GIL уберут?

Уже в процессе.

В каком виде однопоточный тормоз может вообще быть конкурентом Go?

Ты же понимаешь что я могу этот же самый аргумент развернуть в другую сторону? В Го встроенные горутины каналы и прочее - это оверхед если мне нужна максимальная производительность в 1 потоке. В такой ситуации выигрывают языки в которых многопоточность реализована в виде библиотеки а не встроена в язык. Хорошо ли делать ставку на одни лишь горутины и делать это единственной фичей языка? Это очень сильное ограничение, которого нет ни у раста ни у питона.

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

Не для всего софта нужны горутины

Не для всего, есть разные ниши. Но если языки выступают в разных нишах, как (и зачем) их сравнивать? Где чего лучше, там то и берёшь.

Сколько этого успеха из-за качества продукта а сколько из-за пиара гугла?

  1. Го отлично подходит для того, где его применяют. Главным образом, в асинхронной работе с микросервисами.

  2. А я что-то и не помню, чтобы его как-то особо пиарили.

Уже в процессе.

Я это уже лет десять назад слышал.

В Го встроенные горутины каналы и прочее - это оверхед если мне нужна максимальная производительность в 1 потоке.

Я абсолютно с вами согласен. Если нужна производительность синхронного однопоточного кода, Go будет странным выбором. Впрочем, по правилам Русского языка слова «питон» и «производительность» нельзя ставить в одном предложении, так что он тут тоже не сгодится.

Это очень сильное ограничение, которого нет ни у раста ни у питона.

А их тоже можно какашками закидать при желании. Зачем вам borrow checker в синхронном однопоточном коде, например? А типизация в питоне как сделана? Как говна кусок, вот как. Ну, и т.д.

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

Меня вот недавно, во время работы с другим языком, очаровала одна вещь в Go: отсутствие варнингов. Потому что в других языках бывает как: варнингов куча, среди них теряются подсказки для нового кода, а исправлять стрые без целенаправленной сфокусированной работы нельзя. Вдруг что-то сломается? Ну, например, некая функция синтаксически нигде не используется, но при этом спрятана в кишках рефлексии.

И эти опасные варнинги накапливаются, год за годом, словно отсылки к древним доктринам, которые никто никогда не хотел читать.

Тем временем, в Go нет варнингов. Потенциальные объекты варнингов устраняются либо на этапе компиляции, либо ограничениями языка, либо автоматическим обновлением кода до новой версии языка (go fix).

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

Но если языки выступают в разных нишах, как (и зачем) их сравнивать?

А просто потому что эти ниши пересекаются, на выбор обычно доступны несколько вариантов.

Я это уже лет десять назад слышал.

Ну теперь есть pep со статусом final https://peps.python.org/pep-0779/

А их тоже можно какашками закидать при желании. Зачем вам borrow checker в синхронном однопоточном коде, например? А типизация в питоне как сделана? Как говна кусок, вот как. Ну, и т.д.

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

loz ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.