Я вижу, и для меня это очень простая вещь, это то, что я хорошо чувствую по себе, и вижу в других.
Но почти всегда, когда я пытаюсь объяснить, что на решения людей влияют другие факторы, которые рождают или отбирают стимулы — находится масса людей, считающих, что я несу бред. Видимо пока плохо умею объяснять такие простые вещи.
Их нет именно поэтому. Да, более продвинутый формат комментариев даёт больше информации докогенераторам, но он так же порождает стимул вообще не писать эти комментарии.
Комментарий же в Go выглядит простым нативным однострочным комментом для людей, без необходимости отвлекаться от кода и расписывать что-то в нужном формате — и это порождает стимул это делать всегда и всюду, что имеет очень долгосрочный эффект.
Это большая разница, в итоге.
Любое ограничение в Go, как правило является тщательно продуманным и обсуждённым компромиссом, и плюсы, которые появляются благодаря этому решению, значительно перевешивают минусы, только и всего.
Не буду спорить, хоть мне и кажется важность этого момента излишне надуманной — единственный случай, где может случиться вот это «читаю начало строки и вижу» — это grep по имени функции (без параметра -C). В остальных случаях — в коде, в диффах, всегда виден предыдущие строки.
Но в целом такое ограничение — это результат грамматики языка. «Под капотом» Go использует точки с запятой, но их писать не обязательно — перед компиляцией Go «расставляет» точки запятой, и правило там такое — если в конце строки стоит идентификатор или один из токенов из списка (break continue fallthrough return ++ — ) }), то точка с запятой вставляется. Вот тут подробнее: golang.org/doc/effective_go.html#semicolons
Как я понял, суть аргумента в количестве библиотек.
Неверно поняли.
кстати, в Go ведь веб-фреймворки умеют делать hot swap во время разработки
Умеют.
С другой, а много вы тратите времени на деплой?.. час-полтора… Я думаю, можно пережить.
Да всё можно пережить. Но рынок движется другими силами.
Там выше ещё упоминали преимущество документации Go. Не знаю, насколько вы знакомы с экосистемой Python, но найти незадокументированные проекты довольно сложно.
Я очень рад за Python, что в третьей версии в нем достаточно неплохо обстоят дела с документацией. И я на самом деле желаю Питону долгих лет жизни, тем более, что и сам на нём писал. Но, пожалуйста, не воспринимайте посты про языки программирования отличные от Питона как критику в адрес последнего.
Все аргументы в стиле «а вот посмотрите, в языке Х фича Y тоже хорошая» заведомо обречены, потому что преимущество Go не в том, что в нём все мыслимые аспекты и фичи программирования на порядки лучше и качественней, чем в других языках программирования. Нет, и ещё раз нет.
Преимущество Go в сочетании тех или иных решений, которые именно в этом сочетании позволяют решать широкий круг актуальных для нашего конкретного времени, наших конкретных реалий и экосистем, задач, реальными не-сверх-идеальными программистами, и делать это быстро и качественно с минимальными затратами.
Поэтому, серъезно, никто не оспаривает то, насколько Питон классный язык — и по многим пунктам Zen of Python, они даже близки с Go — но примите плюрализм технологий как что-то хорошее, а не плохое. Все технологии, набирающие популярность, набирают её по какой-то объективной причине, хотите вы этого или нет, понимаете вы это или нет. И лучше их понимать.
Кроме того, особенно если вы ведете курсы по Питону — познакомьтесь с Go ближе: даже если вы не будете на нём писать, ваши познания и авторитет от знания ещё одного весомого современного языка программирования только вырастут. Тем более, что с Go на это нужно гораздо меньше времени.
Ясно, ну я продолжать не буду с таким количеством guesswork — а вот когда расскажете алгоритм, то будет интересно его таки имплементировать и сравнить результаты.
Про бенчмарки, тесты и прочее я специально упомянул, что это хоть и «не особо нужно», но это слишком просто делается в Go, чтобы это не делать всегда :)
Кстати, солидарен с комментом выше, я бы тоже сделал веб-сервис, который бы и обновлял данные при поступлении новых, и обрабатывал запросы на проверку.
а) размер файла по ссылке там 1Гб
б) 0.004 секунды на весь поиск? Это означает, что данные как-то подготовлены уже. За такое время даже считать диска ни один самый шустрый IO не даст.
А, ясно. Хотя тогда непонятно требование к «не российскими паспортами можно(нужно) пренебречь».
Вообще, вот такое «сравнение» по хорошему вы должны сделать самостоятельно — всё таки для сравнения производительности такой задачи, как «перелопатить csv» файлик, тут важнее выбрать правильный подход к задаче и правильно оценить компромиссы между нагрузкой на IO, CPU и памятью. Не говоря уже о том, что если файл обновляется раз в сутки, то лучше его один раз отсортировать/свести и все проверки делать уже на подготовленном датасете. Тоесть или вы имплементируйте — или опишите точно ваше решение.
К примеру, решение «в лоб» у меня отняло 15 минут, но оно, явно не самое эффективное, и можно оптимизировать. Задействуется 1 кор CPU, полный проход на моем макбуке занимает 2m23s. Хотя это решение — полноценный тул, с тестами, бенчмарком, комментариями, обработкой параметров командной строки и обработкой ошибок.
Но если ваши главные требования «минимум оперативки и минимум cpu» — то это лучше на C делать. Все-таки Go жертвует немного памятью и cpu, в пользу простоты языка — и это был сознательный компромисс. Сейчас актуальнее экономить время и силы, потраченные на реализацию кода, а не килобайты ОЗУ, которое, в сравнении со стоимостью человеко-часа сейчас совсем дешевое.
По поводу вашего условия — а алгоритм определения «хороший/плохой» укажите, а то пока ясно только, что 0000000000 — хороший, а 0000000005 — плохой :)
Ничего не скажешь, невероятно сложный синтаксис, несколько лет надо учить.
Можно иронизировать, а можно принимать реальность, как данное. Именно это приводит к тому, что многие статьи про важность документирования кода иронично начинаются словами «Всем известно, что документация важна, но её никто не пишет».
Можете ли как-нибудь доказать этот тезис?
Нет. Это мой опыт, и вы имеете право ему не верить, и считать, что я выдаю желаемое за действительное. :)
Окей, попробую своими словами. Для меня главное отличие godoc в двух вещах:
Не нужно учить специальный формат комментариев. Можно спорить и доказывать, что это я лентяй, но это так. Я пробовал, и на практике мне мое время было дороже для кода, чем для вспоминания, как правильно писать код.
Кроме того, тут еще важный момент, который мало где озвучивается — когда я пишу код, мне документация к нему не нужна. Я не хочу прерывать код, чтобы запустить докогенератор и любоваться на него в браузере. Может он мне вообще никогда и не понадобится. Все это уменьшает приоритет важности «писать документацию по ходу написания кода».
В Go это не так — я знаю, что мне достаточно написать одну строчку перед функцией и это тождественно «у тебя есть отличная документация к ней и она будет на godoc.org». И это game-changer — это стимул и мотивация потратить 10 секунд и получить максимум.
не нужно ничего ставить, настраивать, возиться и деплоить. Тут, надеюсь, не нужно объяснять. Аргумент «та там три секунды ставить» как тут выше уже пишут про деплой («я просто баш скрипт на 10 строк написал и запускаю с рабочей машины, так что не нужнен весь ваш девопс вообще») — я не принимаю.
По поводу дотнета — подключаете библиотеку и в интеллисенсе сразу видите контексно-зависимую документацию по тому что набираете. Вплоть до уровня аргументов у функций. Го, очевидно, так не умеет, в силу отсутствия тегов.
В Go все библиотеки доступны в виде исходных кодов, там такая задача даже не стоит.
Ну и да, дотнет (для меня лично) — даже не рассматривается как вариант для системного софта, поскольку это инструмент заточенный под экосистему MS и, даже оставив все последствия этого, необходимость иметь специальную дев-среду для того, чтобы мочь посмотреть документацию, для меня звучит, как страшный сон. Хотя в мире/экосистеме MS/.Net удобно наверное, да.
Нет.
И я продолжаю не видеть связи между слакой, маком, командой chown и go get. И даже, если я сейчас эту многоходовочку мыслей ухвачу, мне все равно вывод «пользователей мака тянет к слаке» кажется очень неверным :)
А вообще ерунда это всё. В моём последнем проекте скрипт деплоя состоял из пары десятков строк на баше. Релиз выкатывается запуском ./release.sh на моей машине. Времени настроить это всё — ну несколько часов от силы. Не те масштабы, чтобы предоставлять статический бинарник, как нечто прорывное.
Вы просто хотели рассказать, как вы решили вопрос деплоя в своем проекте или вы понимаете вопросы, которые стоят перед мировым dev/devops-сообществом, понимаете, что в масштабе миллионов есть потребность эти процессы упрощать и сокращать, и считаете, что все должны выбрать ваш подход?
Хорошо, давайте спрошу иначе — почему большая часть кода на Go документирована, а большая часть кода на Python или Java — нет? Или вы будете с этим спорить, и требовать «доказательства»?
Но почти всегда, когда я пытаюсь объяснить, что на решения людей влияют другие факторы, которые рождают или отбирают стимулы — находится масса людей, считающих, что я несу бред. Видимо пока плохо умею объяснять такие простые вещи.
Их нет именно поэтому. Да, более продвинутый формат комментариев даёт больше информации докогенераторам, но он так же порождает стимул вообще не писать эти комментарии.
Комментарий же в Go выглядит простым нативным однострочным комментом для людей, без необходимости отвлекаться от кода и расписывать что-то в нужном формате — и это порождает стимул это делать всегда и всюду, что имеет очень долгосрочный эффект.
Это большая разница, в итоге.
Любое ограничение в Go, как правило является тщательно продуманным и обсуждённым компромиссом, и плюсы, которые появляются благодаря этому решению, значительно перевешивают минусы, только и всего.
Но в целом такое ограничение — это результат грамматики языка. «Под капотом» Go использует точки с запятой, но их писать не обязательно — перед компиляцией Go «расставляет» точки запятой, и правило там такое — если в конце строки стоит идентификатор или один из токенов из списка (break continue fallthrough return ++ — ) }), то точка с запятой вставляется. Вот тут подробнее: golang.org/doc/effective_go.html#semicolons
Неверно поняли.
Умеют.
Да всё можно пережить. Но рынок движется другими силами.
Я очень рад за Python, что в третьей версии в нем достаточно неплохо обстоят дела с документацией. И я на самом деле желаю Питону долгих лет жизни, тем более, что и сам на нём писал. Но, пожалуйста, не воспринимайте посты про языки программирования отличные от Питона как критику в адрес последнего.
Все аргументы в стиле «а вот посмотрите, в языке Х фича Y тоже хорошая» заведомо обречены, потому что преимущество Go не в том, что в нём все мыслимые аспекты и фичи программирования на порядки лучше и качественней, чем в других языках программирования. Нет, и ещё раз нет.
Преимущество Go в сочетании тех или иных решений, которые именно в этом сочетании позволяют решать широкий круг актуальных для нашего конкретного времени, наших конкретных реалий и экосистем, задач, реальными не-сверх-идеальными программистами, и делать это быстро и качественно с минимальными затратами.
Поэтому, серъезно, никто не оспаривает то, насколько Питон классный язык — и по многим пунктам Zen of Python, они даже близки с Go — но примите плюрализм технологий как что-то хорошее, а не плохое. Все технологии, набирающие популярность, набирают её по какой-то объективной причине, хотите вы этого или нет, понимаете вы это или нет. И лучше их понимать.
Кроме того, особенно если вы ведете курсы по Питону — познакомьтесь с Go ближе: даже если вы не будете на нём писать, ваши познания и авторитет от знания ещё одного весомого современного языка программирования только вырастут. Тем более, что с Go на это нужно гораздо меньше времени.
Про бенчмарки, тесты и прочее я специально упомянул, что это хоть и «не особо нужно», но это слишком просто делается в Go, чтобы это не делать всегда :)
Кстати, солидарен с комментом выше, я бы тоже сделал веб-сервис, который бы и обновлял данные при поступлении новых, и обрабатывал запросы на проверку.
Ещё можно просто почитать описание языка, ну, или хотя бы, спросить у сообщества.
Вот так пишите (точку в конце строки, а не в начале):
а) размер файла по ссылке там 1Гб
б) 0.004 секунды на весь поиск? Это означает, что данные как-то подготовлены уже. За такое время даже считать диска ни один самый шустрый IO не даст.
Что-то либо я недопонял, либо вы не договорили)
Вообще, вот такое «сравнение» по хорошему вы должны сделать самостоятельно — всё таки для сравнения производительности такой задачи, как «перелопатить csv» файлик, тут важнее выбрать правильный подход к задаче и правильно оценить компромиссы между нагрузкой на IO, CPU и памятью. Не говоря уже о том, что если файл обновляется раз в сутки, то лучше его один раз отсортировать/свести и все проверки делать уже на подготовленном датасете. Тоесть или вы имплементируйте — или опишите точно ваше решение.
К примеру, решение «в лоб» у меня отняло 15 минут, но оно, явно не самое эффективное, и можно оптимизировать. Задействуется 1 кор CPU, полный проход на моем макбуке занимает 2m23s. Хотя это решение — полноценный тул, с тестами, бенчмарком, комментариями, обработкой параметров командной строки и обработкой ошибок.
Но если ваши главные требования «минимум оперативки и минимум cpu» — то это лучше на C делать. Все-таки Go жертвует немного памятью и cpu, в пользу простоты языка — и это был сознательный компромисс. Сейчас актуальнее экономить время и силы, потраченные на реализацию кода, а не килобайты ОЗУ, которое, в сравнении со стоимостью человеко-часа сейчас совсем дешевое.
По поводу вашего условия — а алгоритм определения «хороший/плохой» укажите, а то пока ясно только, что 0000000000 — хороший, а 0000000005 — плохой :)
Можно иронизировать, а можно принимать реальность, как данное. Именно это приводит к тому, что многие статьи про важность документирования кода иронично начинаются словами «Всем известно, что документация важна, но её никто не пишет».
Нет. Это мой опыт, и вы имеете право ему не верить, и считать, что я выдаю желаемое за действительное. :)
Окей, попробую своими словами. Для меня главное отличие godoc в двух вещах:
Кроме того, тут еще важный момент, который мало где озвучивается — когда я пишу код, мне документация к нему не нужна. Я не хочу прерывать код, чтобы запустить докогенератор и любоваться на него в браузере. Может он мне вообще никогда и не понадобится. Все это уменьшает приоритет важности «писать документацию по ходу написания кода».
В Go это не так — я знаю, что мне достаточно написать одну строчку перед функцией и это тождественно «у тебя есть отличная документация к ней и она будет на godoc.org». И это game-changer — это стимул и мотивация потратить 10 секунд и получить максимум.
В Go все библиотеки доступны в виде исходных кодов, там такая задача даже не стоит.
Ну и да, дотнет (для меня лично) — даже не рассматривается как вариант для системного софта, поскольку это инструмент заточенный под экосистему MS и, даже оставив все последствия этого, необходимость иметь специальную дев-среду для того, чтобы мочь посмотреть документацию, для меня звучит, как страшный сон. Хотя в мире/экосистеме MS/.Net удобно наверное, да.
Нет.
И я продолжаю не видеть связи между слакой, маком, командой chown и go get. И даже, если я сейчас эту многоходовочку мыслей ухвачу, мне все равно вывод «пользователей мака тянет к слаке» кажется очень неверным :)
Вы просто хотели рассказать, как вы решили вопрос деплоя в своем проекте или вы понимаете вопросы, которые стоят перед мировым dev/devops-сообществом, понимаете, что в масштабе миллионов есть потребность эти процессы упрощать и сокращать, и считаете, что все должны выбрать ваш подход?
Хорошо, давайте спрошу иначе — почему большая часть кода на Go документирована, а большая часть кода на Python или Java — нет? Или вы будете с этим спорить, и требовать «доказательства»?
Ухты. А как это, и зачем? :)