Thank Go!
363 subscribers
1 photo
19 links
Неожиданный взгляд на язык программирования Golang от двух продактов. Конструктив от @mikeberezin с нотками сарказма от @nalgeon
Download Telegram
to view and join the conversation
👹 Красавица и чудовище: обработка ошибок в Go. Часть 3

Думаю, авторы языка понимали лукавство утверждений о великолепии обработки ошибок в го. Именно этим можно объяснить их предложение добавить в Go 1.14 функцию try.

Вместо:

f, err := os.Open(filename)
if err != nil {
return ..., err
}


Можно было бы писать так:

f := try(os.Open(filename))


Сложно представить себе более ужасное решение. Оно несколько повышает читабельность кода, но полностью убивает то единственное, что есть хорошего в работе с ошибками в го — тот самый «explicit error checking», который «forces the programmer to think about errors».

К счастью, волна недоумения от сообщества заставила авторов передумать:

> We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.

Аминь.
✍️ Беспощадные строки в Go. Часть 4

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

Возьмём строку в разных представлениях (в байтах и рунах) и попробуем её изменить.
s := "hello"
b := []byte(s)
r := []rune(s)

b[0] = 98 // 'b'
r[0] = 'r'

fmt.Printf("%s %s %s\n", s, string(b), string(r))

>> hello bello rello


А если изменить что-то в строке?
s[0] = "s"

>> cannot assign to s[0]
>> Go build failed.

Компилятор ругается на присваивание элемента в строке. Т.е. не такой уж это и слайс?
На этот вопрос на поможет ответить понимание самой внутренней структуры слайса и строки, посмотрим на неё при помощи рефлексии:
sHeader := (*reflect.StringHeader)(unsafe.Pointer(&s))
bHeader := (*reflect.SliceHeader)(unsafe.Pointer(&b))
rHeader := (*reflect.SliceHeader)(unsafe.Pointer(&r))

>> &reflect.StringHeader{Data:0x4c1fd1, Len:5}
>> &reflect.SliceHeader{Data:0xc00002c008, Len:5, Cap:8}
>> &reflect.SliceHeader{Data:0xc000014020, Len:5, Cap:8}


Видно, что у настоящих слайсов есть ёмкость (Cap), а у строки — нет.
На самом деле строки являются неизменяемыми слайсами. А при конвертации в слайсы байт и рун происходит копирование данных под капотом. Это видно из поля Data, в котором собственно и хранится ссылка на первый элемент массива данных, на котором строится слайс.
🌶 Для тех кто любит острее

Вышло как-то скучно, поэтому добавим перчика.

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

В Го такая возможность есть. И если вам нужно всё-таки сделать изменяемую строку, то вот она:
b := []byte{'h', 'e', 'l', 'l', 'o'}
s := *(*string)(unsafe.Pointer(&b))
fmt.Printf("%T %s\n", s)

>> string hello


Всё честно, это строка. А теперь следите за руками:
b[0] = 's'
fmt.Println(s)

>> sello


Строка и слайс байт лежат в памяти в одном месте, никакого копирования.
fmt.Printf("%#v\n", (*reflect.SliceHeader)(unsafe.Pointer(&b)).Data)
fmt.Printf("%#v\n", (*reflect.StringHeader)(unsafe.Pointer(&s)).Data)

>> 0xc00002c008
>> 0xc00002c008


Внимание! Так делать очень опасно и не рекомендуется. Пакет unsafe отбрасывает систему типов Го и лезет напрямую в память. Это может приводить к очень страшным рантайм ошибкам.

Например, если подобный трюк попытаться провернуть в обратную сторону, то ничего не выйдет:
s = "hello"
b = *(*[]byte)(unsafe.Pointer(&s))
b[0] = 's'

>> unexpected fault address 0x4c1db5
>> fatal error: fault


Без понимания того, как работает коробка передач, лучше ездить на автомате ;)
✍️ Беспощадные строки. Финал

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

В этом коротком, но познавательном сериале про строки и слайсы мы попытались показать их с разных сторон, поверхностно раскрыв некоторые особенности. А из результатов нашего интерактива следует, что не всем такие особенности по душе :)

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

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

Дизайн основных примитивов языка — это фича. Причём у этой «фичи» сразу несколько важных особенностей:
* это самые часто используемые элементы языка,
* сложно сделать что-то слишком выходящее за рамки привычного опыта пользователя,
* дизайн напрямую влияет на перфоманс языка.

Поэтому любые решения всегда будут компромиссом. Между эффективностью, предсказуемостью, понятностью и удобством. При этом в случае языка программирования у вас нет шанса на эксперименты, потому что это противоречит другой важной фиче — стабильности и поступательности в развитии. Основные концепции и дизайн строятся на опыте создателей языка, так было сделано и в случае Го.
🎁 А что в комплекте?

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

И тут очень важна «стандартная комплектация» — набор инструментов и библиотек, которые уже идут в комплекте. Вот и посмотрим на них.

Начнем с gofmt, которая уже упоминалась в канале. Кажется, что это очень простая идея — сделать форматер языка, но она оказалась довольно сильной. В Го полностью отсутствуют холивары о том, какая длина строки верная, где логичнее ставить переносы и отсупы, т.к. сразу был один верный сттандарт, идущий из коробки, который всем ОК.

Это привело к тому, что весь код на Го, даже который ты видишь в первый раз переключившись на внутренности используемой библиотеки, тебе знаком и понятен. Ты сразу визуально понимаешь что и где происходит. Даже горячо обсуждаемые конструкции
if err != nil {
return err
}


оказываются полезными — они делят код на функциональные блоки,
→ что-то сделали
→ возможно получили ошибку
→ что-то сделали с ошибкой


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

Т.е. простая идея встроенного форматера сделала весь код Го скучным и одноликим, но быстро поняным и знакомым.
О, если бы понятность кода достигалась единообразным форматированием 🙂
📜 Главный инструмент

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

Для меня было удивительно то, что в 2019 году 14% разработчиков на Го используют Vim в качестве предпочитаемого редактора.

Ок, а как там у других?

* Rust — 23,6%, ну вроде объяснимо
* Golang — 14%
* JS — 13%, кто эти люди?
* Python — 9%
* Scala — <7,4%
* и наконец C++ — 7%

Раз такое дело, вот прекрасная статья про Vim.
Цитата:

Сколько понадобится времени

Если следовать советам выше и постоянно правильно практиковать вим, то время от «любое действие занимает минуту» до «могу неспешно работать периодически подсматривая в документацию» займет около месяца. Дальше процесс пойдет легче, но останавливаться в развитии на этом этапе нельзя. Оттачивание всех необходимых навыков может занять и год. Но не стоит пугаться. В любом случае через месяц-два вы сможете вполне сносно работать.
💣 Письма в редакцию

Читатель Максим интересуется: как же разработчики Го могут жить без стримов? Stream — понятие из java-мира. Речь идёт о map/filter/reduce подходах из функционального программирования.

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

Хотя в Го и существуют примеры подобных библиотек от комьюнити, но они не могут выглядеть достаточно красиво и удобно из-за отсутствия необходимых возможностей на уровне языка: дженериков и лямбда-функций. Роб Пайк высказал свое мнение по поводу таких интерфейсов довольно давно — пользуйтесь циклами и не парьтесь.

Согласно опросу разработчиков Го 2019 года — фичи функциональных языков (довольно обобщенно) находятся на третьем месте по желаниям разработчиков, сразу после наиболее обсуждаемых дженериков и обработки ошибок.

А что думаете вы? Пользуетесь чем-то похожим в ежедневной практике?
Документация!

С чем у Go действительно всё классно — так это с документацией.

1️⃣ A Tour of Go — интерактивное введение в язык.
2️⃣ Effective Go — книга о том, как писать идиоматичный код на Go.
3️⃣ Ссылки из документации на исходники каждой функции стандартной библиотеки (например, Max).

Для сравнения я взял топ-10 языков из StackOverflow Developer Survey и посмотрел, как у них дела с этими тремя пунктами:

1. JavaScript. У языка даже своего сайта нет ツ Есть миллион обучалок, но единого авторитетного источника — нет. Документация по языку есть только благодаря Мозилле. Ссылок на исходники нет, конечно. Зато по каждой функции есть интерактивный пример, это отлично.

2. SQL. Всё как у JS, только ещё хуже — в мире SQL не нашлось своей Мозиллы, которая бы сделала документацию с примерами. Где свой SQL получали, там и ищите.

3. Python. Первый язык в топе с собственным сайтом. Есть ссылка Get Started, но дальше разбегаются глаза — что выбрать? Вместо рекомендованной авторами базовой обучалки вываливают на новичка простыню ссылок. Официальный туториал найти можно только каким-то нетривиальным способом. Интерактива нет. Незачёт.

Исходников отдельных функций нет, исходники модулей — только если они написаны на Python (например, для heapq исходники есть, а для itertools — нет)

4. Java. Язык принадлежит компании Оракл, этим всё сказано. Заходите на официальный сайт посмеяться.

5. Bash. Не ожидал, но у него есть сайт и документация. Спасибо и на том.

6. С#. Первый язык родом из нового тысячелетия в списке. Есть интерактивный туториал, тур по языку и руководство разработчика. Неплохо! В документации есть интерактивные примеры, а вот ссылок на исходники нет.

7. PHP. Первое, что встречает на официальном сайте — «Please DO NOT use this version in production, it is an early test version». Спасибо, да. Я бы вообще сделал DO NOT use this in production официальным слоганом языка. Кхм, пардон, отвлёкся. Есть неинтерактивная обучалка, неплохая документация со статическими примерами и комментариями сообщества, и, неожиданно — аж целая книга PHP at the Core: A Hacker's Guide.

8. TypeScript. Новейший язык, 2012 года выпуска. Несколько введений, местами интерактивные. Подробный учебник, который начинается как интерактивный, но быстро превращается в статический (wtf?). Ссылок на исходники нет, но они особо и не нужны — у тайп-скрипта нет собственной стандартной библиотеки.

9. C++. Есть интерактивный тур по языку! Шучу, конечно. Тур выложен в PDF, что тут скажешь. Зато есть Core Guidelines о том, как писать правильный код.

10. C. Сайта нет, ничего нет, населена роботами.

Счёт 10-0 в пользу Go.
🌈 Дженерики в Го — история одной фичи

Три главные фичи неустанно обсуждаются в го-комьюнити с начала времён:
* нормальное управление зависимостями,
* дженерики,
* обработка ошибок.

Начиная с Go 1.11, первый вопрос был решён уже в бета-версии, а в релиз Go 1.13 вошла окончательная версия Go Modules — решение всех проблем, связанных с управлением зависимостями и публикацией модулей.

Но вот остальные два вопроса продолжают быть «самыми желанными фичами». Дженерики — лидер с большим отрывом, начиная с 2016 года. В опросе 2019 года за них голосует 79% пользователей! Это невероятный результат для честного голосования (хотя, кто его знает).

Так в чём же собственно проблема? Почему просто нельзя взять и сделать?
Чтобы лучше разобраться в ситуации, пробежимся по основным вехам:

Еще в 2009 году Russ Cox написал от дилемме дженериков:
do you want slow programmers, slow compilers and bloated binaries, or slow execution times

В 2011 году появляется первый пропосал на гитхабе от Ian Taylor — тут следует добавить, что он до сих пор продолжает участвовать в дизайне дженериков (почти 10 лет!).

В 2015 Russ Cox уже не так консервативен и говорит, что просто нужна ещё одна итерация — это чисто техническая проблема.

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

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

Во всей этой истории нам, как продактам, интересно две вещи:
* как обсуждение внутри открытого комьюнити позволяет отследить эволюцию идей и как пользователи могут влиять как в хорошую, так и в плохую сторону,
* как разработчики Го представляют настолько сложную фичу сообществу.

Эти вопросы мы и разберём в следующих постах.
🌈 Дженерики в Го — как показать сообществу сложную фичу

Как видно из предыдущего поста, тональность обсуждения темы дженериков в Го со временем изменялась. Мы знаем из статьи Роба Пайка, что язык задумывался, как инженерное решение для больших проектов. Он должен быть простым и быстрым со строго поступательным развитием — у не должно быть резких и обратно несовместимых изменений в дизайне. Такие тезисы значительно усложняют добавление новых сложных фич.

Если посмотреть на опросы пользователей 2016, 2017 и 2018 года, то будет виден явный рост доли людей, которые не пользуются языком из-за недостатка нужных фич: 11%, 19%, 22%, соответственно. В топ-3 этих фич входили и дженерики. Их не хватает пользователям для построение более сложных абстракций.

И тут получается довольно сложное противопоставление. С одной стороны, у языка уже есть активное комьюнити, в котором ценятся основные его плюсы: простота и скорость. Для них любые усложнения — боль и страдания, а без более сложных абстракций можно и обойтись. Но в какой-то момент рост этих пользователей замедляется и становится видна часть новых ребят, которым не хватает важных фич для использования продукта — для них это блок-фактор. И получаем мы продуктовую задачу: как растить продукт так, чтобы всем было хорошо. Единственный правильный ответ — никак. Всё равно этот путь пойдет через компромиссы. Но его можно и нужно делать более мягким.

Что мы видим дальше?

В 2019 году вместе с драфтом-дизайна дженериков выходит еще и пост (а также и видео на GopherCon от Ian Taylor) с подробным разбором того, зачем же все-таки нужны дженерики, в чём их польза для языка. Это информационная поддержка продуктового развития, начинаем доносить будущую пользу пользователям.

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

Потом мы видим результаты опроса разработчиков 2019 года, в котором уже 79% разработчиков не могут жить без дженериков. Неплохой рост с 22%, правда? Теперь это уже явное желание комьюнити!

Вместе со вторым дизайном в 2020 году выходит в свет версия языка и плейграунд (!) с его поддержкой. Этот шаг вовлекает в обсуждение новых пользователей, которые раньше не находили сил погрузиться в сложное описание. А теперь то уже можно всё потрогать! Появляется большое количество статей с примерами на плейграунде от разных ребят, распространяя фичу еще шире.

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

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

Есть ли что-то подобное в языке программирования Го как продукте?

Не буду тянуть, ответ есть и он очень простой. Как выглядит вызов синхронной функции, печатающей "Hello, world!":

func() {
fmt.Println("Hello, world!")
}()


А вызов такой же функции, которая не будет блокировать основной сценарий исполнения? Знакомьтесь, примадонна Горутина:

go func(){
fmt.Println("Hello, world!")
}()

Окей, а как две неблокирующие функциии могут взаимодействовать с общими данными? Будет же блокировка! Нет, если есть примауомо Канал:

shareData := make(chan data)

go func(in chan<- data){
doSomeWriteTo(in)
}(shareData)


go func(in <-chan data){
doSomeReadFrom(in)
}(shareData)


Это и есть фича х10. Давайте теперь разбираться что тут к чему.
👩‍💻 Примадонна Горунтина

Что же такого примечательного в запуске неблокирующей функции в Го?

Даже в FAQ Го есть ответ на этот вопрос. Главная особенность в том, что в Го неблокирующая функция запускается в горутине, а не в системном треде. Горутина — абстракция Го рантайма, обеспечивающая себя тремя дополнительными функциями и несколькими килобайтами памяти. Поэтому горутин можно запустить миллионы на обычном бытовом ноутбуке, тогда как тредов лишь тысячи.

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

Знаете, в продукте должен быть шарм. Андрей Бреслав — дизайнер языка Котлин — как-то сказал, что функция в Котлине начинается с ключевого слова fun, потому что это fun! И в этом что-то есть.

Но вот fun'а от вызова функции в Котлине я ни разу не испытал (признаюсь, не часто и пытался), но я кайфую от вызова горутины. Вы только посмотрите:

go func(){
someWork()
}()


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

Нарассказывал я вам про фичу х10, но не всё так просто. Нельзя просто так взять и сделать понятную асинхронность. Да, в Го всё выглядит неплохо, по сравнению с другими языками (привет, @ohmypy), но всегда есть но. Дальше давайте разбираться уже на примерах, без них тут ничего не объяснить.

fmt.Println("Hello, Gopher!")
go func() {
time.Sleep(time.Second)
fmt.Println("I'm inside Goroutine!")
}()
fmt.Println("Buy, Gopher!")
// >> Hello, Gopher!
// >> Buy, Gopher!


Воу! А куда делась то наша так просто запущенная горутина? А она просто не успела выполниться до завершения основной функции. И да, main функция тоже работает внутри горутины.

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

В нашем случае поможет WaitGroup из стандартного пакета sync — будем ждать, пока горутина все же отработает.

fmt.Println("Hello, Gopher!")
wg := sync.WaitGroup{}
wg.Add(1)
go func() {
defer wg.Done()
time.Sleep(time.Second)
fmt.Println("I'm inside Goroutine!")
}()
wg.Wait()
fmt.Println("Buy, Gopher!")
// >> Hello, Gopher!
// >> I'm inside Goroutine!
// >> Buy, Gopher!


Вроде справились, но и это не всё. У Го здесь есть свой путь, к которому мы и переходим дальше — каналы.

Если вам интересно подробнее поразбираться с асинхронностью в Го, то в A Tour of Go есть прекраснейший раздел.
Проблемы первого мира! В питоне, если хочешь сделать функцию доступной для синхронного и асинхронного вызова — приходится писать две функции 😐