Стоит ли изучать GoLang вместе с изучением алгоритмов?

Question

[Игорь Катков]

Всем привет!
Работаю с PHP/Symfony, возникло желание изучить ЯП совершенно другой парадигмы и алгоритмы для общего развития. Подумал вот о чем - стоит ли для этого выбирать GoLang? Что скажете?

Comments

[Никита]

Вполне норм, а что вас именно смущает раз вы решили задать вопрос?

Answer 1

[Александр Павлюк]

Go не подходит на роль языка "совершенно другой парадигмы". Если хотите такой язык, гляньте в сторону Haskell, Clojure, Lisp.
Go подходит на роль языка с нестандартным ООП и нестандартной работой с многопоточностью.
Для общего развития точно стоит его посмотреть. Прежде всего, он более низкоуровневый, чем ПХП, соответственно, вы сможете увидеть и понять некоторые вещи, о которых раньше не задумывались, которые были незаметны пользователю в ПХП, но тем не менее важны для понимания. Плюс, поработаете с компилируемым языком.

Comments

[Gizmothron]

Какие умные слова которые ничего не значат: "нестандартное ООП, нестандартная многопоточность".

Многопоточность там самая что ни на есть стандартная, известная как гринтреды.

Answer 2

[abcd0x00]

Можешь изучать Python3.x , он как раз и лучше PHP, и хорош для изучения алгоритмов (приближен к псевдокоду).

Подумал вот о чем - стоит ли для этого выбирать GoLang?

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

Comments

[Gizmothron]

А при чем здесь мода?
Он популярен потому что позволяет писать эффективные программы.

[Gizmothron]

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

Серьезные конторы переходят с Python, Node, PHP, Ruby, Java - для уменьшения нагрузки на свои сервера.

Ты предпочитаешь настоящий твидовый пиджак? Он должен быть поношенным, если не в курсе.

[Gizmothron]

Совет изучать Python 3.x - глупость.
Эта версия до сих пор мало распространена. И уже не будет, судя по всему.
Основные вещи работают под 2.7 и только под 2.7

[abcd0x00]

Gizmothron:

А при чем здесь мода?

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

Совет изучать Python 3.x - глупость.
Эта версия до сих пор мало распространена.

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

[Gizmothron]

abcd0x00:

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

Уже поздняк метаться.
3-я не обратно совместима со второй. 2-ая была распространена слишком значительно, к моменту изготовления 3-й. Поэтому в документации в 80% сложных программ на Python до сих пор пишут "Python 2.x only" или "Python 2.7 only"

[Gizmothron]

abcd0x00:

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

Хотелось бы не пересказ чужих слов.

Я надеюсь, вы имеете достаточно опыта с другими языками и уделили достаточно времени на изучение Go? И ваши слова являются не результатами того, что вы знакомы с языком менее месяца?

[abcd0x00]

Gizmothron:

Хотелось бы не пересказ чужих слов.

Сходи в тот топик, там есть некоторые моменты.

3-я не обратно совместима со второй. 2-ая была распространена слишком значительно, к моменту изготовления 3-й.

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

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

Уже поздняк метаться.

Ну, сдохнут эти программы, значит.

Ты не понимаешь, что многие вещи из второго питона удалены ВООБЩЕ, их больше никогда не будет. А ты ему предлагаешь сидеть там и что-то читать про них, ведь они во втором питоне есть. Зачем ему, например, в регулярных выражениях читать про флажок re.ASCII и re.UNICODE, если первый практически никогда не используется (в 99 случаях), а второй вообще не нужен, потому что он только для второго питона актуален. Он всё равно рано или поздно будет на третьем и выше питоне писать, зачем ему эти флажки устаревшие учить?

Уже сейчас добавили интерполяцию строк
f'abcd {name}'
во втором питоне даже зачатков к этому не было. И ты ему говоришь: "Не надо про интерполяцию читать, не надо ею пользоваться. Пользуйся лучше каким-нибудь древним инструментом, который и десятой части этих функций не реализует." С какой стати?

[Gizmothron]

abcd0x00:

Сходи в тот топик, там есть некоторые моменты.

Изучай тему тщательнее, прежде, чем начинать:

1. go fmt форматирует текст табами, а не пробелами. Следовательно, как это будет выглядеть на экране зависит от настроек текстового редактора.

2. readline() в Go делается
примерно так:
reader := bufio.NewReader(os.Stdin)
или так
scanner := bufio.NewScanner(os.Stdin)

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

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

Если я снесу Python27, то у меня перестанут работать: Git, Ansible, Slack, 2 штуки SDK облачных хостингов, YouCompleteMe, Terminator, Paramiko, будут проблемы с Virtual Box, OpenCV и Cairo.
Это при том что у меня минимум софта установлено.

Ну, сдохнут эти программы, значит.

Это серьезный софт, ему никто сдохнуть не даст. И переписывать не будут. Слишком много. Python 2.7 останется основной версий еще много лет.

Нельзя делать настолько несовместимой новую версию. Фактически это новый язык. Такого даже с многострадальным С++ не позволяют делать.

[abcd0x00]

Gizmothron:

1. go fmt форматирует текст табами, а не пробелами.

Серьёзно? А я и не заметил. Я и говорю, что мне нужно, чтобы он пробелами мог отформатировать, потому что я использую пробелы. С пробелами код в любом редакторе с любыми настройкам будет выглядеть одинаково. Понимаешь, go fmt форматирует не только пробелы и мне что-то из форматирования подходит, но опять же я его не могу применить, потому что он мои пробелы заменит. То есть там даже нельзя выбрать, что он должен форматировать из всего множества, а что не должен.

2. readline() в Go делается
примерно так:
reader := bufio.NewReader(os.Stdin)
или так
scanner := bufio.NewScanner(os.Stdin)

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

Если я снесу Python27, то у меня перестанут работать: Git, Ansible, Slack, 2 штуки SDK облачных хостингов, YouCompleteMe, Terminator, Paramiko, будут проблемы с Virtual Box, OpenCV и Cairo.

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

Это серьезный софт, ему никто сдохнуть не даст. И переписывать не будут. Слишком много. Python 2.7 останется основной версий еще много лет.

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

Нельзя делать настолько несовместимой новую версию. Фактически это новый язык.

Они бросились писать на втором питоне, тогда как вторая версия - это слишком сырая версия. Надо понимать, что это ненадёжно в плане развития. Они думали, что третья версия будет совместима со второй (как везде бывает), но питон - это язык постоянных экспериментов (что и делает его гибким), там легко меняют ядро языка. Там вот было две функции - range() и xrange(), это был эксперимент, потому что было непонятно, какую лучше использовать. В результате выбрали второй вариант (посмотрели по использованию в разработке) и оставили только его. А ты предлагаешь "нет, надо было тянуть это за собой ещё 20 лет вперёд".

[Gizmothron]

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

Чем тянуть в прошлое-то? Программа работает и кушать не просит. А вот если ее переписывать начать, то программисты очень много кушать захотят. И даже дело не в зарплате программистов. Если сейчас кинуться такие объемы переписывать, то это только отбросит фирму назад, конкуренты обойдут.

Голый git - не пригоден для работы с коллективом разработчиков: там права никак не разграничиваются. Голый git не пригоден для "непрерывной интеграции": голый git ничего этого не умеет.

Не перепишут. Они не переписывают годами, так как есть в индустрии чёткое мнение, что основной применяемой в production является именно версия 2, а не 3.

Если ты считаешь, что можно обойтись без Ansible, Vagrant/VirtualBox, Slack и SDK одних из крупнейших в мире облачных хостингов, то у меня закрадываются сомнения - а не беседую ли я со школьником. Прости за наезд.

Серьёзно? А я и не заметил. Я и говорю, что мне нужно, чтобы он пробелами мог отформатировать, потому что я использую пробелы. С пробелами код в любом редакторе с любыми настройкам будет выглядеть одинаково. Понимаешь, go fmt форматирует не только пробелы и мне что-то из форматирования подходит, но опять же я его не могу применить, потому что он мои пробелы заменит. То есть там даже нельзя выбрать, что он должен форматировать из всего множества, а что не должен.

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

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

Сервер для многопользовательской игры?

Я работал с огромным проектом на PHP (один из полусотни разработчиков в компании), и не представляю его даже на экосистемах Python или Ruby. А писать такое на Node.js или Go - это просто самоубийство.
Кстати, запрещались любые оптимизации кода, которые шли во вред читаемости ;)

Зачем в языке Go приняты отступы в 8 символов?

вообще, если в Go-community и правда все повсеместно используют 8 символов, то это круто. Просто в моём мире Android-программирования разброда и шатания чуть побольше, посему и сужу со своей колокольни. :)

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

А это все. Строка уже готова к обработка.
Например, можно пройтись циклом. Там тоже элементарно:

scanner := bufio.NewScanner(os.Stdin)
for scanner.Scan() {
fmt.Println(scanner.Text())
}

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

Фортран не тот пример. Он, кстати, до сих пор применяется в научном мире, если ты не в курсе. В физике для моделирования, например. Одни из лучших математических библиотек под него написаны.

Да и Python 2 вполне себе жив и развивается. С момента выхода Python 3 вышли Python 2.6, Python 2.7. Все под него пишется, не переживай.

Язык не должен настолько сильно изменяться. Поддержка легаси-кода - это важно. Скажем, Фейсбук и Контакт не могут просто так взять и уйти с PHP. Поэтому придумывают решение - использовать kPHP. А ведь Фейсбук не беден. Да и Контакт не самая мелкая фирма в РФ. Но даже они не могут себе позволить переписать. Любое изменение кода - это возможность внести в него ошибки.

Много лет назад в нашей стране сделали систему продажи авиабилетов. Она работала не на x86 процессора и PC. Через какое-то время железо, оставшееся от СССР начало выходить из строя, а купить аналогичное западное было слишком накладно. Как поступили? Написали эмулятор. Это оказалось гораздо практичнее. Так как переписывать весь код - это внести кучу новых ошибок. И на эмуляторе система продажи авиабилетов работала много лет.

До сих пор делаются компьютеры и ПО для поддержки вычислений для мейнфреймов. Формально, можно переписать все на современную архитектуру и начать экономить бабло. Но умеющие считать бабулесики и оценивать риски западные страховые фирмы и банки считают иначе. Они подсели на мейнфреймы в еще в 1960-х годах и до сих пор с них не желают слазить.

ИТ-индустрия развивается таким темпами потому что существует огромное количество переиспользуемого кода.

А ты предлагаешь "нет, надо было тянуть это за собой ещё 20 лет вперёд".

Есть определенные вещи, которые не зависят даже от локомотивов индустрии. Никто сейчас в здравом уме не станет переписывать Linux например. Хотя сам Линус и другие умные люди уже неоднократно говорили, что монолитное ядро Линукса слишком быстро растет и становится монстром. И было бы здорово перейти на нечто более микроядерное. Но это уже невозможно без титанических усилий. Никто этого делать не будет. Новые инструменты завязываются на ядро Линукса. Не на более совершенное ядро XNU, используемое в Mac OS X.

но питон - это язык постоянных экспериментов (что и делает его гибким), там легко меняют ядро языка. Там вот было две функции - range() и xrange(), это был эксперимент, потому что было непонятно, какую лучше использовать. В результате выбрали второй вариант (посмотрели по использованию в разработке) и оставили только его.

Никто не мешал оставить обратную совместимость. Например, использовали же в заголовке файла "encoding utf". Никто не мешал также для совместимости встроить там указание на версию Python. Авторы же Питона решили тянуть всех за волосы в светлое будущее.

Это не я так решил. Это так есть. Вся история человечества. Англичанам для того, чтобы хоть немного изменить общественно-экономические реалии пришлось устраивать 2 революции с разницей в более чем век (Английская 17 века и в США в 18) и завоевывать целый новый континет (Северная Америка).

Немного юмора на эту тему

4 фута 8.5 дюйма - ракета или лошадиный зад?

По бокам космического корабля «Кеннеди» размещаются два двигателя по 5 футов шириной. Конструкторы корабля хотели бы сделать эти двигатели еще шире, но не смогли. Почему?
Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому туннелю. Расстояние между рельсами стандартное: 4 фута 8.5 дюйма, поэтому конструкторы могли сделать двигатели только шириной 5 футов.
Возникает вопрос: почему расстояние между рельсами 4 фута 8.5 дюйма?

Откуда взялась эта цифра?

Оказывается, что железную дорогу в Штатах делали такую же, как и в Англии, а в Англии делали железнодорожные вагоны по тому же принципу, что и трамвайные, а первые трамваи производились в Англии по образу и подобию конки. А длина оси конки составляла как раз 4 фута 8.5 дюйма!
Но почему?
Потому что конки делали с тем расчетом, чтобы их оси попадали в колеи на английских дорогах, чтобы колеса меньше изнашивались, а расстояние между колеями в Англии как раз 4 фута 8.5 дюйма!
Отчего так?

Да просто дороги в Великобритании стали делать римляне, подводя их под размер своих боевых колесниц, и длина оси стандартной римской колесницы равнялась... правильно, 4 футам 8.5 дюймам! Ну вот теперь мы докопались, откуда взялся этот размер, но все же почему римлянам вздумалось делать свои колесницы с осями именно такой длины? А вот почему: в такую колесницу запрягали обычно двух лошадей. А 4 фута 8.5 дюйма - это был как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы равновесие колесницы.

Следовательно, вот и ответ на самый первый вопрос: даже теперь, когда человек вышел в космос, его наивысшие технические достижения напрямую зависят от РАЗМЕРА ЛОШАДИНОЙ ЗАДНИЦЫ ДВЕ ТЫСЯЧИ ЛЕТ НАЗАД!

[Gizmothron]

abcd0x00:

Такой большой pivot, который сделали с Python 3, было бы хорошей идеей, если бы это сделали раньше. Еще во времена Python 2. А сейчас уже поздняк метаться.

Ты сам подумай. У тебя есть куча кода. Не 10 или 20 модулей. А действительно огромная куча кода. Туева хуча.
Он нормально работает. Зачем ты его будешь переписывать? Тебе скучно? Ты скорее на пляж пойдешь или девушек кадрить.

Предположим код работает плохо. Причина переписать очевидна. Тебе нужны ресурсы на это. Если твое предприятие активно развивается - ресурсы есть.
Что именно нужно решить в коде? Очевидно, раз предприятие развивается, то это вопросы производительности.

Итак перед тобой дилемма. Нужно решить вопросы производительности, но идеология перехода Python 2/3 требует не просто пропатчить небольшие участки, как это можно сделать с PHP 5/7. Для Python требуется именно переписать код.
То есть тебе нужно все переделать с нуля. И зачем ты будешь для этого использовать Python 3 в наше время? Ведь технологии не стоят на месте. Ты предпочтешь более производительные. Например, Go. Он гарантировано даст большую производительность при той же простоте написания кода.

Другая ситуация. Производительность устраивает. Не устраивает недостаточная гибкость. Тут однозначно придется все написать заново. И опять мы приходим к тому, что у нас нет завязки на Python. Ведь с нуля мы можем сделать на чем угодно.

Поэтому и нет смысла в Python 3. В Python 2 смысл есть. Его держат для поддержки уже существующего кода. И развивают этого код (вынуждено) в рамах 2 версии.
А вот если бы переход от 2 к 3 был такой же плавный как от PHP 5 к PHP 7, то другое дело. Это позволило бы остаться с почти той же кодовой базой.

Оба-на! Да тебе лишь поспорить? Я нахожу противоречие в твоих словах:

Про Go:

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

Про Python:

Они бросились писать на втором питоне, тогда как вторая версия - это слишком сырая версия. Надо понимать, что это ненадёжно в плане развития. Они думали, что третья версия будет совместима со второй (как везде бывает), но питон - это язык постоянных экспериментов (что и делает его гибким), там легко меняют ядро языка. Там вот было две функции - range() и xrange(), это был эксперимент, потому что было непонятно, какую лучше использовать. В результате выбрали второй вариант (посмотрели по использованию в разработке) и оставили только его. А ты предлагаешь "нет, надо было тянуть это за собой ещё 20 лет вперёд".

Неинтересный собеседник. Фу.

[abcd0x00]

Gizmothron:

Оба-на! Да тебе лишь поспорить? Я нахожу противоречие в твоих словах:

Про Go:
...

Про Python:
...

Про питон никто не говорил никогда, что язык сформирован окончательно. По той же причине он не стандартизируется, потому что нет смысла стандартизировать то, что ещё не готово. По той же причине ядро языка так легко меняют, ломая обратную совместимость. Он ещё готовится, а семеро с ложками уже подскочили к кастрюле, а потом возмущаются, что у них невкусно. Ты ему говоришь "все едят баланду, ты тоже ешь". Во-первых, далеко не все, во-вторых, они уже накладывают новое себе. Что, ты не знаешь, что многие вещи уже переписаны на третий питон, а над какими-то работа идёт и они наполовину уже переписаны? У кого не спроси "вы переписываете?", все отвечают "да, мы переписываем".

Ты сам подумай. У тебя есть куча кода. Не 10 или 20 модулей. А действительно огромная куча кода. Туева хуча.
Он нормально работает. Зачем ты его будешь переписывать?

А ты не видел, как KDE переписывали? Его переписывали, не потому что оно было плохим, а потому что оно закупорилось, не имея доступа к новым технологиям. Эмуляторы - это всё равно хрень. Максимум, что ты можешь с эмулятором иметь, так это тот же функционал. Но когда надо будет связать там какое-нибудь древнее с каким-нибудь новым (типа MS-DOS с Wi-Fi), ты просто ничего с этим не сделаешь и будешь сидеть в своём эмуляторе. Что, ты будешь сидеть и разрабатывать что-то новое под MS-DOS?

Никто не мешал оставить обратную совместимость. Например, использовали же в заголовке файла "encoding utf".

В третьем питоне это можно не писать, если у тебя utf-8. Это нововведение третьего питона. А во втором питоне ты ДОЛЖЕН писать utf-8. Когда используется ascii там? Даже у англоговорящих не будет исходник только в ascii никогда, потому что есть куча символов уже, которые могут запросто попасть в комментарии.

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

Никто не мешал также для совместимости встроить там указание на версию Python.

Версию питона ты можешь указывать в шебанге. Или что ты предлагаешь? напихать директив каких-то по всему исходнику? Ха-ха, так вот такую хрень в Go и сделали - это же вообще капец. Это ещё один минус Go, когда ты даже комментарии не можешь писать без оглядки, а то вдруг они там как-то сработают. Это вот очередная глупость или что, я даже не знаю. Или они пьяные были, или их там в Google заставили срочно что-то добавить в язык.

Следовательно, вот и ответ на самый первый вопрос: даже теперь, когда человек вышел в космос, его наивысшие технические достижения напрямую зависят от РАЗМЕРА ЛОШАДИНОЙ ЗАДНИЦЫ ДВЕ ТЫСЯЧИ ЛЕТ НАЗАД!

Ну, ушли от ascii в кодировках. А ты предлагаешь оставаться, потому что кто-то там программы какие-то написал.

Язык не должен настолько сильно изменяться.

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

Фортран не тот пример. Он, кстати, до сих пор применяется в научном мире, если ты не в курсе.

Я в курсе, что у тебя ничего на фортране нет и не будет никогда.

А это все. Строка уже готова к обработка.
Например, можно пройтись циклом. Там тоже элементарно:

scanner := bufio.NewScanner(os.Stdin)
for scanner.Scan() {
fmt.Println(scanner.Text())
}

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

Брателло, ты не прав. Табы позволяют визуализировать код как хочешь.

Да не использую я табы. Где-то я хочу три пробела поставить специально, потому что мне так надо. Ты настроишь? Ты не настроишь. Почему? А потому что настраиваются сразу все табы. А настроить половину исходника в два пробела, половину - в четыре, а изредка сделать по три в некоторых строках, ни в одной программе ты так не настроишь. Это ограничение - если настраиваешь, то все сразу.

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

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

Если ты считаешь, что можно обойтись без Ansible, Vagrant/VirtualBox, Slack и SDK одних из крупнейших в мире облачных хостингов, то у меня закрадываются сомнения - а не беседую ли я со школьником.

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

[qweqwa]

abcd0x00:

Да не использую я табы. Где-то я хочу три пробела поставить специально, потому что мне так надо. Ты настроишь? Ты не настроишь. Почему? А потому что настраиваются сразу все табы. А настроить половину исходника в два пробела, половину - в четыре, а изредка сделать по три в некоторых строках, ни в одной программе ты так не настроишь. Это ограничение - если настраиваешь, то все сразу.

Это целесообразно при одиночной работе. При работе в группе программистов этого нельзя делать. Пример из жизни нашей фирмы. Есть такая замечательная IDE называется Intellij IDEA. Но для Go в ней по умолчанию используется свое форматирование кода, отличное от отраслевого стандарта go fmt. Все программисты у нас идут в ногу, а один ...нецензурное... не в ногу. Не может он видите ли настроить в IDE вызов go fmt при записи. В результате все его коммиты загажены и git не выполняет свою функцию показывать точечно что именно было изменено.

[qweqwa]

Причем это и на других влияет - тех, кто после него коммитит. И автоматическое merge не работат. Вот так один ...нецензурное... тормозит своей дуростью работу всей конторе. Мы уже придумали как с этим бороть - на git-сервере будут хуки. И хрен он что закоммитит теперь, пока не будет делать как все.

[abcd0x00]

qweqwa:

Это целесообразно при одиночной работе. При работе в группе программистов этого нельзя делать.

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

[qweqwa]

abcd0x00:
Группе программистов никто не мешает договориться и вместо go fmt использовать другой форматтер. Но он должен быть единым для всех по причине описанной выше проблемы.
На деле так никто не делает. Незачем совершенно.
Да и читать чужие библиотеки, написанные вне нашего проекта, гораздо удобнее так как во всем мире Go они выглядят единообразно. Все это приводит, в конечном итоге, к повышению производительности труда.

[abcd0x00]

qweqwa:

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

То есть из-за одних пробелов лишиться всего go fmt - вот как это называется. А всё потому, что нет возможности отключать некоторые из преобразований. И с чего они вообще взяли, что текущий формат является идеальным? Современное приложение должно включать в себя файл с настройками формата. Чтобы ты мог просто взять их и поменять под свою команду. А тут просто вшили просто какой-то формат и всё.

На деле так никто не делает. Незачем совершенно.

Это не незачем, а просто возможности такой нет. Никто не хочет писать свой go fmt заново, когда можно взять этот корявый и к нему привыкнуть.

[qweqwa]

abcd0x00:

Это не незачем, а просто возможности такой нет. Никто не хочет писать свой go fmt заново, когда можно взять этот корявый и к нему привыкнуть.

Хочешь быть "не как все" - изволь напрягаться.

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

Если этого мало, то в состав стандартных пакетов Go входит пакет для работы с AST языка Go. На его основе форматтер пишется на раз-два.

То есть из-за одних пробелов лишиться всего go fmt - вот как это называется. А всё потому, что нет возможности отключать некоторые из преобразований. И с чего они вообще взяли, что текущий формат является идеальным? Современное приложение должно включать в себя файл с настройками формата. Чтобы ты мог просто взять их и поменять под свою команду. А тут просто вшили просто какой-то формат и всё.

Я даже знаю почему Линус (автор git) так сделал. Потому что git универсальный инструмент. И для каких-то форматов файлов пробелы крайне важны.

Вам никто не мешает сделать хуки для git под себя. При git push прогонять файл через кастомный go fmt. При git pull еще проще, просто заменять табы пробелами.

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

Вы не прониклись проблемой с коммитами. Разжевываю:

1. Посмотрите репы на ГитХабе, в которых ведется работа настоящими профессионалами своего дела. Посмотрите коммиты. Каждый коммит это несколько строчек. Очень изредка десятки строк. Любой коммит точечный.

2. Это позволяет хорошо видеть как тебе самому (когда ты через месяц забудешь), так и членам твоей команды. Где и для чего и что изменено.

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

4. Посмотрим же что будет, если человек не соблюдает правила форматирования. Он изменил 1 строчку по делу. Остальную часть файла изменил его форматтер. В коммит попал весь файл.

5. После него человек с другим форматирование кода изменил 2 строчки по делу. Остальную часть файла изменил форматтер. В коммит попал весь файл.

6. Получаем месево огромных коммитов, которое противоречит концепции git. Это затрудняет поиск отличий.

7. Это делает невозможным автоматическое слияние малых изменений внесенных двумя людьми, так как их форматтеры сделали изменения не совместимыми.

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

P.S.:
Принцип малых изменений в Git настолько важен, что в некоторых командах ограничивают размер коммита парой сотен строк. Как раз для защиты от подобных ошибок.

[abcd0x00]

qweqwa:

Вы не прониклись проблемой с коммитами. Разжевываю:

Так я не про коммиты говорю. Представь, что у тебя проект, в котором отступ в два пробела. И у тебя там блоки вложены на большую глубину (потому и два пробела, чтобы можно было не думать о глубине). С двумя пробелами они смотрятся хоть где, хоть в настроенной системе, хоть в ненастроенной системе. И даже на github'е через веб-интерфейс они будут смотреться прекрасно. (Ведь ты же знаешь, что на github'е слишком длинные строки обрезаются.) А с go fmt у тебя такие хорошие коммиты, но на github'е через веб-интерфейс ты их не просмотришь.

Вот пример, там как раз такие строки есть, которые вылазят за край. Ну да, сделали там скролл на github'е, которого раньше не было, но не суть. Так вот, они вылазят как раз потому что нужно глубоко вкладывать (это не просто бзик какой-то, а реальная потребность), а отступы в виде табуляций отображаются как восемь пробелов. И не настроишь ты github, чтобы он отображал меньше пробелов на каждую табуляцию.

Поэтому я хочу взять и сделать отступы в четыре пробела во всём проекте (чтобы все программисты-участники писали четыре во всех коммитах). Но этот дурацкий go fmt не даёт мне этого сделать, навязывая свою хрень.

3 минуты - форкаешь, ищешь в исходнике табы, заменяешь пробелами, компилируешь вариант под себя.

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

Если этого мало, то в состав стандартных пакетов Go входит пакет для работы с AST языка Go.

Да написать-то я могу без всякого AST и без всякого Go, но вопрос-то остаётся: почему я в программе не могу отключить один из сотни элементов, который всю картину портит?

[qweqwa]

abcd0x00:

Ведь ты же знаешь, что на github'е слишком длинные строки обрезаются.

Веб-инерфейс ГитХаба никакого отношения к работе с кодом не имеет. Работают локально. В своей репе git.

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

Значит, не 3 минуты, а.... 7 минут.

почему я в программе не могу отключить один из сотни элементов, который всю картину портит?

Если бы он портил картину, то возмущались бы толпы. Возмущаешься ты один. Исходники открыты. Модифицируй под себя как хочешь.

[abcd0x00]

qweqwa:

Веб-инерфейс ГитХаба никакого отношения к работе с кодом не имеет. Работают локально. В своей репе git.

С двумя пробелами (да даже с четырьмя) ты бы так не говорил. Ты бы говорил "какой прекрасный интерфейс!".

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

Если бы он портил картину, то возмущались бы толпы. Возмущаешься ты один.

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

[qweqwa]

А ты не знаешь, что коммиты принято делать с очень короткими заголовками?

потому как их делаешь по 2 десятка в день. придумывать задолбаешься.

Остальные просто этим не пользуются.

все пишут по стандарту и не ворчат.

[abcd0x00]

qweqwa:

потому как их делаешь по 2 десятка в день. придумывать задолбаешься.

Не, просто есть программы, в которые они не поместятся. Поэтому заголовочная строка коммита короткая, а текст может быть шире. Насчёт придумки, так ты не читал просто коммитов Линуса Торвальдса в репозитории git'а. Вот там у него целые произведения на несколько страниц.

[qweqwa]

abcd0x00:
это ядро операционной системы, там и должно быть все прояснено.

над одним коммитом в ОС нужно неделю думать.

с обычным прикладным ПО не так. в день может по три-двадцать коммитов быть. на каждый простыню не пишут.

[abcd0x00]

qweqwa:

это ядро операционной системы

Какое ядро, ты не знаешь, что git разработал Линус Торвальдс? Я тебе не про ядро, а про сам git, у которого есть репозиторий. Вот скачай себе и почитай, как там коммиты пишут.
https://git.kernel.org/pub/scm/git/git.git

[cijiw]

abcd0x00: Когда вы будете таким большим и толстым как Линус и вам будут платить только за имя - тогда и вы сможете заниматься чисто образованием молодых программистов, которые будут ходить в Гит читать ваш код. И что примечательно - вам за это будут платить достаточно денег, чтобы вы не думали о производительности труда. Я согласен с @qweqwe типичные коммиты содержат очень небольшие компактные комментарии.

[abcd0x00]

cijiw:

Я согласен с @qweqwe типичные коммиты содержат очень небольшие компактные комментарии.

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

[cijiw]

abcd0x00: вы предлагаете мержить коммиты без просмотра кода, что ли? ;)

правильный стиль комментирования
https://habrahabr.ru/post/183646/

[abcd0x00]

cijiw:

вы предлагаете мержить коммиты без просмотра кода, что ли? ;)

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

[cijiw]

abcd0x00:
Над какими видами ПО вы работали?

[abcd0x00]

cijiw: а ты какие виды ПО знаешь?

[qweqwa]

abcd0x00: 3 года в ПО - это целые поколения в ИТ, подобные архиологические раскопки случались на моей памяти 0 раз за 10 лет.

[abcd0x00]

qweqwa: три года - поколение? Не видал коммитов, которым по 20 лет?

[guest@localhost main]$ git log1 be840
commit be84045f0780b31d4ff08042daf27c9521ccf393
Author: Guido van Rossum <[e-mail]>
Date:   Thu Aug 9 14:25:15 1990 +0000

    Initial revision
    
    --HG--
    branch : legacy-trunk
    extra : convert_revision : svn%3A6015fed2-1504-0410-9fe1-9d1591cc4771/python/branches/leg

[guest@localhost main]$

Три года - это вообще ничто. Оглянуться не успел, пять лет пролетело.

[qweqwa]

abcd0x00: Существовать коммиты вполне себе могут. Они же кушать не просят эти смешные байты кода (даже не килобайты).

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

[abcd0x00]

qweqwa:

или базовая технология как git

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

[qweqwa]

abcd0x00:
Я уже больше 10 лет читаю....
;)

99% разработчиков в мире занимаются прикладными вещами. Их результат нужен прямо здесь и сейчас.

В 99% случае интересны коммиты не далее чем недельной давности.

Помню пару раз за 10 лет, чтобы интересовали коммиты полугодовой давности.

Проекты готовят к появлению нового разработчика как раз теми методами, которые ты отрицаешь: жесткими требованиями по форматированию кода, например
;)

[abcd0x00]

qweqwa:

Я уже больше 10 лет читаю....

Так а что ты тогда не знаешь такие команды, как blame или bisect? Я постоянно смотрю откуда появилось изменение, кто его внёс. И ссылается оно не всегда на неделю-две. Бывает, что просто надо понять, зачем сделали такой-то кусок, вот отыскиваешь автора и смотришь за его действиями в каком-то там году. Так что...

Проекты готовят к появлению нового разработчика как раз теми методами, которые ты отрицаешь: жесткими требованиями по форматированию кода

Смотри, ты форматируешь отступы в табы, а потом у себя настраиваешь их. У табов преимущество только в том, что они один байт занимают - один оступ = один байт. Но недостатки я привёл выше, и ты сказал, что это github какой-то не такой. Это не github, это форматировщик негибкий.

Answer 3

[Gizmothron]

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

Другая парадигма - это Erlang, Haskell, Nemerle.