LINUX.ORG.RU

Смена технического лидера в проекте Go

 


1

3

Сообщество Go отмечает важное событие: с 1 сентября Austin Clements станет новым техническим лидером проекта Go, включая команду Go в Google и сам проект в целом. Russ Cox, который возглавлял проект более 12 лет, объявил об этом шаге, подчеркивая, что лидирующая роль – это служение, а не почетное звание.

Cox отметил, что смена лидеров приносит новые силы и свежие перспективы, и что 12 лет стабильного руководства – это достаточно. Он привел в пример проект Python, который по его мнению выиграл от того, что Guido van Rossum отошел от лидерства в 2018 году. Austin Clements, работающий над Go с 2014 года и ранее возглавлявший работу над «ядром Go», теперь станет техническим лидером всего проекта. Cherry Mui, работающая над Go с 2016 года, возьмет на себя руководство компилятором, рантаймом и выпусками вместо Austin.

Хотя Cox отходит от принятия решений, он останется активным участником проекта, продолжая делиться своим опытом и поддерживать команду. Его новый фокус будет направлен на проекты Gaby и Oscar, с целью улучшения продуктивности разработчиков и открытия новых путей для других проектов. Oscar – это проект, направленный на улучшение разработки открытого ПО с помощью автоматизации процессов поддержки исходного кода. Используя большие языковые модели (LLM) для анализа и преобразования текста в код, Oscar фокусируется на рутинных задачах, таких как обработка вопросов и сопоставление их с документацией. Проект уже показал успешные результаты с ботом @gabyhelp в трекере задач Go.

Russ выразил гордость за достижения сообщества Go, а также полную уверенность в Austin и Cherry, как новых лидерах, Roland Shoemaker, который продолжит руководить безопасностью Go, и в Rob Findley и Hana Kim, которые продолжат руководить инструментами Go и поддержкой IDE.

Поздравляем Austin Clements и Cherry Mui с новыми ролями и благодарим Russ Cox за его неоценимый вклад в развитие Go!

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 10)

Посмотрим. Но у меня пока ощущение, что после ухода главных идеологов, хакеров старой школы, Го начал терять свою идеологию и подход, то, что делало его особенным. Хорошо, что есть Hare.

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

Это ecofriendly потоки, исполняются только, если у тебя комп запитан от солнечных батарей или ветряков

cocucka_B_TECTE
()
Ответ на: удаленный комментарий

Уважаемые люди часто уважают друг друга и не грешно «открыто и смело» выказывать своё уважение.

perl5_guy ★★★★★
()
Последнее исправление: perl5_guy (всего исправлений: 1)

Го начал скатываться. Может новый лидер уберет эти противные генерики и добавит исключения…

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

Может новый лидер

they/them.

Мне кажется мужской род тут не катит.

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

да нормальные вроде итераторы. генетики я б тоже не запускал, но люди любят. мои девелоперы 2 года ждали :))

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

Может новый лидер уберет эти противные генерики

И добавит нормальные? Сомнитнительно.

Го уже свернул нетуда.

ya-betmen ★★★★★
()
Ответ на: комментарий от GFORGX

Исключения гораздо удобней, чем бесконечные if err != nil после каждой строчки. С исключениями код получается надёжным, все ошибки гарантировано будут обработаны. Также исключения увеличивают производительность кода.

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

да нормальные вроде итераторы

Я в принципе согласен с этой статьёй: https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1a620

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

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

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

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

все ошибки гарантировано будут обработаны

Вообще-то ровно наоборот. С if err != nil все ошибки будут обработаны. Ещё бы обязательным это сделали, чтобы наверняка.

no-such-file ★★★★★
()
Ответ на: комментарий от vbr

Генерики это тупиковый путь. Они излишне усложняют систему типов в языке

Непонятно что они усложняют, это же не шаблоны.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Вообще-то ровно наоборот. С if err != nil все ошибки будут обработаны.

Не будут, если его не написать. А исключения работают всегда.

Иными словами: если в Go забыть написать обработку ошибок, то программа проигнорирует эту ошибку. Если в Java забыть написать обработку ошибок, то управление перейдёт к вышестоящему обработчику ошибок. Чтобы в Java проигнорировать ошибку, нужно написать специальный код для этого.

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

исключения работают всегда

Работают всегда, проверяются не всегда. Шило на мыло. Причем явная проверка она на то и явная, что сразу видно, проверка есть. А вот обрабатывается ли где-то исключение сразу не скажешь.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Поддержу. То, что в Java никто нормально исключениями так и не пользуется подтверждает, что с ними тоже не все так гладко как в рекламе.

urxvt ★★★★★
()
Ответ на: комментарий от no-such-file

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

  • При компиляции компилятор должен собрать список исключений каждой функции и добавить их в метаинформацию которая будет экспортирована вместе с функцией.
  • При использовании функции IDE/компилятор будут знать список исключений которые выбрасывает функция и все её вызываемые субфункции.
  • Если на каком-то уровне какие-то исключения обрабатываются - то они должны быть убраны из этого дерева.
  • В любом месте кода IDE/компилятор должны уметь сказать: в этой точке могут быть выброшены A, B и, внезапно, Z, потому что на глубинном уровне в 40 коллах от этой функции есть функция, которая кидает Z и никто по пути это исключение не перехватил.
  • Компилятор должен запрещать компилировать main, в котором не обработаны все подлежащие исключения
  • Должен быть способ сказать компилятору - «не компилируй дальше, если в этой точке возможны какие-то необработанные исключения».

Вот это ^ нормальная реализация исключений. А не та хня, что сейчас в С++, жабе и всём остальном.

PPP328 ★★★★★
()
Ответ на: комментарий от no-such-file

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

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

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

Можешь считать что это призыв написать Остину и Черри на почту, пусть заходят на LOR принимать поздравления. Но вообще да, немного дичь :-).

ei-grad ★★★★★
() автор топика
Ответ на: комментарий от vbr

Также исключения увеличивают производительность кода.

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

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

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

ya-betmen ★★★★★
()
Ответ на: комментарий от PPP328

всё еще может дропнуть UnexpectedException

Так оно на то и анекспектед, что нельзя предсказать. Как и вообще любые рантаймовые исключения. Они как бы от входных данных зависят и от фаз Луны. Да и чем твоё предложение поможет? Ну будет компилятор на вообще любой код вопить что ты не обработал возможное деление на ноль. Ну будут макаки добавлять пустой обработчик (специальную библиотеку даже запилят). Приложение как валилось тупо так и будет валиться. Ничего не поменялось, только лишний геморрой добавился.

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

Куда лучше, чем игнорировать его.

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

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

Также исключения увеличивают производительность кода.

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

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

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

Проблема C++ в том, что там нет GC, поэтому в очень многих функциях будет блок финализатора, где будут отрабатывать деструкторы локальных переменных. Поэтому там при раскрутке стека кода будет работать больше, хотя и не больше, чем при ручной обработке исключения. Но в Go такой проблемы нет, в 90% функций никакого финализатора не будет, поэтому там исключения бы работали быстро.

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

Вот в том то и дело, что вообще не должно быть ситуации unexpected exception. Как класса, в принципе. Каждый throw должен быть запомнен компилятором. Не должно быть ситуации throw N, где N- переменная.

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

В Харе или Го? Оба нативные. В Го коллектор есть, в Харе ручное управление, как в С.

urxvt ★★★★★
()
Ответ на: комментарий от ya-betmen

Ну насколько мне известно, для Java есть сторонние компиляторы в нативный код, но насколько они сейчас живые…

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

Так ведь жит никто не отменял. На выхлопе то всё равно найтивка. Или вопрос в наличии вирт машины?

ya-betmen ★★★★★
()
Ответ на: комментарий от PPP328

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

Не все

При компиляции компилятор должен собрать список исключений каждой функции и добавить их в метаинформацию которая будет экспортирована вместе с функцией. При использовании функции IDE/компилятор будут знать список исключений которые выбрасывает функция и все её вызываемые субфункции. Если на каком-то уровне какие-то исключения обрабатываются - то они должны быть убраны из этого дерева. В любом месте кода IDE/компилятор должны уметь сказать: в этой точке могут быть выброшены A, B и, внезапно, Z, потому что на глубинном уровне в 40 коллах от этой функции есть функция, которая кидает Z и никто по пути это исключение не перехватил.

Это всё выше не имеет смысла потому что см. ниже

Компилятор должен запрещать компилировать main, в котором не обработаны все подлежащие исключения

Пользователи будут это «контрить», отлавливая самый базовый класс исключения (Проверено в Java 20 лет назад)

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

За этим - в Dlang (люто-бешено рекомендую)

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