Не знаю, но я верю в эффективность конкурентных рынков. Если бы Lisp был так хорош и удачен, отвечал бы требованием времени и вписывался в экосистему, не сомневайтесь — его бы использовали, коммьюнити росло, а обучающие материалы и success stories появлялись бы экспоненциально. Видимо, чего-то нет.
Отвечу за себя — в моём понимании, Lisp даже не рассматривается как язык для серверного софта, особенно для стартапа. Если бы я нанял CTO и он бы мне сказал — будем писать на Lisp-е, я бы подробно пообщался с человеком, чтобы выяснить а) адекватно ли он понимает рынок существующих инструментов и языков, б) возможно я чего-то очень важного не знаю про Lisp и там действительно выгода на выгоде и выгодой погоняет. Так-то я вижу хайп вокруг Clojure, но пока тоже ни одного веского аргумента даже для «посмотреть более внимательно» я не имею — код, который мне попадается, мне не нравится — поэтому я пока отношу Clojure к «не подходят под личные предпочтения», но стараюсь регулярно присматриваться, всё таки этот рынок динамичный и упираться в одни технологии из принципа нельзя.
Это как в Java уже 20 лет? Или в дотнете 13? Или в Питоне — не узнаю уж сколько.
Нет, не так.
Если вы намекаете на Javadoc и Pythondoc, то а) их нужно ставить отдельно, б) для них нужно учить/запоминать специальный синтаксис. И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
Ну и сайтов, которые в одном месте удобно агрегируют документацию всех публичных проектов на Java, Питоне или .Net я тоже не знаю.
У меня в проектах это делается автоматически через go generate, да. Но речь же не только об ассетах, там достаточно сложности, от которой single binary избавляет.
почему его то с clojurescript сравнивают, то с веб фреймворками.
Я думаю, причина тут банально в том, что задача «бекенд для мобильного приложения для стартапа» — это популярная задача, и способы её решить — одна из обсуждаемых тем, и Go тут явно игрок.
Ну, во-первых, не ответили. ) В оригинальном комментарии была процитирована строка запуска go get и вот та фраза про связь. Даже оставив в стороне про «срач в /usr» и GOPATH (тут я еще могу ход мысли проследить), но причем тут маки?
Ваше возмущение мне более-менее понятно, но они да, решают, проблему, и стадия «посмотреть что и как нужно всем» — это тоже часть решения. Это же не арифметическая задача, здесь вопрос компромиссов и не впаривать всем решение «удобное для нас» — достаточно разумно.
Почему сказочки?
Возьмите две крайности для примера: один стартап(А) выбрал Ruby, второй (Б) выбрал Asm для написания REST-бекенда. Знаю смешно, но я намеренно утрирую. Стартап Б пишет 8 месяцев современный REST-бекенд для API, стартап А за это время уже давным давно выходит на рынок, зарабатывает популярность и продается Гуглу.
Даже в более мягком сценарии — нужно менять/рефакторить код под новые условия/обстоятельства — у стартапа А на это уходит месяц, у стартапа Б ведущий программист вешается от депрессии (или увольняется), и еще год уходит на рефакторинг.
Сводить это к «технологии нехватки денег» — имхо, неверно. Да, можно вбухать еще кучу бабла, набрать рок-звезд по ассемблеру — но разве это решит проблему концептуально и будет правильно?
1) Вопрос продуман и встроен в язык/тулинг изначально
2) Не нужно ничего устанавливать дополнительно
3) Не нужно учить никакой специальный синтаксис комментариев (кроме одного правила)
В сухом остатке — большая часть кода на Go имеет документацию, доступную через локальные инструменты и в интернете.
Даже если программист вообще знать ничего не хочет про документацию — все равно будет удобная страничка, с описанием публичного API библиотеки. Если же хочет — с самым минимальным напрягом, получаем очень качественные доки и на это очень быстро подсаживаешься и привыкаешь.
Ну, вы же понимаете, что такого рода неуверенность решается только одним методом — возьми и попробуй.
А вообще — тут все решает маркет. Если есть какая-то технология, когда нужна многим людям, и она есть на всех современных языках, то — учитывая многие поинты, в том числе озвученные в этой статье — она и есть написана и на Go.
А так ведь — как мне шаблонизировать на go? Есть ли sass какой-нибудь процессор на go?
В стандартной библиотеке Go есть встроенный отличный html/template, достаточный для многих случаев. Есть и сторонние, более навороченные, но я не игрался, мне не релевантно. Быстрый поиск по Sass показывает, что есть библиотека-враппер над libsass. А вообще, обязательно освойтесь с godoc.org — там автоматически экспортится документация ко всем открытым в open-source библиотекам на Go, удобно искать всё в одном месте, и документация есть всегда (тоже одна из фишек подхода к документации в Go).
используя Go придется все равно заморочиться и с деплоем, и с devops.
А как иначе? :) Разница лишь в том, что эти заморочки становятся настолько простыми, насколько это возможно, и процесс на порядки проще и легче, чем при других решениях.
А ну, давайте, каждый заминусовавший комментарий выше, обоснует свой голос. :)
В цитате, на которую ссылаются на коммент выше ни слова нет про «аудиторию», речь исключительно о конкуренции и весь наезд про «влажные сны» — просто не по адресу. Такое бывает — быстро прочёл, ошибся, недопонял.
А как сейчас модно деплоить go приложения? Есть какие-нибудь best practices?
Ну тут (не только касательно Go) зоопарк целый. Обычно пользуют те решения, к которым привыкли/есть в стеке.
Если не критичен простой, то банальным stop/change binary/start, если критичен — то разными методами zero downtime restart. Супервизор или systemd — и то и другое в ходу. Можно и через докер push/pull деплоить. Я думаю, что всего зоопарка решений я даже не знаю.
как хранить и распространять, в случае веб-приложения, js/css/картинки, как минифицировать ассеты и прочее
Я пользую go-bindata, но есть еще подобные проекты, вроде go-rice, там есть и удобные врапперы для использования с http-либой. Про минификацию — какие-то проскакивали решения (так не вспомню сходу, не пользую), но имхо, если речь о фронтенде, то лучше минифицировать стандартными решениями для фронтенд-разработки, и засовывать в assets уже минифицированный код.
Резонно. Но, уже, пожалуй поздно менять, да и «Побеждая посредственность» выглядит немного лучше, чем «Побеждая средний уровень». Хотя мне оба не сильно нравятся, если честно. :) Но спасибо за вариант.
Да, я вообще в черновике это перевёл в лоб как «Побеждая середнячков» :) — ну, оно и по контексту оригинальной статьи так. Но всё таки не звучало, и лучшего перевода я не нашел.
А, про Java и параллели — неверно Вас понял. В любом случае, аргумент «в Java тоже» из разряда — «Microsoft тоже выпускала планшет» — оно то так, но результат в итоге разный.
Многие стартапы начинаются с труда одного-двух человек. Go позволяет сократить накладные расходы на devops и упростить написание объемного для других языков кода — и это вообще делает возможным само существование этого стартапа. С большими компаниями, как раз сложнее — им нужно 150 причин, чтобы обосновать переход и убедиться, что он не будет затратным. Что-то вы не так поняли, кажется.
Если уж параллель с Java проводили…
Извините, но люди очень хороши в неверных параллелях. Без полного взвешенного обоснования всей картины, выхватывать «похожее» и называть «это мы уже проходили» — это всегда ложный путь.
Ага, синтаксис.
И всё же, если мы будем говорить о переходе на, скажем, Rust — уже и это очень много. Синтаксис, кстати, там очень похож на C, поэтому даже учить нечего. Основное — это построение в голове карты языка, что есть, чего нет, плюс ознакомпление с каналами/select-ом. А дальше уже освоение stdlib, которая тоже очень выгодно выделяется ото всех стандартных библиотек, которые «вы уже проходили». Серьезно.
И вот прям вау эффекта, чтобы всё бросить и перейти на него, у меня не возникает =/
Видимо под ваш набор задач, с которыми вы имеете дело из года в год — вам достаточно и Java. Но людей много, и требования рынка создают новые, более удачные решения. Речь об этом же.
Мне кажется, или вы только что попытались сказать «Все вопросы менеджмента зависимостей — легко и просто решаются, но авторы и коммьюнити Go просто не знают того, что знаю я про опыт других языков, и поэтому сделали неправильно»? :)
Да ничего, на самом деле с Вами интересней всего из всех комментаторов тут было общаться.
Насчёт «Go не так популярен, как мне кажется» — мне не кажется, и я думаю, что достаточно объективно вижу картинку. Go достаточно уверенно занимает свою основную нишу (системный/серверный софт) и постепенно осваивает новые ниши — и мне важно то, что уже написанного софта и библиотек достаточно, чтобы не упираться в отсутствие каких-то важных библиотек, и что лично я для всех моих задач (а я, в основном, серверным софтом занимаюсь) получаю благодаря Go результат.
Тоесть фразы вроде «Go не так популярен» или «вот посмотрим на него, когда он вытеснит все другие языки» — мне просто не релевантны. Go для меня уже состоялся и экономит массу времени, которое для меня есть синонимом к «деньги» :)
Но популяризировать я, по мере возможности, всё же Go хочу и буду, потому что масса толковых людей просто ещё даже не знают, что такой язык существует. Больше статей, больше комьюнити -> больше качественного кода и счастливых девелоперов -> профит :)
А все приведенные ваши примеры — это не говнокод. Это то, что Брукс в своем знаменитом труде «No silver bullet» называл "essential complexity" — та составная сложности задачи, которая происходит из области проблемы, а не от выбранного инструмента. От этой сложности не уйти, каким языком её не решай. Если вам нужно поддерживать N алгоритмов генерации ключей — нет такого языка, где вы все N вариантов напишете одной командой. Зато вторая составная — "accidental complexity" — которая привносится инструментом, вот эти все обертки/классы/расходы на ручной менеджмент памяти и декодинг фичастых конструкций — это то, что можно и нужно уменьшать. Вообще эта тема отдельной статьи заслуживает.
Надо написать, спасибо за идею :)
Отвечу за себя — в моём понимании, Lisp даже не рассматривается как язык для серверного софта, особенно для стартапа. Если бы я нанял CTO и он бы мне сказал — будем писать на Lisp-е, я бы подробно пообщался с человеком, чтобы выяснить а) адекватно ли он понимает рынок существующих инструментов и языков, б) возможно я чего-то очень важного не знаю про Lisp и там действительно выгода на выгоде и выгодой погоняет. Так-то я вижу хайп вокруг Clojure, но пока тоже ни одного веского аргумента даже для «посмотреть более внимательно» я не имею — код, который мне попадается, мне не нравится — поэтому я пока отношу Clojure к «не подходят под личные предпочтения», но стараюсь регулярно присматриваться, всё таки этот рынок динамичный и упираться в одни технологии из принципа нельзя.
Нет, не так.
Если вы намекаете на Javadoc и Pythondoc, то а) их нужно ставить отдельно, б) для них нужно учить/запоминать специальный синтаксис. И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
Ну и сайтов, которые в одном месте удобно агрегируют документацию всех публичных проектов на Java, Питоне или .Net я тоже не знаю.
У меня в проектах это делается автоматически через go generate, да. Но речь же не только об ассетах, там достаточно сложности, от которой single binary избавляет.
Я думаю, причина тут банально в том, что задача «бекенд для мобильного приложения для стартапа» — это популярная задача, и способы её решить — одна из обсуждаемых тем, и Go тут явно игрок.
Ваше возмущение мне более-менее понятно, но они да, решают, проблему, и стадия «посмотреть что и как нужно всем» — это тоже часть решения. Это же не арифметическая задача, здесь вопрос компромиссов и не впаривать всем решение «удобное для нас» — достаточно разумно.
Возьмите две крайности для примера: один стартап(А) выбрал Ruby, второй (Б) выбрал Asm для написания REST-бекенда. Знаю смешно, но я намеренно утрирую. Стартап Б пишет 8 месяцев современный REST-бекенд для API, стартап А за это время уже давным давно выходит на рынок, зарабатывает популярность и продается Гуглу.
Даже в более мягком сценарии — нужно менять/рефакторить код под новые условия/обстоятельства — у стартапа А на это уходит месяц, у стартапа Б ведущий программист вешается от депрессии (или увольняется), и еще год уходит на рефакторинг.
Сводить это к «технологии нехватки денег» — имхо, неверно. Да, можно вбухать еще кучу бабла, набрать рок-звезд по ассемблеру — но разве это решит проблему концептуально и будет правильно?
2) Не нужно ничего устанавливать дополнительно
3) Не нужно учить никакой специальный синтаксис комментариев (кроме одного правила)
В сухом остатке — большая часть кода на Go имеет документацию, доступную через локальные инструменты и в интернете.
Даже если программист вообще знать ничего не хочет про документацию — все равно будет удобная страничка, с описанием публичного API библиотеки. Если же хочет — с самым минимальным напрягом, получаем очень качественные доки и на это очень быстро подсаживаешься и привыкаешь.
Ну, вы же понимаете, что такого рода неуверенность решается только одним методом — возьми и попробуй.
А вообще — тут все решает маркет. Если есть какая-то технология, когда нужна многим людям, и она есть на всех современных языках, то — учитывая многие поинты, в том числе озвученные в этой статье — она и есть написана и на Go.
В стандартной библиотеке Go есть встроенный отличный html/template, достаточный для многих случаев. Есть и сторонние, более навороченные, но я не игрался, мне не релевантно. Быстрый поиск по Sass показывает, что есть библиотека-враппер над libsass. А вообще, обязательно освойтесь с godoc.org — там автоматически экспортится документация ко всем открытым в open-source библиотекам на Go, удобно искать всё в одном месте, и документация есть всегда (тоже одна из фишек подхода к документации в Go).
А как иначе? :) Разница лишь в том, что эти заморочки становятся настолько простыми, насколько это возможно, и процесс на порядки проще и легче, чем при других решениях.
В цитате, на которую ссылаются на коммент выше ни слова нет про «аудиторию», речь исключительно о конкуренции и весь наезд про «влажные сны» — просто не по адресу. Такое бывает — быстро прочёл, ошибся, недопонял.
Ну тут (не только касательно Go) зоопарк целый. Обычно пользуют те решения, к которым привыкли/есть в стеке.
Если не критичен простой, то банальным stop/change binary/start, если критичен — то разными методами zero downtime restart. Супервизор или systemd — и то и другое в ходу. Можно и через докер push/pull деплоить. Я думаю, что всего зоопарка решений я даже не знаю.
Я пользую go-bindata, но есть еще подобные проекты, вроде go-rice, там есть и удобные врапперы для использования с http-либой. Про минификацию — какие-то проскакивали решения (так не вспомню сходу, не пользую), но имхо, если речь о фронтенде, то лучше минифицировать стандартными решениями для фронтенд-разработки, и засовывать в assets уже минифицированный код.
Многие стартапы начинаются с труда одного-двух человек. Go позволяет сократить накладные расходы на devops и упростить написание объемного для других языков кода — и это вообще делает возможным само существование этого стартапа. С большими компаниями, как раз сложнее — им нужно 150 причин, чтобы обосновать переход и убедиться, что он не будет затратным. Что-то вы не так поняли, кажется.
Извините, но люди очень хороши в неверных параллелях. Без полного взвешенного обоснования всей картины, выхватывать «похожее» и называть «это мы уже проходили» — это всегда ложный путь.
И всё же, если мы будем говорить о переходе на, скажем, Rust — уже и это очень много. Синтаксис, кстати, там очень похож на C, поэтому даже учить нечего. Основное — это построение в голове карты языка, что есть, чего нет, плюс ознакомпление с каналами/select-ом. А дальше уже освоение stdlib, которая тоже очень выгодно выделяется ото всех стандартных библиотек, которые «вы уже проходили». Серьезно.
Видимо под ваш набор задач, с которыми вы имеете дело из года в год — вам достаточно и Java. Но людей много, и требования рынка создают новые, более удачные решения. Речь об этом же.
Насчёт «Go не так популярен, как мне кажется» — мне не кажется, и я думаю, что достаточно объективно вижу картинку. Go достаточно уверенно занимает свою основную нишу (системный/серверный софт) и постепенно осваивает новые ниши — и мне важно то, что уже написанного софта и библиотек достаточно, чтобы не упираться в отсутствие каких-то важных библиотек, и что лично я для всех моих задач (а я, в основном, серверным софтом занимаюсь) получаю благодаря Go результат.
Тоесть фразы вроде «Go не так популярен» или «вот посмотрим на него, когда он вытеснит все другие языки» — мне просто не релевантны. Go для меня уже состоялся и экономит массу времени, которое для меня есть синонимом к «деньги» :)
Но популяризировать я, по мере возможности, всё же Go хочу и буду, потому что масса толковых людей просто ещё даже не знают, что такой язык существует. Больше статей, больше комьюнити -> больше качественного кода и счастливых девелоперов -> профит :)
А все приведенные ваши примеры — это не говнокод. Это то, что Брукс в своем знаменитом труде «No silver bullet» называл "essential complexity" — та составная сложности задачи, которая происходит из области проблемы, а не от выбранного инструмента. От этой сложности не уйти, каким языком её не решай. Если вам нужно поддерживать N алгоритмов генерации ключей — нет такого языка, где вы все N вариантов напишете одной командой. Зато вторая составная — "accidental complexity" — которая привносится инструментом, вот эти все обертки/классы/расходы на ручной менеджмент памяти и декодинг фичастых конструкций — это то, что можно и нужно уменьшать. Вообще эта тема отдельной статьи заслуживает.
Надо написать, спасибо за идею :)