TL;DR Golang был разработан специально для того, чтобы расцвести в больших проектах, которые пишут большие группы программистов разных уровней, и в мире нет такой группы больше, чем open-source сообщество.
Абсолютно всё в жизни основано на компромиссах — первый закон термодинамики доказывает это, и языки программирования тут не исключение. Компромиссы в Go не уникальны, но именно благодаря их удачному сочетанию, Go и случился. Законы физики также утверждают, что каждое действие порождает противодействие, и, с ростом популярности, также возрастает количество критики в адрес языка, иногда обоснованной, иногда не очень. Позвольте мне объяснить, почему я считаю, что эта критика не важна, и Go обречён на успех несмотря ни на что.
Raison d’etre
Чтобы понять, почему Go таков, каким является, прежде всего вы должны понимать причину его появления.
Целью проекта Go было устранить медленность и неуклюжесть разработки ПО в Google, и таким образом сделать процесс более продуктивным и масштабируемым. Язык был разработан людьми и для людей, которые пишут — и читают, и дебажат и поддерживают — большие программные системы.(источник)
Это и есть единственная причина создания Go, и никакой больше. Это не был 20% проект для развлечения, который случайно попал в струю, это не была попытка достичь чего-то, чего не было сделано раньше. Он просто был создан от разочарования той сложностью, которая неизбежно создавалась большими командами, работающими над большими кусками кода, написанными на языках с большим наборов фич. И каждый компромисс был выбран потому что он следует этим интересам. И если вы недовольны этими компромиссами, скорее всего ваши интересы просто не совпадают и вам не нужно использовать Go.
Хотя одними из наиболее значимых особенностей Go является скорость компиляции или легкая конкурентность (concurrency), всё же главной чертой, которая делает Go особенным является его невероятная простота. Go стремится уменьшить сложность больших проектов Google всеми способами, и делает это жертвуя какими-то вещами — многими вещами — иногда даже принципами, которые вы всегда считали незыблемыми, вроде DRY. Go не такой, как Python или Ruby, которые «позволяют» вам писать понятный код. В Go у вас просто нет другого выбора.
Попробую изобразить на примере. Go — это ваш друг, но не тот друг, который просит вас после вечеринки не садиться за руль, а вызвать такси, Go — это друг, который прерывает вашу вечеринку, говоря вам, что он выбросил весь ваш алкоголь в окно. Go не позволяет вам абстрагировать себя в ногу (abstract yourself in the foot. — orig)
Остальные компромиссы ортогональны. Да, Go не всегда вас сохранит от «состояний гонки», как это сделает Erlang, но Erlang даёт вам эту сохранность ценой постоянного копирования ваших данных, значительно теряя в скорости — TANSTAAFL.
Я, критик
Когда вы читаете критиков, и это касается многих других тематик, вы, как правило, можете их разделить на две категории:
- Жалуется, что Go не оптимально решает задачи, которые ставились перед Go
- Жалуется, что Go не оптимально решает личные цели
И тут действительно есть обоснованная критика, которая целиком попадает в первую категорию. Иногда это вопрос предпочтений. Иногда вещи оказываются гораздо более сложными, нежели люди себе представляют. Иногда авторы Go, которые такие же люди, как и все, просто не сделали это полностью как надо.
Но большинство критиков, которых я встречаю, целиком относятся ко второй категории. И ответ таким критикам всегда одинаков: «Go просто не для тебя». Некоторые люди видят в таком отношении неуступчивость сообщества и нежелание улучшать то, что убъёт Go в долгосрочной перспективе. Они просто не осознают, что другие люди хотят от языка иные вещи.
Очень простой способ обнаружить эти несовпадения интересов — это проанализировать использования слова «Я». Критик, как правило разочарован, потому что «Я» не могу сделать то, что «Я» хочу, «Я» не могу выразить это так, как «Я» хочу. Очень редко вы услышите жалобы на то, что «мы» делаем.
Если вас разочаровывает то, что код становится нечитабельным после того, как над ним в разное время поработали 5 разных людей, или даже ваш собственный код из прошлого, то Go для вас. Если вас разочаровывает невозможность использования трюков ClojureScript, то Go это не то, что вы ищете. Если вас разочаровывает невозможность доказать, что вы круче остальных, то Go уж точно не для вас.
Open-source
Но оставим в стороне личные предпочтения, есть одна группа, которая тут бесспорно выигрывает гораздо больше Google от простоты и дружелюбности Go — это сообщество open-source.
Open-source проекты существуют благодаря вкладу сообщества. Очень малое количество успешных проектов созданы одним разработчиком. В мире open-source вы не нанимаете ваших разработчиков, они сами должны прийти к вам, и, хотя вы и можете выбирать, какие пулл-реквесты/патчи принимать, чем больше вы получаете, тем быстрее вы растёте.
И это то, где Go нет равных.
Go блистает, в частности, в трёх аспектах:
Он поощряет изучать чужой код
Если мы с вами похожи, то вы достаточно часто будете заглядывать в исходники чужих проектов на Github. Просто из любопытства или по надобности, но вы регулярно будете изучать чужой код, чтобы понять, как там всё работает. Иногда вы будете находить простой и понятный код, иногда придется забираться глубже уровень за уровнем, чтобы дешифровать код. Проекты на Go преимущественно будут в первой группе.
Даже если я не собираюсь трогать код, я всегда предпочитаю определенный open-source софт другому просто потому что факт того, что он написан на Go даёт мне чувство гораздо большего контроля над ним. Я чувствую, что в случае каких-то проблем, я не завишу полностью от его автора, который единолично может их решить. И у меня нет такого же чувства с проектами, написанными на языках, которые я знаю гораздо дольше. Для open-source проектов быть написанным на Go — это уже преимущество само по себе.
Go делает легче вклады сообщества
Равные правила игры также дают особенный выигрыш, если вы автор open-source проекта. Go делает процесс ревью merge-запросов гораздо менее утомительным. Утилиты вроде go fmt, golint и go vet оставляют очень мало пространства для персональных предпочтений в форматировании кода. И в целом, Go не даст так просто превратить ваш проект в монстра с тысячью способов сделать одну и ту же вещь. Если вам приходится проверять код случайных людей из интернета, вы не хотите язык с трюками и, скорее всего, вы не хотите людей, стремящихся доказать, как они круты. Вы хотите что-то максимально ясное и очевидное. Возможно даже локальную обработку ошибок.
Go уменьшает страх открыть исходный код
Это хорошо известный момент, что для открытия исходного кода своего проекта, вы должны быть либо рок-звездой в программировании или иметь эго, как у рок-звезды, чтобы противостоять критике. И на самом деле не важно, как хорошо вы пишете код — всегда найдется кто-то, кто его будет ненавидеть и убедится в том, что он это до вас донёс. Это плохой момент, который подвергает стрессу хороших людей, делающих альтруистичные вещи, из-за чего огромное количество исходных кодов остаются в темноте, потому что их авторы боятся, что он недостаточно хорош для стадии релиза в open-source.
Код на Go, как правило, выглядит готовым для публичного открытия гораздо раньше и быстрее, чем в других языках, он даёт гораздо более сильное чувство уверенности и комфорта разработчику, и сообщество принимает простые и небольшие решения, предпочитая их большим и сложным. В целом, Go разбавляет неуверенность разработчиков большим количеством кода, который выходит из тьмы.
Заключительные мысли
Успех Go, на самом деле, уже состоялся. Множество важного системного софта, выходящего в эти дни, написано на Go. OSS-компании, такие как Docker, CoreOS или Hashicorp осуществляют революции в серверах, используя Go, как основной инструмент. Всё больше появляется баз данных, поисковых движков, http-прокси или систем мониторинга. Go уже большой игрок в мире серверного софта и это только увеличивает его богатство.
Если у вас есть претензии к Go, который не оптимально достигает поставленных перед ним целей, даже обоснованные, просто примите, что язык уже не будет изменён. Команда авторов Go чётко и неоднократно давала понять, язык стабилен и закончен на ближайшее обозримое будущее. Вы опоздали на вечеринку. Некоторые могут жаловаться и плакать из-за этого, но это обещание не ломать совместимость даёт в долгосрочной перспективе гораздо больший выигрыш, чем любое мыслимое изменение в языке. Ломающие совместимость изменения, даже из лучших побуждений, далеко не всегда желанны, даже на диком западе разработки Javascript.
Что если вам и в самом деле нравится простота, но парочка из компромиссов Go просто кажутся вам невыносимыми? Тогда, мне действительно жаль, вы можете либо продолжить дальше поиски языка, который идеально подходит под ваши нужды, или, если вы достаточно талантливы, даже создать ваш собственный язык. Кто знает, если достаточное количество людей нуждается в том же, это может даже получить поддержку.
Update Jun 14, 2015
Похоже, эта статья немного наделала шуму. Около 40К посещений в первые 24 часа, и я получил немало отзывов, прямых и непрямых. Я не собираюсь спорить с интернетом, но хотел бы добавить несколько запоздалых ремарок для тех, кто натолкнется на эту статью в будущем.
О значении слова «успех»
Под словом «успех» я не подразумеваю, что Go заменит все остальные существующие языки. Это было бы глупо. Под успехом я подразумеваю, что достаточно большая часть жизни разработчиков будет, если не написание кода на Go, то, как минимум, пользование софтом, написанным на Go. Это моё понимание успешного языка программирования.
О доказательстве моих утверждений
Эта статья была изначально размещена на субреддите Golang, и расчитана на аудиторию уже хорошо знакомую с языком. Доказывать, что Go код прост и легко в поддержке выходит за рамки статьи, и, насколько мне известно, с этим никто не спорит. Мои утверждения могут быть абсолютно очевидны для тех, кто использовал Go, но могут выглядеть абсолютной пропагандой для тех, кто ничего про него не знает.
Я не компетентен в том, чтобы формально доказать достижения Go в плане простоты. Я просто ощущаю их на своём опыте. Если вы и вправду хотите узнать, прав ли я — предлагаю вам пройти Go tour и посмотреть на популярные Go репозитории на Github. Также рекомендую взглянуть на статью Роба Пайка "Less is exponentially more", где он описывает и обсуждает многие из упрощений Go.
Комментарии (96)
yul
14.06.2015 09:52Если вас разочаровывает невозможность использования трюков ClojureScript, то Go это не то, что вы ищете.
В статье по ссылке аргументированная критика языка с реальными примерами, а все что автор этой статьи из этого понял, что «нельзя делать как в ClojureScript»?
Сложилось впечатление, что язык хорош для крупных компаний, которые могут нанять больше человек и получить более-менее стабильный прирост производительности команды.
divan0 Автор
14.06.2015 13:56+3Сложилось впечатление, что язык хорош для крупных компаний, которые могут нанять больше человек и получить более-менее стабильный прирост производительности команды.
Это хороший поинт, и это действительно было одной из задач. Хотя главный пункт был всё же не в том, чтобы «добавить +N людей и получить +N% производительности», а в том, чтобы вновь пришедшие в проект очень быстро могли в него войти, понять и поддерживать без превращения кодовой базы в типичный для таких ситуаций ужас.
Ещё очень часто звучит утверждение, что, мол, наоборот, Go хорош для маленьких проектов, и микро-демоны/сервисы/утилиты очень легко начать и написать за считанные минуты/часы. По моему видению, Go и в маленьких и в больших проектах удачен.
divan0 Автор
14.06.2015 13:26+27Господа минусующие — хочу напомнить, что это перевод. И каждый минус статье без комментария — это только подтверждение слов автора.
Ну а каждый минус мне в карму — это подтверждение частого утверждения, что переводить статьи для Хабра — гиблое дело. Не вопрос же :)
arkandos
14.06.2015 17:33+15Про переводы: тут срабатывает логика уголовного кодекса: раз перевел, значит, согласен, значит, причастен и соучастник.
divan0 Автор
14.06.2015 17:41+4Возможно ) Но всё же это неадекват. Я ещё понимаю, если бы статья была в стиле «хейтерс гона хейт, критики до свидания» — но это, действительно, очень толковая статья, не банальный, свежий и меткий взгляд на long-term эффект дизайна языка на open-source комьюнити.
Взгляд at scale — даже если оно идет в разрез с твоими убеждениями, всё же заслуживает уважения. Ну или, как минимум, здоровой дискуссии, а не тупого минусования.
Подозреваю, что главный эффект тут производят референсы на другие критические статьи — но это, вобщем-то, тема статьи, и автор достаточно виртуозно на них ссылается :)
terrier
14.06.2015 18:59+2Я ещё понимаю, если бы статья была в стиле «хейтерс гона хейт, критики до свидания»
Позвольте, но ведь именно это тут и написано:
Вы опоздали на вечеринку. Некоторые могут жаловаться и плакать из-за этого
Аргумент: «Команда авторов языка неоднократно заявляла, что язык стабильный и чего-то крупного добавлять не будут» просто смешной. Основа команды авторов языка работает в одной корпорации и если ровно одному менеджеру достаточно высокого уровня придет в голову мысль «Надо бы кое-что значительно переделать в golang» команда авторов языка просто и незатейливо возьмет под козырек.
Ну и высказывания типа «Go блистает» с примерами каких-то noname-проектов вообще на грани слишком толстого тролллинга. Вот когда эта ваша CockroachDB подвинет если не Oracle, то хотя бы Redis, тогда можно будет говорить «блистает». Ну а на данный момент Go по популярности конкурирует с такими замечательными языками как EXEC, Forth и Icon
www.tiobe.com/index.php/content/paperinfo/tpci/index.html
TL;DR Автор так восхищенно истекает слюнями по поводу своего любимого языка, что это похоже на толстоватый троллинг
cy-ernado
14.06.2015 19:04+3Docker — noname проект?
Ладно.terrier
14.06.2015 19:06+1Вы используете CockroachDB, blevesearch или Vulcand?
cy-ernado
14.06.2015 19:11+2Я использую Docker, косвенно использую go в: Youtube, сайтах, находящихся за Cloudflare, используюя mongo-tools и MMS, когда мой Google Chrome скачивает обновления, когда мой dropbox синхронизирует данные, когда я пишу в чате на Twitch или захожу на твиттер, когда что-то делаю со своими серверами на DigitalOcean.
terrier
14.06.2015 19:17-1Ок, прекрасно.
Когда вы используете практически любой linux-сервер очень вероятно, что там есть немало строчек на bash. Bash «большой игрок в мире серверного софта»? А кто бОльший игрок Go или bash?cy-ernado
14.06.2015 19:27+3Я вам перечислил не-noname проекты на Go, или включающие в себя существенные сервисы/микросервисы на go (привет 500px), которые я использую. А bash — везде и повсюду в серверах, это факт, и я с ним спорить не буду.
Что я хотел сказать:
Если использовать другие метрики, например, google trends или github stars, то ситуация с популярностью и ее ростом у go будет вам яснее.terrier
14.06.2015 19:47-5Посмотрел в google trends
www.google.com/trends/explore#q=golang%2C%20python&cmpt=q&tz=
Ситуация с популярностью go мне теперь совершенно ясна
ingrysty
14.06.2015 19:53+5Обновляю вашу ссылку — www.google.com/trends/explore#q=%2Fm%2F09gbxjr%2C%20python&cmpt=q&tz=
cy-ernado
14.06.2015 20:01Если пользоваться такими же аргументами, как оппонент, то можно и такую ссылку привести:
вот такую вот.
Получаем, что go — язык богов, и на порядки превосходит по полярности все языки, придуманные до него и после.
PQR
14.06.2015 21:15-1Ваша ссылка слишком обобщена, вот конкретная по programming language; www.google.com/trends/explore#q=%2Fm%2F09gbxjr%2C%20%2Fm%2F0jgqg&cmpt=q&tz=
cy-ernado
14.06.2015 21:17+1Так я специально привел обобщенную ссылку, аналогичную той, что дал оппонент :)
terrier
14.06.2015 20:10Круто, спасибо.
Что ж действительно Go programming language побеждает Python programming language, змею-питона и Монти Пайтона вместе взятых. В битве на гугл-тренде побеждает боксер в синих трусах
divan0 Автор
14.06.2015 19:12+1Вы опоздали на вечеринку. Некоторые могут жаловаться и плакать из-за этого
На мой взгляд это просто констатация факта. Go 1.0 вышел в 2012-м году и тогда было сказано — всё, язык меняться не будет, «we're done». Но при этом, регулярно приходится читать статьи с вопросом «почему меня не слышат». Слышат, но есть некоторая объективная реальность, которую нужно принять.
Основа команды авторов языка работает в одной корпорации и если ровно одному менеджеру достаточно высокого уровня придет в голову мысль «Надо бы кое-что значительно переделать в golang» команда авторов языка просто и незатейливо возьмет под козырек.
Менеджер прийдет к Робу Пайку и скажет «нужно значительно переделать» и в Go поломают обратную совместимость? Хорошая у вас фантазия :)
Ну а на данный момент Go по популярности конкурирует с такими замечательными языками как EXEC, Forth и Icon
Вы неправы. Мы можем спорить про то, что на самом деле меряет индекс TIOBE, но если у вас не возникает когнитивного диссонанса во время сравнения распространения Go, Forth и (что это вообще за языки?) Exec и Icon, то, видимо, вам просто не интересен реальный расклад, и вы о чём-то своём сейчас.terrier
14.06.2015 19:24+1Менеджер прийдет к Робу Пайку и скажет «нужно значительно переделать» и в Go поломают обратную совместимость? Хорошая у вас фантазия :)
Да, добро пожаловать в мир корпоративной разработки. У Пайка, конечно, может быть вариант не согласиться с этим и уволиться. энтузиасты могут сделать 15 форков, но go будет развиваться так как захочет корпорация добра.
но если у вас не возникает когнитивного диссонанса во время сравнения распространения Go, Forth и (что это вообще за языки?) Exec и Icon, то, видимо, вам просто не интересен реальный расклад, и вы о чём-то своём сейчас.
Ну, извините, что убиваю ваших идолов. Понятно, что когда вы пишете на gо и варитесь в этом котле, вам кажется, что все вокруг любят go и go уже почти победил.
Хотите еще больше жестокости?
Вот:
jobsearch.monster.com/search/golang_5? плюс jobsearch.monster.com/search/go-developer_5?
vs
jobsearch.monster.com/search/python_5?divan0 Автор
14.06.2015 19:31-4Да, добро пожаловать в мир корпоративной разработки. У Пайка, конечно, может быть вариант не согласиться с этим и уволиться. энтузиасты могут сделать 15 форков, но go будет развиваться так как захочет корпорация добра.
Если бы подобные утверждения были на чём-то основаны, то был бы смысл спорить.
Ну, извините, что убиваю ваших идолов.
А вы извините, что разрушаю ваши иллюзии о том, что вы убиваете каких-то идолов :)
Хотите еще больше жестокости?
Не хочу вас расстраивать, но пока что в Go-коммьюнити преобладает ситуация, когда ищут Go-программистов, а все гоферы и так заняты.terrier
14.06.2015 19:38+2Так вот в этом-то и проблема, что вам цифры-цифры-цифры, а вы в ответ слова-слова-слова и эмоции и «У меня и у моих друзей все работает»
cy-ernado
14.06.2015 19:51+1Вы привели рейтинг tiobe, в котором популярность у D на порядок выше, чем у Go.
Затем привели ссылки на jobsearch.monster.com
Теперь я попрошу вас, для «consistency», привести запрос к jobsearch.monster.com, который покажет популярность D.
А еще заодно приведу разные метрики.
Go vs erlang vs d vs perl vs python vs rubyterrier
14.06.2015 20:02Теперь я попрошу вас, для «consistency», привести запрос к jobsearch.monster.com, который покажет популярность D.
Я даже сформулировать такой запрос не могу. А что вы пытаетесь доказать в этой битве титанов? Я согласен, что Go, D, Rust еще примерно в одной весовой категории и кто победит — зависит от того, как измерять. Однако эта весовая категория — микроскопическая и выступать с заявлениями типа «Go/D/Rust уже победил и блистает» пока рановато.cy-ernado
14.06.2015 20:21+1Я вот тоже не смог сформулировать такой запрос. А доказать пытался не очень высокую репрезентативность tiobe в контексте ЯП go.
Go победил в битве за свою жизнь. Он выжил и развивается, его используют, популярность увеличивается если не экспоненциально, то линейно. D на мой взгляд — не смог. У Rust битва за жизнь в самом разгаре.
А «блистает» — довольно субьективная характеристика. Для меня блистает, для Александреску блистает D, а go — не нужен.divan0 Автор
14.06.2015 20:22+1Слово «блистает» в статье использовано в очень четком контексте с описанием аспектов open-source мира, в которых Go «блистает». Человек увидел два слова «Go» и «блистает» в одном абзаце и понесло :)
terrier
14.06.2015 20:32Go победил в битве за свою жизнь.
Да, справедливо. Эта фраза могла бы быть использована как заглавие заметно более объективной статьи про Go
divan0 Автор
14.06.2015 19:56+4Вы ищете цифры, чтобы оправдать своё негативное отношение к Go — ок, на здоровье.
Я и еще тысячи людей и компаний по всему миру, благодаря Go уже не первый год делем качественный софт, рубим бабло и получаем от этого удовольствие.
Каждому своё. Никакой проблемы нет :)
На этом дискуссию с вами прекращаю, извините уж.terrier
14.06.2015 20:03-5Какого-то смысла обижаться на объективные цифры нет, иначе однажды выход из уютного мирка, где Go «блистает» и «уже победил» будет весьма болезненным
vsb
15.06.2015 06:23> Основа команды авторов языка работает в одной корпорации и если ровно одному менеджеру достаточно высокого уровня придет в голову мысль «Надо бы кое-что значительно переделать в golang» команда авторов языка просто и незатейливо возьмет под козырек.
Менеджер достаточно высокого уровня понимает, что ему не надо лезть туда, в чём он понимает гораздо меньше других. А если полезет — в гугле хватит других менеджеров ещё более высокого уровня, чтобы сделать правильный выбор между менеджером высокого уровня и Робом Пайком. Гугл это продуктовая компания, а не корпоративная служанка и в приоритетах у него свои интересы.
LeshiyUrban
14.06.2015 15:33+1[ИМХО]
Единственно, чего не хватает в Go — generics. Хотя это, конечно, прямо соответствует идеологии упрощения читабельности (шаблонный код не всегда легко понимается).
[/ИМХО]
lair
14.06.2015 16:49+3Стоп-стоп, так generics (обобщенное программирование) или templates (шаблонный код)?
LeshiyUrban
14.06.2015 17:34+2Так, чтобы можно было реализовать строготипизированную работу с произвольными коллекциями без копипаста и с проверкой типов при компиляции (например очередь как в STL)
divan0 Автор
14.06.2015 17:55+2Ответы на подобные претензии обычно делятся на две группы, и обе достаточно справедливы:
1) Go не против generics — просто авторы Go, при всём своём колоссальном опыте и мозгах, не знают, как сделать generics так, чтобы это было не sucks, как в других языках и не убрало другие достоинства Go. И до сих пор никто не смог предложить адекватное решение.
2) У generics есть достаточно хорошо известные use-кейсы. Там где без женериков совсем плохо — да, Go не подходит. Но на практике — такие юз-кейсы — это доли процента от реальной практической надобности.
Вот взять даже ваш пример — «хочу очередь для произвольных типов». Если вы изучаете теорию языков программирования — то вам это кажется нужным и важным. Если вы пишете сетевой сервис или код для прошивки дрона, в котором вам нужно использовать очередь — как правило, вы её будете использовать для конкретных значений. В реальной практике реализовывать свои контейнеры для всех возможных типов как-правило не нужно. И это, кстати, тема для отдельной дискуссии — когда в языках с женериками, люди используют их к месту и без места, и считают, что это «более продвинутый стиль программирования».
Оба этих ответа дают понимание, того, почему в Go нет generics.
Вообще, на эту тему есть достаточно хороший документ, где собраны все реальные категории того, что подразумевается под словом Generics, известные способы имплементации, с плюсами и минусами — познавательное чтиво. По крайней мере после него будет неудобно сводить generics к темплейтам.
docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#LeshiyUrban
14.06.2015 18:22+3Тут не в теории дело, а чисто в практике: когда пишешь код под int, а в соседнем проекте потребуется string но с аналогичными операциями, копипаст начинает злить и мешать
divan0 Автор
14.06.2015 18:32+2Возможно, но, что я вижу из своего опыта и то, что читаю регулярно в подобных обсуждениях — что это отнюдь не частый кейс.
Вот серьезно, не примите за придирки, но могли бы вы описать хотя бы 5 последних ситуаций, где вам пришлось реализовывать свой контейнер сначала для int, а потом для string? Просто интересно, что за софт вы пишете, где регулярно встречается такая ситуация.
Я легко могу понять разовые отдельные подобные случаи, но если это возникает на практике регулярно — то даже интересно, почему такой частый паттерн или контейнер не учтён.LeshiyUrban
14.06.2015 18:45Софт: бэкенд веб сервисов, «умный дом», прикладная часть драйверов и т. п.. Проекты совсем разные (в т.ч. и заказчики).
Пример:
В одном проекте: сервис, обменивающийся данными по сети с полезной нагрузкой в виде строки (авторизационый сервис).
В другом: схожий сервис, но данные не строковые, а различные числовые данные (int, uint, float и другие результаты замеров).
В будущем третьем: сервис уже с пользовательским типом (драйверная обертка).
Конечно, так или иначе это можно сделать. Но очень много одинаковых компонентов, отличающихся только типом в аргументах функций.
lair
14.06.2015 17:58Ну то есть обобщенного программирования. Не понимаю, в чем там проблемы с читаемостью в таком случае.
4p4
14.06.2015 19:27+8Спасибо за перевод. По теме статьи скажу следущее: можно прочитать эту статью мысленно заменяя Go на название любого другого языка — ничего не изменится. Общие слова ничем не подтверждённые.
divan0 Автор
14.06.2015 19:35+2Я решил эту статью перевести именно потому, что озвученные в ней вещи действительно важны, и совпадают с моими наблюдениями. Только с Go у меня вошло в привычку читать код других проектов — просто потому что в 90% случаев он читабельный, понятный и доступный, только с Go у меня появилось вот это ощущение «если написано на Go — то это сразу +20 к карме проекта», и только с Go я стал опен-сорсить проекты, которые писал для себя.
Автор статьи просто в яблочко попал, на самом деле.
По вашему совету заменил Go на C++, и как-то совсем не идёт :)4p4
14.06.2015 19:37Хорошо) Буду думать, что в Го есть некая загадочная читаемость, достигаемая компромисами и практичностью.
divan0 Автор
14.06.2015 19:46+3Нет никакой загадочности. Напишу, как это вижу лично я.
Вот самый примитивный пример — ternary operator. Удобная вроде штука, во всех развитых языках есть. Выразительно, кратко — сила, одним словом.
Но на практике это приводит к тому, что в 50% случаев ternary operator используют так, что код сложнее прочитать и понять, а иногда из :? творят откровенную лапшу на десятки строк. Да, можно винить программистов и говорить — вы просто плохие программисты. Но если пытаться ответить на вопрос «как получить качественный код?», а не, «кто виноват?», то решение «выпилить ternary operator вообще» в итоге в среднем приведет к более читабельному и понятному коду.
И так практически со всем — от отсутствия эксепшенов до чувствительности к регистру имён переменных.
Эффект «большЕй читабельности» не загадочный, он вполне очевидный.lair
14.06.2015 19:58То есть вы считаете, что с помощью if/else нельзя написать такой же лапши на десятки строк, а необходимость при условных выражениях всегда разделять объявление переменной и присвоение ей значения — не понижает читаемость?
Но вообще, конечно, мне интересно, как именно вы (объективно) измеряете читаемость.divan0 Автор
14.06.2015 20:09+4Можно написать всё. Вовпрос в том, стимулирует язык это делать или нет.
Вот такое (это реальный код) написать с помощью if/else будет очень сложно, и мозг банально из-за лени среагирует на поиск другого решения.
Читабельность не измеряется «объективно», это достаточно субъективная вещь. Но всё субъективное, будучи умноженное на миллионы человеко-часов дают возможность выделить «более правильное» и «менее правильное», хорошие и плохие практики.lair
14.06.2015 20:17А что вы будете умножать на миллионы человеко-часов? На основании чего вы будете выделять?
(А в вашем примере есть очень высокая вероятность дублирования кода между разными веткамиtype is x, что может привести к ошибкам другого рода. Хотя код, конечно, пахнет.)divan0 Автор
14.06.2015 20:19+1Я перестаю понимать ваши вопросы.
Вы вообще не согласны с тем, что код может быть более или менее читабельным? Или вы пытаетесь узнать у меня формулу определения читабельности кода? :)lair
14.06.2015 20:23Я согласен с тем, что код может быть более и менее читабельным. Я не согласен с тем, что для устоявшейся (в мейнстриме) функциональности можно однозначно сказать, что ее невключение в язык гарантированно повысит его читабельность.
Проще говоря, я считаю, что богатство языковых примитивов языка не может ухудшить его читабельность — на фоне общего синтаксиса и семантики это пренебрежимое отклонение.
t0pep0
14.06.2015 20:33+2Видимо Вы никогда не разбирали лапшу из
.map(?:?: rescue) rescue
Завидую Вамlair
14.06.2015 20:36Разбирал. А теперь скажите мне, что именно вы можете сделать с этим языком, чтобы избежать этой ситуации, и при этом не ухудшить читаемость в правильных применениях того же синтаксиса?
t0pep0
14.06.2015 20:42Банально не писать в одну строку подобный код.
А для того, что бы его не писали, в конечном итоге язык не должен содержать конструкций, которые позволяют так писать. В этом случае Go — хороший язык, в нем нет подобных конструкций
Да, и для «добивания» удобочитаемости в комплекте к компилятору Go идут gofmt + govet + golint, которые не только помогут отформатировать код согласно гайдлайну, но и проведут статический анализ (приятный бонус)lair
14.06.2015 20:43А почему вы думаете, что это не ухудшит читаемость в случаях правильного применения? Вообще же, это мне напоминает вечную дискуссию terse code vs sparse code.
(я, к своему стыду, не смог найти, что это именно за язык, и, как следствие, не понимаю, что именно вас фрустрирует)t0pep0
14.06.2015 20:48+1В случае правильного применения ни одна конструкция не ухудшит читаемость. Но обычно на одно правильное применение приходится 15 не правильных.
(Пример был общим, с некоторым уклоном в ruby)lair
14.06.2015 22:02Понимаете, вы с водой выплескиваете ребенка. Вы запрещаете в языке выразительную конструкцию, и тем самым ухудшаете читаемость кода, написанного хорошими программистами.
divan0 Автор
14.06.2015 22:25«выразительная конструкция», которая даже 50% случаях превращает код в месиво — это вредная конструкция.
lair
14.06.2015 23:31+1Любая конструкция в 50% случаев превращает код в месиво. Тупо потому, что большая часть кода, который мы все регулярно видим (конечно, если это не наш код) — месиво.
t0pep0
15.06.2015 00:03Покажите мне месиво в etcd
lair
15.06.2015 00:10-2(Возможно, он просто из меньшей части?)
Но вообще, конечно: github.com/coreos/etcd/blob/master/etcdserver/etcdserverpb/etcdserver.pb.go#L66-L390
(я в курсе, что это кодогенерация, но кого это волнует?)cy-ernado
15.06.2015 00:13+1Вы что, издеваетесь?
lair
15.06.2015 00:21Нет. Я просто показываю, что на любом языке можно породить месиво. Если это может сделать робот, то это может сделать и человек (потому что я видел людей, которые пишут так, что лучше бы это был робот).
cy-ernado
15.06.2015 00:32+1Код там более-менее читабельный.
Хотя он и не предназначался для чтения и тем более модификации живыми существами.
Вы бы еще результат обфускатора какого-нибудь использовали как аргумент.lair
15.06.2015 00:40А это и не аргумент, это t0pep0 попросил показать пример месива из etcd. Я не очень понимаю, зачем к моему исходному комментарию аргументы, мне казалось, он более-менее самоочевиден.
divan0 Автор
15.06.2015 00:53+2Любая конструкция в 50% случаев превращает код в месиво.
lair, чуть выше я спрашивал, считаете ли вы, что код не бывает более или менее читаемым. Вот эта фраза равозначна ответу «да».
Ваша позиция ясна — вы считаете, что авторы Go неправы в том, что убрали различные конструкции из языка, потому что в долгосрочной перспективе они никак не влияют на читабельность кода.
Ни я, ни автор статьи, ни авторы Go c вами не согласны, и на этой ноте предлагаю этот, уже зашедший в тупик (а демонстрация кода автогенераторов — это тупик) тред закончить. Мы не сможем вам доказать «долгосрочный эффект по повышению читабельности» просто потому что это сложная вещь для доказательства — отдельный труд нужно писать и разрабатывать методологию исследования. Я лично для себя справедливость и правильность решения авторов Go ощущаю на ежедневном опыте на собственном и чужом коде. До Go, последние лет 5, для меня «читать код стороннего проекта» практически 100% означало «столкнуться с говнокодом/»персональным" стилем/сложночитабельными конструкциями". В Go это стало приятным ежедневным развлечением, только и всего. Я вам это не могу доказать и нарисовать графики, вы можете лишь поверить или не поверить, что я честен перед собой в своих оценках и абсолютно искренен с вами.lair
15.06.2015 01:00lair, чуть выше я спрашивал, считаете ли вы, что код не бывает более или менее читаемым. Вот эта фраза равозначна ответу «да».
Я, насколько помню, ответил вам что код бывает менее или более читаемым.
вы считаете, что авторы Go неправы в том, что убрали различные конструкции из языка, потому что в долгосрочной перспективе они никак не влияют на читабельность кода.
Нет, я считаю, что позиция «мы уберем эту конструкцию из языка, потому что она плохо влияет на читабельность» может быть ошибочной (потому что оценка long-term effects находится за пределами практически любой компетенции). Я, заметим, ничего не имею ни против Go, ни против принятых в нем design decisions — просто потому, что лично мне не хватает опыта программирования на этом языке.
До Go, последние лет 5, для меня «читать код стороннего проекта» практически 100% означало «столкнуться с говнокодом/»персональным" стилем/сложночитабельными конструкциями". В Go это стало приятным ежедневным развлечением, только и всего.
А вы уверены, что это свойство языка, а не сообщества?
PS. Seriously.
map[bool]int{true: a, false: b}[a > b]
lair
15.06.2015 01:04Даже не совсем так. Не «мы уберем эту конструкцию из языка, потому что она плохо влияет на читабельность», а «есть программисты, которые пишут с помощью этой конструкции говнокод, поэтому мы ее уберем». Вот этот подход меня сильно настораживает.
w0den
15.06.2015 00:42+2Против Go ничего не имею, но, по моему мнению, это самый нелепый аргумент (причём, это касается всех кто так думает — что это, не программист криворукой, а синтаксис языка настолько плохой). Проблема в том, что плохой программист будет писать говнокод на любом языке, а вот профессионалу все эти «ограничения» будут мешать писать по-настоящему хороший код. Вы говорите что «язык стимулирует это делать», но скорее всего, это лень, невежество, дедлайн, маленькая зарплата, землетрясение или всё что угодно, но только не язык программирования.
И потом, посмотрите следующею функцию (я взял её из официального источника где учат новичков что «такое Go»):
func sum(a []int, c chan int) { sum := 0 for _, v := range a { sum += v } c <- sum }
Не знаю как Вы, но я не вижу тут «загадочную читаемость» про которую Вы говорите. Также, как не вижу её в следующем фрагменте кода:
c := (map[bool]int{true:a,false:a-1})[a>b]divan0 Автор
15.06.2015 01:09Не знаю как Вы, но я не вижу тут «загадочную читаемость» про которую Вы говорите
Ладно, похоже, придется копнуть глубже.
Итак, про «читаемость».
Что такое «читать код»? Это понять, что собственно, этот код делает — «скомпилировать»/«запустить» его у себя в голове. Очевидно, что этот навык (чтения кода) может быть как нулевым, так и это может быть супер-натасканный 10-ти летним опытом программист, который беглым взглядом на код STL будет понимать как и что будет исполняться.
Давайте этот навык примем за некоторое число, скажем X. Распределение этого навыка среди людей, в общем случае, описывается гауссианой, с пиком где-то посрединке (среднячок). «Сильные программисты» — это меньшинство, они действительно могут очень быстро «читать» сложные конструкции. И одна из упомянутых в статье ссылок, как раз про критику об этом — мол я, «сильный программист», хочу писать крутой шифрокод, который я могу мгновенно читать, но Go мне говорит, что такой код сложночитаемый -> значит Go считает меня за лоха. Там практически так и писалось, мол Go не дает мне показать, какой я сильный программист.
Но весь поинт в том, что в Google, как и в мире open-source большинство программистов (гауссиана же) не будут в состоянии также моментально и правильно понимать те конструкции, на которые вы натаскали свой мозг. Им, для правильного понимания и дешифрования вашего кода, придется потратить больше усилий, и, потенциально, совершить больше ошибок, прежде чем, строка будет правильно прочитана. Это потери реального рабочего времени, реальные причины реальных ошибок, и стимулы для всевозможных плохих практик. И это мы говорим — о примере одной строки. Умножьте этот эффект на тысячи строк и тысячи рабочих дней и разница и потери станут более понятными.
Поэтому, в интересах авторов Go (с которыми я, к примеру, целиком согласен из своего практического опыта), чтобы, код был легкочитаем для вот той «серединки», для большинства. Чтобы любой человек, который захочет законтрибьютить в мой проект, мог это легко сделать, без того, чтобы иметь за плечами 10+ опыта горьких страданий и ошибок.
Ну отдельно можно расписать то, что плотность кода всё-таки влияет на то, как легко и быстро из него вычленит паттерны ваш неокортекс. Но так как я не читал тут никаких специальных научных исследований, а просто это чувствую на собственном опыте, то, пожалуй, не буду расписывать. Но для меня кажется очевидным, что «проскочить» или «не заметить» или «спутать» один символ в череде очень разнородных символов — гораздо проще, чем в структурированном, разбросанном на несколько строк коде. По крайней мере весь мой эмпирический опыт говорит именно это — я такое «незаметил»/«пропустил» очень много натерпелся в С++.w0den
15.06.2015 02:17+1Извините, но Вы всё усложняйте, и, кажется, слишком глубоко «копнули». Вы написали столько букв про читаемость кода, но кажется Вы даже не читали/поняли мой комментарий. Читайте ещё раз мой комментарий и сообщение на которую я ответил — и заметите, пожалуйста, как и почему я написал слово «читаемость».
Также, прошу заметить, что я приводил две сниппеты написанные на Go, которые, по-моему, Ваши «гауссианы» точно не смогут их моментально понять, как и эту конструкциюgo sum(a[len(a)/2:], c), которая, также взята из официального источника. А приводил я эти сниппеты не потому что считаю их говнокодом, а лишь потому что для меня странно видеть людей которые ненавидят тернарный оператор, но очень легко принимают совершено «необычные конструкции», и при этом считают что язык программирования стимулируют писать говнокод.
И самое главное — для меня «по-настоящему хороший код» это никак не «крутой шифрокод», а простой и оптимизированный код.divan0 Автор
15.06.2015 05:01Ну, поскольку речь шла о «загадочной читаемости», которая появилась до вашего комментария, то и мой ответ был не только вам.
Замысел ваших сниппетов не слишком очевиден, но последний комментарий проясняет. Вы почему-то автоматически мне приписали, что я на любой Go-код вешаю ярлык «читабельный код», и приводите в пример не самый красивый в этом плане сниппет, ещё и обвинили в «ненависти к ternary operator-у».
Постараюсь ответить кратко — речь не идёт о бинарном делении на «читабельный» и «не читабельный», речь о статистической вероятности.
Я понял ваше несогласие с тем, что «та или иная фича способствует её неправильному использованию», но тут я даже не знаю что вам возразить. Мое убеждение в том, что авторы Go не с потолка взяли эти утверждения слишком сильно кореллирует с моим личным опытом. Мне хотелось бы, чтобы такие важные в разработке вещи, как «читабельность кода» можно было легко измерять и формализировать, но пока что это увы не так.w0den
15.06.2015 08:05+2Замысел ваших сниппетов не слишком очевиден, но последний комментарий проясняет.
Да, мне тоже показалось что стоит объяснить почему я этого сделал.
Вы почему-то автоматически мне приписали, что я на любой Go-код вешаю ярлык «читабельный код»
Но разве это не Вы сказали что код Go в 90% случаев читабельный, понятный и доступный? Я не знаю откуда Вы взяли эти цифры, но допустим что это так. Однако, именно данная фраза послужила одной из причин приписывать, как Вы сказали, «ярлык читабельный код».
и приводите в пример не самый красивый в этом плане сниппет
Я взял 2 сниппеты из официального урока, чтобы показать что, даже без тернарного оператора в Go есть другие конструкции из-за которых код также становится не очень читаемым. И если в официальном уроке используются такие сниппеты, что же происходит в «закрытых» продуктах? Неужели там код пишут лучше? Не верю!
Заметите, я не взял просто «не самый красивый в этом плане сниппет», я взял сниппеты которые показывают людям насколько этот язык хорош и, пам-пам, гибкий. Но что же получается — они убрали тернарный оператор, но добавили куча новых конструкций, которые далеко не всегда делают код более читаемым. И разве тернарный оператор не делает ЯП более гибким?
ещё и обвинили в «ненависти к ternary operator-у»
Может я не использовал подходящее слово, но, сначала Вы пишите что в 50% случаев (опять используете какие-то загадочные цифры) тернарный оператор «это плохо» и говорите, что нужно его выпилить если хотим получить качественный код. Далее интереснее — Вы приводите пример кода чтобы доказать что тернарный оператор «это очень плохо» и что язык программирования стимулирует так писать. И наконец, t0pep0 говорит что «Go — хороший язык, в нем нет подобных конструкций». Я могу ошибаться, но раз Вы не видите другие странные конструкции кроме тернарного оператора, я подумал, что вы точно не любите его.
речь не идёт о бинарном делении на «читабельный» и «не читабельный», речь о статистической вероятности.
Если вспомнить историю, то статистика подсказывает почему сейчас на Go написан так мало говнокода. А всё очень просто — сейчас, по сравнению с другими языками, Go используют только немногие и как я заметил, большинство из них действительно профессионалы. Но что будет, когда неопытные программисты (или индусы) будут переходить к Go? Вы думаете, отсутствие тернарного оператора будет сдерживать их написать говнокод? Или, может быть они больше не будут использовать по 1000 строк if/else вместо простой функции или цикла?
Я понял ваше несогласие с тем, что «та или иная фича способствует её неправильному использованию», но тут я даже не знаю что вам возразить. Мое убеждение в том, что авторы Go не с потолка взяли эти утверждения слишком сильно кореллирует с моим личным опытом.
Что бы не говорили авторы языка Go, я никогда не поверю что в Go отсутствует говнокод поскольку он не поддерживает тернарный оператор (также как в других ЯП много говнокода из-за того что он поддерживается). Можно посмотреть на том же govnokod.ru, вряд-ли там так много примеров с использованием тернарного оператора. А вот чтобы подискутировать насчёт «потолка» — нужно открыть новую ветку комментариев, ибо, как мне кажется, тернарный оператор не используется в Go совсем по другой причине :)
Мне хотелось бы, чтобы такие важные в разработке вещи, как «читабельность кода» можно было легко измерять и формализировать, но пока что это увы не так.
Полностью согласен с Вами. И я очень рад за это.divan0 Автор
15.06.2015 09:40+3Но разве это не Вы сказали что код Go в 90% случаев читабельный, понятный и доступный? Я не знаю откуда Вы взяли эти цифры, но допустим что это так.
В том-то и дело, что цифры я эти беру исключительно из личного опыта, и потому нахожу себя в несколько неловком положении, когда меня просят «а докажи?». Автор статьи тут, наиболее правильно поступил — написал, мол, не считаю себя компетентным в том, чтобы предоставить формальное доказательство — я просто это ощущаю на собственном опыте.
Касательно приведенных сниппетов. Первый (sum()) — это очень понятный и прямолинейный код. Его сложно прочесть или интерпретировать неправильно, он оставляет мало места для ошибочной трактовки, даже если вы плохо знаете язык, в нем сложно «пропустить» одну букву и неверно истрактовать. Это хороший и идиоматический для Go код.
Второй сниппет — я не знаю откуда вы взяли, но это образец того, как не нужно делать, и я лично такой код не встречал.
Я могу ошибаться, но раз Вы не видите другие странные конструкции кроме тернарного оператора, я подумал, что вы точно не любите его.
Тернарный оператор служит хорошим примером того, какими ценностями руководствовались авторы Go, для достижения целей, описанных в начале статьи. Да, я не спорю, что:
foo := bar ? 1 : 0
выглядит приятнее, чем
foo := 0 if bar { foo = 1 }
Но из многолетней практики очевидно, что ternary operator используется не только для таких случаев. Он используется и тогда, когда if/else действительно должен быть более читабельным, и для вложенных проверок, и как аргумент функций и как возвратное значение, и как угодно ещё, делая код — по общему консенсусу хуже. Приведенный чуть ранее пример — лишь демонстрация этого.
И логика авторов Go звучит примерно так: «плюсы от возможности написать в 10% случаев чуть более краткий код, не перекрывают минусы от того, что в 90% код будет становиться хуже».
Но что будет, когда неопытные программисты (или индусы) будут переходить к Go?
Мне понятен ваш песс… реализм, основанный на опыте с другими языками, но такое опасение было бы действительно обоснованным, если бы Go концептуально не отличался от тех языков, которые прошли через подобное. Я не помню на своей памяти, язык, который бы хвастался тем, что у них меньше всего фич и он проще всех.
Эффект тут такой, что в Go уже повалило много людей, которые поняли, какие они получают плюсы и бенефиты, без того, чтобы становится бородатыми хардкорщиками. У Пайка есть даже статья о том, почему С++-программисты неохотно переходят на Go, и основной приток гоферов — с языков вроде Ruby, Python и PHP. Так что в Go уже большая часть комьюнити — это народ далеко не гении PLT, хотя действительно умных людей тоже немало.
Скажу так — Go позволяет легче делать production level код, и быть в нём уверенным. Для того, чтобы выдать качественный код на Go не нужно «5+ лет опыта» и 5 прочитенных «Библий Go».
Ну и, чтобы ещё уменьшить ваши опасения — посмотрите на вопрос с другой стороны. Роб Пайк и Ко фактически поставили это главной целью языка — сделать так, чтобы новичкам было сложно писать плохой код. Описывать опыт и достижения Томпсона и Пайка, думаю, не стоит — но я их опыту доверяю, и считаю, что если они поставили какую-то цель, разрабатывая язык, то это нифига не случайность, что все, кто этим языком пользуются, пишут слово в слово про эту цель.
Ну и последнее — лично я не теоретик, я практик. Я не привязываюсь к технологиям и вещам, и легко беру новые более эффективные инструменты, если такие появляются. Go мне дал возможность очень быстро делать очень качественный софт, при этом получая тот фан, который я давно уже потерял от программирования. И похожих альтернатив пока я не вижу даже на горизонте.w0den
15.06.2015 20:16+2К сожалению, продолжать дискуссию не имеет смысла (по крайнее мере, я этого больше не хочу). Но вот что я скажу вместо заключения:
Во-первых, Go не так популярен как Вам кажется. Когда на нём будет написан по крайнее мере 5% когда который написан, скажем, на JavaScript, тогда можно ещё посмотреть насколько Go хорош в этом плане. Плюс, насколько я знаю, те, кто раньше писали на другие языка и перешли к Go, являлись хорошими профессионалами в своей области и раз уж не писали говнокод, скажем на PHP, то и логично что не будет писать его ни на Go, ни на другом языкке.
Во-вторых, цифры должны быть подкреплены фактами. Я уважаю Ваше мнение, но когда речь идёт о таких цифрах как 90% или 50% — мне кажется что они взяты из «потолка»
В-третьих, если бы Go был бы так идеален, можно было бы открыть случайные репозитория и не найти там ни одной строки плохого кода. Но, увы, это не так.
И последнее, я специально потратил пару минут чтобы посмотреть пару репозиторий на GitHub. Открыл самые популярные и посмотрел только первый попавший файл — честно, я не заметил чтобы тут сработала так называемая «защита от написания плохого кода»:
И так, первый у нас docker*:
if !MatchesContentType("application/json", "application/json") { t.Fail() } if !MatchesContentType("application/json; charset=utf-8", "application/json") { t.Fail() } if MatchesContentType("dockerapplication/json", "application/json") { t.Fail() }
Потом syncthing*:
case "setup": setup() case "install": pkg := "./cmd/..." var tags []string if noupgrade { tags = []string{"noupgrade"} } install(pkg, tags) case "build": pkg := "./cmd/syncthing" var tags []string if noupgrade { tags = []string{"noupgrade"} } build(pkg, tags) case "test": test("./...") case "bench": bench("./...") case "assets": assets() case "xdr": xdr() case "translate": translate() case "transifex": transifex() case "deps": deps() case "tar": buildTar() case "zip": buildZip() case "deb": buildDeb() case "clean": clean() case "vet": vet("./cmd/syncthing") vet("./internal/...") case "lint": lint("./cmd/syncthing") lint("./internal/...")
Далее идёт сам golang*:
const exitstr = "exitcode=" cmd := `export TMPDIR="` + deviceGotmp + `"` + `; export GOROOT="` + deviceGoroot + `"` + `; export GOPATH="` + deviceGopath + `"` + `; cd "` + deviceCwd + `"` + "; '" + deviceBin + "' " + strings.Join(os.Args[2:], " ") + "; echo -n " + exitstr + "$?" output := run("shell", cmd)
И последний которого посмотрел, gogs*:
case "": priv, err = rsa.GenerateKey(rand.Reader, ctx.Int("rsa-bits")) case "P224": priv, err = ecdsa.GenerateKey(elliptic.P224(), rand.Reader) case "P256": priv, err = ecdsa.GenerateKey(elliptic.P256(), rand.Reader) case "P384": priv, err = ecdsa.GenerateKey(elliptic.P384(), rand.Reader) case "P521": priv, err = ecdsa.GenerateKey(elliptic.P521(), rand.Reader)
Я прекрасно понимаю, что ни один язык программирования не идеален и плохой код существует везде. Но, повторюсь ещё раз — то что некоторые пишут говнокод это не проблема языка. И то, что на других языках написано больше плохого кода, чем на Go, никак не связано с отсутствием/наличие тернарного оператора.divan0 Автор
15.06.2015 21:03+1Да ничего, на самом деле с Вами интересней всего из всех комментаторов тут было общаться.
Насчёт «Go не так популярен, как мне кажется» — мне не кажется, и я думаю, что достаточно объективно вижу картинку. Go достаточно уверенно занимает свою основную нишу (системный/серверный софт) и постепенно осваивает новые ниши — и мне важно то, что уже написанного софта и библиотек достаточно, чтобы не упираться в отсутствие каких-то важных библиотек, и что лично я для всех моих задач (а я, в основном, серверным софтом занимаюсь) получаю благодаря Go результат.
Тоесть фразы вроде «Go не так популярен» или «вот посмотрим на него, когда он вытеснит все другие языки» — мне просто не релевантны. Go для меня уже состоялся и экономит массу времени, которое для меня есть синонимом к «деньги» :)
Но популяризировать я, по мере возможности, всё же Go хочу и буду, потому что масса толковых людей просто ещё даже не знают, что такой язык существует. Больше статей, больше комьюнити -> больше качественного кода и счастливых девелоперов -> профит :)
А все приведенные ваши примеры — это не говнокод. Это то, что Брукс в своем знаменитом труде «No silver bullet» называл "essential complexity" — та составная сложности задачи, которая происходит из области проблемы, а не от выбранного инструмента. От этой сложности не уйти, каким языком её не решай. Если вам нужно поддерживать N алгоритмов генерации ключей — нет такого языка, где вы все N вариантов напишете одной командой. Зато вторая составная — "accidental complexity" — которая привносится инструментом, вот эти все обертки/классы/расходы на ручной менеджмент памяти и декодинг фичастых конструкций — это то, что можно и нужно уменьшать. Вообще эта тема отдельной статьи заслуживает.
Надо написать, спасибо за идею :)
t0pep0
15.06.2015 10:45+1И потом, посмотрите следующею функцию (я взял её из официального источника где учат новичков что «такое Go»):
Простите, а что здесь не понятного?
Также, как не вижу её в следующем фрагменте кода:
Да, согласен, код пример того, как писать не надо.
Если вам станет легче, то такой код нужно заменить на
c := a - 1 if a > b { c = a }
Но сдается мне, что указанная Вами строка была написана кем-то специально, что бы показать, что и такие извращения возможны. Тут однако встатет вопрос о том, что если захотеть можно написать говнокод на любом языкеcy-ernado
15.06.2015 13:33Мне вот тоже не очень ясно, что там такого непонятного в приведенном куске кода, кроме пропуска переменной для номера элемента массива.
Если захотеть, можно написать обфускатор на go и пропускать через него все свои коммиты, специально отстреливая себе ногу вместе со всем остальным телом. Самое смешное, что и сгенерированный код для бездушных машин (protobuff), и вещи
c := (map[bool]int{true: a, false: a - 1})[a > b] // причем именно так оно выглядит после go fmt, а то что вы привели - неизвестно откуда.
выглядят относительно адекватно, хотя подобную конструкцию я вижу первый раз (а пишу на go я уже больше года в продакшене, и с 2012 — вообще)
Но go fmt этот обфусцированный код сформатирует по-человечески, а go vet не пропустит достаточно много.
P.s. немного промахнулся с тем, кому отвечал, извините
areht
24.06.2015 02:15-1> Вот такое (это реальный код) написать с помощью if/else будет очень сложно
Легко, надо просто написать соответствующие if/else в одну строчку. Если у писавшего это человека мозг из-за лени не пошел искать другое решение — у меня для мозга плохие новости…
t0pep0
14.06.2015 22:41+3В тему C++
Однажды я пытался создать list<map> и мои синтаксические ошибки подняли мёртвых из могил
http://habrahabr.ru/post/203276/
m52
15.06.2015 15:33Автор говорит о суперчитабельности. По совету выше начал проходить Тур оф Го и вижу пример:
func split(sum int) (x, y int) {
x = sum * 4 / 9
y = sum — x
return
}
(код не форматируется у меня)
И читаю объяснение:
> Naked return statements should be used only in short functions, as with the example shown here. They can harm readability in longer functions.
Ну ведь сами понимают, что это снижает читабельность (лично для меня даже эта микрофункция уже не очевидна), нахера такое вообще вводить? Что, написав return x, y код как-то жутко усложнился?t0pep0
15.06.2015 19:39+1Naked return statements should be used only in short functions, as with the example shown here. They can harm readabilit y in longer functions.
В грубом переводе — return без аргументов можно использовать только в коротких функциях, в длинных это ухудшит читаемость.
А в коротких функциях иногда и правда return без параметров бывает аккуратнее
t0pep0
15.06.2015 19:43З.Ы. В настоящее время сообщество работает над переводом тур оф гоу, надеюсь после этого будет меньше таких не понятных ситуаций
m52
15.06.2015 21:57Эмм… лол. Я понял о чем там говорят, мне не нужен перевод.
> А в коротких функциях иногда и правда return без параметров бывает аккуратнее
Я не знаю что вы подразумеваете под «аккуратностью», но эти их нейкед ритёрн ухудшает читабельность и понятность любой функции — и большой, и маленькой, при этом никакого профита не дает. И не надо тут ничего выдумывать про какую-то там аккуратность.
sandricmora
Немного не понял про трюки на clojurescript. В чем там именно трюки состоят? И причем тут clojurescript? В том, что для csp в clojure легче описывать сложные concurrency абстракции с помощью core/async, чем в go, или там что то другое подразумевалось? В любом случае, именно c clojureSCRIPT сравнение как по мне странное. И вообще, представляю как ОТР эрланга после такого думает «вот щас обидно было».
З.Ы. Со всем уважением к terraform от упомянутой в переводе hashicorp (которую я искренне люблю, как и go), все же ее наиболее популярный продукт — vagrant, написан на руби, и это не мешает ему «осуществлять революции в серверах».
divan0 Автор
Там референс к примеру из статьи, в которой есть фраза «I frequently use in ClojureScript code tricks like» и вообще, Качаев знатный функциональщик, и часто ругает Go, за то что в нём нельзя делать то, что можно в функциональных языках
С vagrant-а начался Hashicorp, Go тогда был ещё в зародыше и Хашимото выбрал наиболее подходящий на тот момент инструмент. Про будущее руби отдельно можно писать, но в целом утверждение «на руби тоже есть клевые серверный софт» никак не противоречит статье :)
cy-ernado
А как vagrant относится к осуществлению «революции в серверах», если он де факто — development environment?
sandricmora
Так, что в нем есть команда push наверно. Не знаю правда подпадает ли это под «де факто».
cy-ernado
Это не относится к серверной части инфраструктуры