К слову, разработчики на Go редко ставят Go из репозитория системы. Во-первых, он почти всегда там старый. Во-вторых, я ещё должен найти packager'а, которой понял концепцию GOPATH и GOROOT, и не применил какие-то патчи, которые, как ему кажется, делают что-то лучше и Fedora/Debian/Ubuntu-way, но всё ломают для разработчиков. Последний раз смотрел года два назад – было дно.
Почти все разработчики на языках, отличных от C и С++, не ставят библиотеки для этих языков yum'ом и apt'ом, а используют средства экосистемы языка: gem, pip, crate, etc. Пакетный менеджер системы придумали совсем не для них, и пользоваться им, чтобы ставить, например, gem'ы, дико неудобно.
В Go для этого используются go get и различные менеджеры зависимостей, которые постепенно вытесняются официальным экспериментом: https://github.com/golang/dep. Если у вас будут SemVer-теги для релизов, то будет ещё приятнее.
Отвечая на вопрос – да, пользоваться инструментом, привычным разработчику на языке, удобнее, чем инструментом, грубо говоря, системного администратора. Тут между вами, разработчиками unit'а, и разработчиками на Go пропасть, которую надо преодолеть.
Как минимум, своеобразный import path: все известные мне тулзы, включая саму утилиту go, будут считать, что это пакет стандартной библиотеки. Если вы сделаете путь вроде github.com/nginx/go-unit, и положите пакет туда, вы избавите людей от большой головной боли.
Язык – это не только и не столько стандартная библиотека. Это, в первую очередь, его идеи, его философия. И его философия говорит нам, что код в этой статье не должен использоваться кроме как для упражнений. Опять же, пример от Роба Пайка: https://github.com/robpike/filter
Статья больше не про цикл, а про проблему с которой сталкиваются программисты на Go. Эта проблема, как правило, возникает чаще всего именно с for-range.
Это проблема, с которой сталкиваются начинающие программисты на Go, пришедшии с JavaScript, Python и Ruby. Не нужно писать на Go как на этих языках. Не нужно бороться с языком.
Ссылка, однако, ведёт на не связанную с Golang Moscow конференцию Golang Conf.
Golang Moscow был тут: https://www.meetup.com/ru-RU/Golang-Moscow/
Наша конференция GopherCon Russia была тут: https://www.gophercon-russia.ru
На Golang Conf я только выступал один раз.
StackGres же ещё:
Ещё Обама негров линчевал. /s
При чём тут полёты?
К слову, разработчики на Go редко ставят Go из репозитория системы. Во-первых, он почти всегда там старый. Во-вторых, я ещё должен найти packager'а, которой понял концепцию GOPATH и GOROOT, и не применил какие-то патчи, которые, как ему кажется, делают что-то лучше и Fedora/Debian/Ubuntu-way, но всё ломают для разработчиков. Последний раз смотрел года два назад – было дно.
Почти все разработчики на языках, отличных от C и С++, не ставят библиотеки для этих языков yum'ом и apt'ом, а используют средства экосистемы языка: gem, pip, crate, etc. Пакетный менеджер системы придумали совсем не для них, и пользоваться им, чтобы ставить, например, gem'ы, дико неудобно.
В Go для этого используются go get и различные менеджеры зависимостей, которые постепенно вытесняются официальным экспериментом: https://github.com/golang/dep. Если у вас будут SemVer-теги для релизов, то будет ещё приятнее.
Отвечая на вопрос – да, пользоваться инструментом, привычным разработчику на языке, удобнее, чем инструментом, грубо говоря, системного администратора. Тут между вами, разработчиками unit'а, и разработчиками на Go пропасть, которую надо преодолеть.
Как минимум, своеобразный import path: все известные мне тулзы, включая саму утилиту go, будут считать, что это пакет стандартной библиотеки. Если вы сделаете путь вроде github.com/nginx/go-unit, и положите пакет туда, вы избавите людей от большой головной боли.
Лишнее слово.
А призы будут?
https://xkcd.com/927/
Люди с C++ и Java вообще редко переходят на Go. Об этом хорошо написал Роб Пайк: https://commandcenter.blogspot.ru/2012/06/less-is-exponentially-more.html
Язык – это не только и не столько стандартная библиотека. Это, в первую очередь, его идеи, его философия. И его философия говорит нам, что код в этой статье не должен использоваться кроме как для упражнений. Опять же, пример от Роба Пайка: https://github.com/robpike/filter
Успользую уже очень давно. Работает.
https://github.com/kisielk/errcheck
Это проблема, с которой сталкиваются начинающие программисты на Go, пришедшии с JavaScript, Python и Ruby. Не нужно писать на Go как на этих языках. Не нужно бороться с языком.
Починили, должно работать.
Привет. Напиши, пожалуйста, в нашу группу.