Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 183
Go очень быстро завоёвывает сообщество стартапов. Вот далеко не полный, и постоянно растущий список компаний...Только стартапов я там не увидел.
Достаточно скоро, многие из противников перейдут на Go просто следуя трендам рынка.Большие компании могут себе такое позволить.
А в стартапах важна скорость. Вряд ли использование Go командой, которая никогда с ним не работала, хорошее решение для стартапа.
А по пунктам:
1) Если уж параллель с Java проводили… В Java тоже много чего есть, а чего нет, легко можно дополнить Open Source готовыми решениями (которые легко интегрируются в уже имеющуюся систему).
2)
хороший программист может выучить Go в течении 1-3 выходныхАга, синтаксис.
3) С Rails и Django дела не имел, но в той же Java/Scala всё то же довольно просто. Netty/Akka и иже с ними. И всё тот же один бинарник.
4) Тогда зачем переходить на Go, если кроме экономии памяти (которая нынче дешёвая) она ничего, в сущности, нового не даёт.
p.s. я сам с Go не работал, преимущественно с Java имею дело. Читаю статьи по Go периодически. И вот прям вау эффекта, чтобы всё бросить и перейти на него, у меня не возникает =/
Большие компании могут себе такое позволить.
Многие стартапы начинаются с труда одного-двух человек. Go позволяет сократить накладные расходы на devops и упростить написание объемного для других языков кода — и это вообще делает возможным само существование этого стартапа. С большими компаниями, как раз сложнее — им нужно 150 причин, чтобы обосновать переход и убедиться, что он не будет затратным. Что-то вы не так поняли, кажется.
Если уж параллель с Java проводили…
Извините, но люди очень хороши в неверных параллелях. Без полного взвешенного обоснования всей картины, выхватывать «похожее» и называть «это мы уже проходили» — это всегда ложный путь.
Ага, синтаксис.
И всё же, если мы будем говорить о переходе на, скажем, Rust — уже и это очень много. Синтаксис, кстати, там очень похож на C, поэтому даже учить нечего. Основное — это построение в голове карты языка, что есть, чего нет, плюс ознакомпление с каналами/select-ом. А дальше уже освоение stdlib, которая тоже очень выгодно выделяется ото всех стандартных библиотек, которые «вы уже проходили». Серьезно.
И вот прям вау эффекта, чтобы всё бросить и перейти на него, у меня не возникает =/
Видимо под ваш набор задач, с которыми вы имеете дело из года в год — вам достаточно и Java. Но людей много, и требования рынка создают новые, более удачные решения. Речь об этом же.
А, про Java и параллели — неверно Вас понял. В любом случае, аргумент «в Java тоже» из разряда — «Microsoft тоже выпускала планшет» — оно то так, но результат в итоге разный.
Все круто, но вот честно
— Я не уверен что он прямо так радикально выразительныее ruby / python и обеспечивает большую скорость разработки
— А также — ну вот нужно мне — парсить excel, работать c каким-нибудь поисковым движком типа sphinx / elastic — вдруг чего-то такого не окажется? Все таки написано много готового кода, опираясь на который можно сосредоточиться на key features.
А так ведь — как мне шаблонизировать на go? Есть ли sass какой-нибудь процессор на go? Задавая себе эти вопросы я прихожу к выводу что используя Go придется все равно заморочиться и с деплоем, и с devops. :(
ересно также будет посмотреть, например на Swift вдруг в связи с его открытием появиться какой-нибудь интересный web framework для него?
— Я не уверен что он прямо так радикально выразительныее ruby / python и обеспечивает большую скорость разработки
— А также — ну вот нужно мне — парсить excel, работать c каким-нибудь поисковым движком типа sphinx / elastic — вдруг чего-то такого не окажется? Все таки написано много готового кода, опираясь на который можно сосредоточиться на key features.
А так ведь — как мне шаблонизировать на go? Есть ли sass какой-нибудь процессор на go? Задавая себе эти вопросы я прихожу к выводу что используя Go придется все равно заморочиться и с деплоем, и с devops. :(
ересно также будет посмотреть, например на Swift вдруг в связи с его открытием появиться какой-нибудь интересный web framework для него?
Я не уверен
вдруг
Ну, вы же понимаете, что такого рода неуверенность решается только одним методом — возьми и попробуй.
А вообще — тут все решает маркет. Если есть какая-то технология, когда нужна многим людям, и она есть на всех современных языках, то — учитывая многие поинты, в том числе озвученные в этой статье — она и есть написана и на Go.
А так ведь — как мне шаблонизировать на go? Есть ли sass какой-нибудь процессор на go?
В стандартной библиотеке Go есть встроенный отличный html/template, достаточный для многих случаев. Есть и сторонние, более навороченные, но я не игрался, мне не релевантно. Быстрый поиск по Sass показывает, что есть библиотека-враппер над libsass. А вообще, обязательно освойтесь с godoc.org — там автоматически экспортится документация ко всем открытым в open-source библиотекам на Go, удобно искать всё в одном месте, и документация есть всегда (тоже одна из фишек подхода к документации в Go).
используя Go придется все равно заморочиться и с деплоем, и с devops.
А как иначе? :) Разница лишь в том, что эти заморочки становятся настолько простыми, насколько это возможно, и процесс на порядки проще и легче, чем при других решениях.
А что такого в подходе к документации в Go?
1) Вопрос продуман и встроен в язык/тулинг изначально
2) Не нужно ничего устанавливать дополнительно
3) Не нужно учить никакой специальный синтаксис комментариев (кроме одного правила)
В сухом остатке — большая часть кода на Go имеет документацию, доступную через локальные инструменты и в интернете.
Даже если программист вообще знать ничего не хочет про документацию — все равно будет удобная страничка, с описанием публичного API библиотеки. Если же хочет — с самым минимальным напрягом, получаем очень качественные доки и на это очень быстро подсаживаешься и привыкаешь.
2) Не нужно ничего устанавливать дополнительно
3) Не нужно учить никакой специальный синтаксис комментариев (кроме одного правила)
В сухом остатке — большая часть кода на Go имеет документацию, доступную через локальные инструменты и в интернете.
Даже если программист вообще знать ничего не хочет про документацию — все равно будет удобная страничка, с описанием публичного API библиотеки. Если же хочет — с самым минимальным напрягом, получаем очень качественные доки и на это очень быстро подсаживаешься и привыкаешь.
Это как в Java уже 20 лет? Или в дотнете 13? Или в Питоне — не узнаю уж сколько.
Javadoc встроен в язык? Я что-то опять пропустил?
Как мне в питоне, например, сгенерировать документацию, не устанавливая ничего, кроме питона? (нет, sphinx не входит в питон)
Как мне в питоне, например, сгенерировать документацию, не устанавливая ничего, кроме питона? (нет, sphinx не входит в питон)
> The pydoc module automatically generates documentation from Python modules. The documentation can be presented as pages of text on the console, served to a Web browser, or saved to HTML files.
$ pydoc3 -w /usr/lib/python3.4/zipfile.py
wrote zipfile.html
$ pydoc3 -w /usr/lib/python3.4/zipfile.py
wrote zipfile.html
Да, pydoc я как-то упустил.
По сути, godoc — стандарт документации для go, есть godoc.org, который можешь сгененировать доки для любого доступного проекта. Т.е. просто зайти godoc.org/github.com/foo/bar, и там будет документация по foo/bar.
Причем точно такая же документация будет, если godoc запустить локально. Такого удобного инструмента для других языков я не видел.
Она достаточно продвинутая, чтобы не было нужды использовать такие инструменты, как sphinx или javadoc.
Это снижает порог вхождения. Ну и я не думаю, что кто-то всерьез использует pydoc в больших проектах. Поправьте, если ошибаюсь.
По сути, godoc — стандарт документации для go, есть godoc.org, который можешь сгененировать доки для любого доступного проекта. Т.е. просто зайти godoc.org/github.com/foo/bar, и там будет документация по foo/bar.
Причем точно такая же документация будет, если godoc запустить локально. Такого удобного инструмента для других языков я не видел.
Она достаточно продвинутая, чтобы не было нужды использовать такие инструменты, как sphinx или javadoc.
Это снижает порог вхождения. Ну и я не думаю, что кто-то всерьез использует pydoc в больших проектах. Поправьте, если ошибаюсь.
Конечно, встроен, javadoc всегда был включен в JDK, практически любая Java IDE умеет генерить javadoc.
Это как в Java уже 20 лет? Или в дотнете 13? Или в Питоне — не узнаю уж сколько.
Нет, не так.
Если вы намекаете на Javadoc и Pythondoc, то а) их нужно ставить отдельно, б) для них нужно учить/запоминать специальный синтаксис. И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
Ну и сайтов, которые в одном месте удобно агрегируют документацию всех публичных проектов на Java, Питоне или .Net я тоже не знаю.
Почитал вот тут — blog.golang.org/godoc-documenting-go-code
Разницы не увидел. Ну кроме отсутствия тегов, что скорее недостаток. Если я не прав — объясните.
Не знаю как ява и питон, но дотнет умеет вгенеривать документацию прям в бинарник, а IDE — читать ее оттуда.
А публичные проекты все благополучно на nuget и msdn.
Разницы не увидел. Ну кроме отсутствия тегов, что скорее недостаток. Если я не прав — объясните.
Не знаю как ява и питон, но дотнет умеет вгенеривать документацию прям в бинарник, а IDE — читать ее оттуда.
А публичные проекты все благополучно на nuget и msdn.
Вы просто очень хотите «не увидеть разницу».
Хорошо, давайте спрошу иначе — почему большая часть кода на Go документирована, а большая часть кода на Python или Java — нет? Или вы будете с этим спорить, и требовать «доказательства»?
Ухты. А как это, и зачем? :)
Хорошо, давайте спрошу иначе — почему большая часть кода на Go документирована, а большая часть кода на Python или Java — нет? Или вы будете с этим спорить, и требовать «доказательства»?
вгенеривать документацию прям в бинарник
Ухты. А как это, и зачем? :)
Извините, мне виднее чего я хочу или не хочу.
Я всего лишь попросил объяснить разницу.
Раз вы отвечаете вопросом на вопрос, то я вам тоже отвечу вопросом — как качество покрытия библиотек документацией делает язык лучше? Именно язык, как в заголовке и статье, а не платформу.
Собственно, для меня как до дотнетчика — отсутствие документации выглядит вообще странно.
У нас как-то на все публичное и стабильное есть документация.
По поводу дотнета — подключаете библиотеку и в интеллисенсе сразу видите контексно-зависимую документацию по тому что набираете. Вплоть до уровня аргументов у функций. Го, очевидно, так не умеет, в силу отсутствия тегов.
Я всего лишь попросил объяснить разницу.
Раз вы отвечаете вопросом на вопрос, то я вам тоже отвечу вопросом — как качество покрытия библиотек документацией делает язык лучше? Именно язык, как в заголовке и статье, а не платформу.
Собственно, для меня как до дотнетчика — отсутствие документации выглядит вообще странно.
У нас как-то на все публичное и стабильное есть документация.
По поводу дотнета — подключаете библиотеку и в интеллисенсе сразу видите контексно-зависимую документацию по тому что набираете. Вплоть до уровня аргументов у функций. Го, очевидно, так не умеет, в силу отсутствия тегов.
Я всего лишь попросил объяснить разницу.
Окей, попробую своими словами. Для меня главное отличие godoc в двух вещах:
- Не нужно учить специальный формат комментариев. Можно спорить и доказывать, что это я лентяй, но это так. Я пробовал, и на практике мне мое время было дороже для кода, чем для вспоминания, как правильно писать код.
Кроме того, тут еще важный момент, который мало где озвучивается — когда я пишу код, мне документация к нему не нужна. Я не хочу прерывать код, чтобы запустить докогенератор и любоваться на него в браузере. Может он мне вообще никогда и не понадобится. Все это уменьшает приоритет важности «писать документацию по ходу написания кода».
В Go это не так — я знаю, что мне достаточно написать одну строчку перед функцией и это тождественно «у тебя есть отличная документация к ней и она будет на godoc.org». И это game-changer — это стимул и мотивация потратить 10 секунд и получить максимум.
- не нужно ничего ставить, настраивать, возиться и деплоить. Тут, надеюсь, не нужно объяснять. Аргумент «та там три секунды ставить» как тут выше уже пишут про деплой («я просто баш скрипт на 10 строк написал и запускаю с рабочей машины, так что не нужнен весь ваш девопс вообще») — я не принимаю.
По поводу дотнета — подключаете библиотеку и в интеллисенсе сразу видите контексно-зависимую документацию по тому что набираете. Вплоть до уровня аргументов у функций. Го, очевидно, так не умеет, в силу отсутствия тегов.
В Go все библиотеки доступны в виде исходных кодов, там такая задача даже не стоит.
Ну и да, дотнет (для меня лично) — даже не рассматривается как вариант для системного софта, поскольку это инструмент заточенный под экосистему MS и, даже оставив все последствия этого, необходимость иметь специальную дев-среду для того, чтобы мочь посмотреть документацию, для меня звучит, как страшный сон. Хотя в мире/экосистеме MS/.Net удобно наверное, да.
В Go это не так — я знаю, что мне достаточно написать одну строчку перед функцией и это тождественно «у тебя есть отличная документация к ней и она будет на godoc.org».
Это иллюзия, а не знание. Одной строчки недостаточно, чтобы быть отличной документацией.
Но если отвлечься от однострочкизма, то в .net вы имеете ровно то же самое: прямо в коде пишете свою одну строчку, и она автоматом попадает в документацию вашего проекта, и далее везде видна.
необходимость иметь специальную дев-среду для того, чтобы мочь посмотреть документацию, для меня звучит, как страшный сон
Не, вы немного не понялb. Для того, чтобы посмотреть документацию, не нужна dev-среда. Но если у вас есть дев-среда, то документация в ней доступна.
Да, сценарий «я хочу посмотреть автосгенеренную документацию по публичному проекту, не трогая сам проект» в .net недоступен — но не потому, что это технически невозможно (с точки зрения языка там все то же самое, что и в go), а по каким-то другим причинам (вероятно, просто по общей лени).
«Специальный формат комментариев» в Javadoc ограничивается добавлением одной звёздочки в начало комментария:
И всё. Этого достаточно, чтобы такой комментарий подхватился javadoc'ом.
Если вы под «специальным форматом» подразумеваете теги вроде @ code или @ parameter и подобное, то, они, во-первых, для использования абсолютно необязательны, а во-вторых, прошу прощения, в Go их аналогов нет вообще. Это, кстати, лично для меня было очень большим недостатком. В документации ко многим библиотекам на Java или Scala очень часто очень много кросс-ссылок между разными участками документации, в том числе, автоматически сгенерированных (например, в Javadoc можно получить список Known implementors для какого-то интерфейса). В документации Go этого нет, и это очень сильно снижает удобство пользования ей.
/*
*
*/
vs
/**
*
*/
И всё. Этого достаточно, чтобы такой комментарий подхватился javadoc'ом.
Если вы под «специальным форматом» подразумеваете теги вроде @ code или @ parameter и подобное, то, они, во-первых, для использования абсолютно необязательны, а во-вторых, прошу прощения, в Go их аналогов нет вообще. Это, кстати, лично для меня было очень большим недостатком. В документации ко многим библиотекам на Java или Scala очень часто очень много кросс-ссылок между разными участками документации, в том числе, автоматически сгенерированных (например, в Javadoc можно получить список Known implementors для какого-то интерфейса). В документации Go этого нет, и это очень сильно снижает удобство пользования ей.
в Go их аналогов нет вообще.
Их нет именно поэтому. Да, более продвинутый формат комментариев даёт больше информации докогенераторам, но он так же порождает стимул вообще не писать эти комментарии.
Комментарий же в Go выглядит простым нативным однострочным комментом для людей, без необходимости отвлекаться от кода и расписывать что-то в нужном формате — и это порождает стимул это делать всегда и всюду, что имеет очень долгосрочный эффект.
Это большая разница, в итоге.
но он так же порождает стимул вообще не писать эти комментарии
Я не понимаю, как наличие потенциальных, но не обязательных возможностей может порождать стимул не писать комментарии.
Ну вам же объяснили и даже доказали. Чтобы стать полезной и нужной фичей, необходимо и достаточно попасть в go-мир. Все остальное априори от лукавого.
Ничего не хочу сказать против или за go, но divan0 типичный фанатик, со всеми вытекающими.
Ничего не хочу сказать против или за go, но divan0 типичный фанатик, со всеми вытекающими.
Ну вам же объяснили и даже доказали. Чтобы стать полезной и нужной фичей, необходимо и достаточно попасть в go-мир. Все остальное априори от лукавого.
Ничего не хочу сказать против или за go, но divan0 типичный фанатик, со всеми вытекающими.
Сами перекрутили, сами обвинили. Зачем?
В этом треде я пытаюсь донести одну вещь — люди всегда идут путем наименьшего сопротивления. Все понимают, что доки это хорошо, но в языке А для достижения результата «хорошие доки всегда» нужно приложить Х усилий и опыта, а я в языке Б — 10*Х. И мой поинт в том, что в итоге хорошие доки будут с большей вероятностью в проектах на языке А.
И поймите одну вещь — я не придумываю объяснения ради объяснений. Я смотрю на себя, на свой опыт, на те причины, по которым я не писал раньше документацию или сводил обработку ошибок к «выкинуть эксепшн». Хотя про все докогенераторы и правила я знал. Но Go поменял правила игры, и не только для меня, поэтому я и пытаюсь это описать максимально открыто и понятно, отталкиваясь только от реальности, а не от теоретических измышлений.
Если вы не хотите понимать о чем речь, не хотите вникнуть, и вам проще проще назвать меня «фанатиком» — пожалуйста, ваше право, но ценности дискуссии это не добавляет.
Я вижу, и для меня это очень простая вещь, это то, что я хорошо чувствую по себе, и вижу в других.
Но почти всегда, когда я пытаюсь объяснить, что на решения людей влияют другие факторы, которые рождают или отбирают стимулы — находится масса людей, считающих, что я несу бред. Видимо пока плохо умею объяснять такие простые вещи.
Но почти всегда, когда я пытаюсь объяснить, что на решения людей влияют другие факторы, которые рождают или отбирают стимулы — находится масса людей, считающих, что я несу бред. Видимо пока плохо умею объяснять такие простые вещи.
Вы в статье про «побеждая посредственность» до парадокса блаба дочитали-то?
Конечно.
Понимаете какое дело. Мне нравится Go. Но даже после беглого ознакомления становится понятно, что «не выходит из него серебрянная пуля». И понравился он мне совсем не теми вещами, которые вы описали в статье. Какие-то вещи сделаны лучше чем в других языках, какие-то — хуже…
И лично мне понятно, что это еще один неплохой инструмент, который вполне вероятно можно эффективно использовать для некоторого набора задач. А для других задач — вероятно подойдет другой инструмент.
Но когда я читаю рекламу языка, где в качестве преимуществ указаны вещи, которые, как я знаю, гарантировано сделаны лучше в других платформах (будем честными, документация и деплой — это не про язык), и, в ходе обсуждения, выясняется что вы про это не совсем в курсе — у меня возникает примерно такое же ощущение как от недавних статей про Оберон.
Особый цинизм, в том, что семейство лиспов, про которое писал Пол Грэм, все еще мощнее, в том числе Go.
И лично мне понятно, что это еще один неплохой инструмент, который вполне вероятно можно эффективно использовать для некоторого набора задач. А для других задач — вероятно подойдет другой инструмент.
Но когда я читаю рекламу языка, где в качестве преимуществ указаны вещи, которые, как я знаю, гарантировано сделаны лучше в других платформах (будем честными, документация и деплой — это не про язык), и, в ходе обсуждения, выясняется что вы про это не совсем в курсе — у меня возникает примерно такое же ощущение как от недавних статей про Оберон.
Особый цинизм, в том, что семейство лиспов, про которое писал Пол Грэм, все еще мощнее, в том числе Go.
Но даже после беглого ознакомления становится понятно, что «не выходит из него серебрянная пуля»
И не должна.
И понравился он мне совсем не теми вещами, которые вы описали в статье.
Это не моя статья, это перевод. Хабру надо как-то сделать более различимым, видимо.
где в качестве преимуществ указаны вещи, которые, как я знаю, гарантировано сделаны лучше в других платформах (будем честными, документация и деплой — это не про язык),
Извините, но это про язык. Когда вы начинаете писать на другом языке — вы принимаете и его тулинг и экосистему. В С/С++ тоже можно было всегда делать статические бинарники, но по факту их очень редко делают.
Ну и то, что я писал уже не раз тут в комментариях — речь не о конкретных «вещах, сделанных лучше», которые вы считаете «гарантированно» лучше в других языках. Речь в совокупности всех вместе взятых факторов, которые приводят к тому, что можно получать конечный результат быстрее и качественнее в общем случае. Когда мне расписывают, как чудесна кодогенерация в .Net и как хорошо она показывается в IDE — это чудесно, но какой мне от этого толк, если я хочу писать кроссплатформенный софт?
Речь о финальном результате, а не о частностях. А так, оригинальная статья — это ответ на недавнюю неадекватную критику Go — и фразой в конце про 1-800-GO-SWITCH автор явно дал понять, что не скрывает популистского наклона статьи. :)
Я не понимаю, как наличие потенциальных, но не обязательных возможностей может порождать стимул не писать комментарии.
Я всё таки хочу научиться доносить этот момент, мне он кажется достаточно важным.
Скажите, вы понимаете как в экономике формируется кривая спроса? Я просто хочу параллели провести, но для них нужно понимание основ микроэкономики.
«godoc -http :6060 -analysis type» — не то?
Спасибо.
Собственно, за меня уже почти все ответили. Добавлю только, что дома я 90% времени работаю под линуксом, и у меня дотнетовские доки благополучно видно в емаксе под моно.
Собственно, за меня уже почти все ответили. Добавлю только, что дома я 90% времени работаю под линуксом, и у меня дотнетовские доки благополучно видно в емаксе под моно.
А вы тоже согласны с тем, что простота и сложность никак не влияют на то, пишут или не пишут доки, а те, кто это утверждает (включая авторов Go) — просто фанатики? )
Может вы все-таки заглянете в дотнет и посмотрите на качество документации там?
msdn.com если что.
msdn.com если что.
Я рад, если все проекты, даже маленькие side-проекты на дотнете могут похвастаться минимально приемлимой документации и язык/инфраструктура стимулирует программистов это делать. Серьезно, значит MS тут ухватила нить и пошла правильным путем конкретно в этом вопросе.
Но вопрос документации — это лишь один из кирпичиков, и .NET для моих задач не подходит ну вот прямо ни разу.
Но вопрос документации — это лишь один из кирпичиков, и .NET для моих задач не подходит ну вот прямо ни разу.
Я говорю о документации в целом, безотносительно языков, поэтому терминология «интерфейсов»/«модулей» тут лишняя.
А скажите, почему весь внутренний код, который на моем опыте писали Python-программисты — без документации? Плохие программисты попались?
А скажите, почему весь внутренний код, который на моем опыте писали Python-программисты — без документации? Плохие программисты попались?
Кстати, из личного опыта — до Go «написание документации» это была второстепенная задача «на потом», и докогенерация из комментов — лишь один из возможных подходов. Боюсь, что «плохие программисты» на самом деле не пишут комменты для докогенератора не потому, что они наизусть знают «Code complete», а потому что для них это тоже второстепенная задача.
Go этот вопрос (создания документации) сводит к простой привычке однострочного коммента перед функцией. Ни больше, ни меньше. Но, наверное людям, не писавшим на Go я так и не смогу объяснить, как это когда язык и тулинг непосредственно влияет на программистов и на результирующий код.
Go этот вопрос (создания документации) сводит к простой привычке однострочного коммента перед функцией. Ни больше, ни меньше. Но, наверное людям, не писавшим на Go я так и не смогу объяснить, как это когда язык и тулинг непосредственно влияет на программистов и на результирующий код.
простой привычке однострочного коммента перед функцией
Это плохая привычка на самом деле. Вы правда пишите комментарий к функции isEmpty() «это функция проверяет что все поля объекты пусты», а к функции toString() «это функция переводит внутреннее представления объекта в строку»? Зачем? Скажите честно вы хотя бы пролистывали «Чистый код»? Прочитайте хотя бы первые сто страниц, тогда многие вопросы у вас пропадут сами собой. Я не говорю все что там есть принимать как истину, но хотя бы прочитайте.
они наизусть знают «Code complete»
«Сlean code», не «Code complete»
Вы правда пишите комментарий к функции isEmpty() «это функция проверяет что все поля объекты пусты», а к функции toString() «это функция переводит внутреннее представления объекта в строку»?
А, вы об этом. Нет, если функция не предназначается для экспорта (не «публичная», не доступная пользователю либу, не будет показана в API), то комментарий можно не писать, golint ругаться не будет. Хотя, если это немного сложнее, чем isEmpty и одним именем/названием тут не обойтись (к примеру, разбирает какой-то кусок протокола) — то да, для таких функций, даже не «публичных», пишу. Даже если это немного избыточно кажется, пишу, потому что это слишком просто, чтобы этого не сделать, а в будущем кому-то потенциально спасет время и нервы.
Скажите честно вы хотя бы пролистывали «Чистый код»?
Полностью не читал, но неоднократно встречал озвученные там идеи в статьях и видео, в целом, солидарен, конечно же со многими озвученными вещами, но на практике пока не встречал кода, который подходит под определение. А вы, полностью следуете этой книге?
Нет, хорошие. Просто они читали книгу Боба Мартина «Чистый код». Если кратко, код должен быть самодокументируемым за счет правильных имен, а документация ради документации вообще явное зло. Классиков надо знать.
Вы на самом деле требуете испортить хороший код ради идей документирования всего подряд, которые были популярны лет 10 назад.
Вы на самом деле требуете испортить хороший код ради идей документирования всего подряд, которые были популярны лет 10 назад.
Нет, к сожалению, не читали.
Самодокументируемый код — это ещё большая редкость, чем покрытый тестами код. К сожалению, большая часть кода, который я вижу и видел, не подходит под это, поэтому комментарии — особенно с учетом наличия докогенератора по ним — всё остаются хорошей практикой. А
Самодокументируемый код — это ещё большая редкость, чем покрытый тестами код. К сожалению, большая часть кода, который я вижу и видел, не подходит под это, поэтому комментарии — особенно с учетом наличия докогенератора по ним — всё остаются хорошей практикой. А
который я вижу и видел, не подходит под это, поэтому комментарии — особенно с учетом наличия докогенератора по ним — всё остаются хорошей практикой
Даже если так. Зачем менять одну плохую практику на другую плохую практику и ещё гордится что язык в этом помогает, не проще ли просто прочитать одну книжку и экономить время и силы?
P.S. Потом речь ведь не об абстрактных программистах, а о том почему вы лично не хотите писать тот код, где почти не нужны будут комментарии?
На самом деле, насколько я помню, дотнет не умеет вшивать документацию в бинарник, она отдельно живет в аннотациях, и IDE в эти же аннотации и смотрит. Но эти аннотации все равно успешно распространяются вместе с бинарником, поэтому для документированного проекта необходимости в агрегации документации (по крайней мере, той, которая из комментариев) особо нет.
> Если вы намекаете на Javadoc и Pythondoc, то а) их нужно ставить отдельно
Не нужно. javadoc идет в комплекте с jdk, в питоне, как я понимаю — аналогично.
> для них нужно учить/запоминать специальный синтаксис
Что за синтаксис? Давайте-ка сравним доки Go и Java. Вот пример на Go (взятый здесь: blog.golang.org/godoc-documenting-go-code)
// Fprint formats using the default formats for its operands and writes to w.
// Spaces are added between operands when neither is a string.
// It returns the number of bytes written and any write error encountered.
func Fprint(w io.Writer, a ...interface{}) (n int, err error)
Вот похожий код из Java:
/**
* Writes a string.
*
* param str
* String to be written
*
* @throws IOException
* If an I/O error occurs
*/
public void write(String str) throws IOException
Ничего не скажешь, невероятно сложный синтаксис, несколько лет надо учить.
Что интересно, по той же ссылке на блог Go можно найти такой текст:
> Godoc is conceptually related to Python's Docstring and Java's Javadoc, but its design is simpler. The comments read by godoc are not language constructs (as with Docstring) nor must they have their own machine-readable syntax (as with Javadoc). Godoc comments are just good comments, the sort you would want to read even if godoc didn't exist.
Автор в общем признает, что по сути подход такой же, как в Java и Python. Правда потом зачем-то начинает решать за меня, какие комментарии мне читать приятнее. Но видимо, это такая черта Go-евангелистов.
> И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
Можете ли как-нибудь доказать этот тезис?
Не нужно. javadoc идет в комплекте с jdk, в питоне, как я понимаю — аналогично.
> для них нужно учить/запоминать специальный синтаксис
Что за синтаксис? Давайте-ка сравним доки Go и Java. Вот пример на Go (взятый здесь: blog.golang.org/godoc-documenting-go-code)
// Fprint formats using the default formats for its operands and writes to w.
// Spaces are added between operands when neither is a string.
// It returns the number of bytes written and any write error encountered.
func Fprint(w io.Writer, a ...interface{}) (n int, err error)
Вот похожий код из Java:
/**
* Writes a string.
*
* param str
* String to be written
*
* @throws IOException
* If an I/O error occurs
*/
public void write(String str) throws IOException
Ничего не скажешь, невероятно сложный синтаксис, несколько лет надо учить.
Что интересно, по той же ссылке на блог Go можно найти такой текст:
> Godoc is conceptually related to Python's Docstring and Java's Javadoc, but its design is simpler. The comments read by godoc are not language constructs (as with Docstring) nor must they have their own machine-readable syntax (as with Javadoc). Godoc comments are just good comments, the sort you would want to read even if godoc didn't exist.
Автор в общем признает, что по сути подход такой же, как в Java и Python. Правда потом зачем-то начинает решать за меня, какие комментарии мне читать приятнее. Но видимо, это такая черта Go-евангелистов.
> И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
Можете ли как-нибудь доказать этот тезис?
Ничего не скажешь, невероятно сложный синтаксис, несколько лет надо учить.
Можно иронизировать, а можно принимать реальность, как данное. Именно это приводит к тому, что многие статьи про важность документирования кода иронично начинаются словами «Всем известно, что документация важна, но её никто не пишет».
Можете ли как-нибудь доказать этот тезис?
Нет. Это мой опыт, и вы имеете право ему не верить, и считать, что я выдаю желаемое за действительное. :)
Если вы намекаете на Javadoc и Pythondoc, то а) их нужно ставить отдельно, б) для них нужно учить/запоминать специальный синтаксис.
А для .net неверно ни то, ни другое. Ставить ничего не надо, а синтаксис решается IDE (в том смысле, что набрал три слэша перед аннотируемым объектом — получил готовое место для документациии). Ну и то, что получается из xmldoc-а — удобнее, потому что, например, сразу есть навигация по контексту.
Смотрю на вас, и удивляюсь — зачем всё это, если есть perl+CPAN??? Ну сделали ещё один модный язык…
а) их нужно ставить отдельно
Что? javadoc всегда был включен в JDK и поддерживается всеми IDE
б) для них нужно учить/запоминать специальный синтаксис
Какой спец.синтаксис? Набираешь /** + Enter и любая нормальная IDE генерит нужный javadoc комментарий со всеми параметрами и результатом. И даже в блокноте /** это javadoc */ — где тут специальный синтаксис?
удобно агрегируют документацию всех публичных проектов на Java
github, например? Скажите зачем вам документация ВСЕХ сотен тысяч opensource проектов на Java? Что вы с ней будите делать? Находите нужный вам проект на github и смотрите у него javadoc, почти все opensource проекты, которые рассчитывают на использование третьми лицами, генерят javadoc. Когда проектов на Go будет столько же сколько на Java единый агрегатор документации просто заспамят.
проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют
Вы не читали «Чистый код»? Документация не должна быть самоцелью, если вы не разрабатываете публичную библиотеку, намного лучше если код самодокументирован, благодаря понятным именованиям, поэтому для внутренних проектов зачастую комментарии не добавляют ко всем классам и не генерят javadoc, а не потому что это сложно или лень.
Документация доступна в метаданных скомпилированного кода?
3) А где там один бинарник? Прям запускается без установки java?
Jar'ник. Да, jvm нужна. А для запуска Go приложения ничего устанавливать на систему не надо?
Нет, нативный бинарник же. И кросс-компиляция из коробки лучшая, чем у кого-либо и когда-либо.
Нет, совершенно ничего не надо. Он компилируется в статический бинарник, и для деплоя хватает просто копирования на целевую машину, без установки вообще чего либо.
Собственно, меня go покорил в том числе этим :)
Собственно, меня go покорил в том числе этим :)
Под какой набор инструкций процессора оно компилируется?
Вот тут можно подсмотреть: build.golang.org/?branch=release-branch.go1.4
Забавно. Переоткрытие статического связывания уже выглядит, как достижение и инновация.
А вообще ерунда это всё. В моём последнем проекте скрипт деплоя состоял из пары десятков строк на баше. Релиз выкатывается запуском ./release.sh на моей машине. Времени настроить это всё — ну несколько часов от силы. Не те масштабы, чтобы предоставлять статический бинарник, как нечто прорывное.
Вы просто хотели рассказать, как вы решили вопрос деплоя в своем проекте или вы понимаете вопросы, которые стоят перед мировым dev/devops-сообществом, понимаете, что в масштабе миллионов есть потребность эти процессы упрощать и сокращать, и считаете, что все должны выбрать ваш подход?
Кстати, довольно интересное выступление про MongoDB, и почему они перешли в своих тулзах на go:
ftp.belnet.be/FOSDEM/2015/devroom-go/mongo_go.mp4
Там как раз java/c++ бекграунд у выступающего.
ftp.belnet.be/FOSDEM/2015/devroom-go/mongo_go.mp4
Там как раз java/c++ бекграунд у выступающего.
кроме экономии памяти (которая нынче дешёвая)
Я абсолютно не защищаю Go (отношусь к нему нейтрально, хотя как мейнтейнер пакетов на нём в дистрибутиве имею к нему претензии, но знаю так же и о его преимуществах), но вот этот ваш аргумент у меня вызывает жжение пониже спины каждый раз когда я его слышу в какой угодно дискуссии на тему программирования. Потому что люди, которые его используют, скорее всего, пользуются только Desktop-платформами и в составе системного блока у них серверные двух- и более процесорные материнские платы, с тридцатью слотами и поддержкой тысяч «планок» по 16 гигабайт каждая. А о том, что их продуктом могут пользоваться слегка на другом железе — предпочитают не думать.
Я как-то встречал где-то тут в комментариях к соседнему посту предложение каждому говорящему про то, что оперативная память стоит копейки и она намного дешевле труда программиста на обучение писать оптимизированный код, отвечать за свои слова делом и спонсировать увеличение объёма оперативной памяти в устройствах пользователей их ПО.
И вот как-то оно мне даже понравилось, знаете ли…
Да память дешевая, постоянная еще дешевле. Вот в андроид магазине раньше показывали размер приложений, а сейчас убрали. Всем пофик что там у пользователя — ставь и пользуйся или покупай более дорогую технику.
Что сказать — я тоже дико неодобряю это развитие событий, но понимаю что в глобальном смысле в этом есть некая логика.
Фактически пользователей вынуждают оплачивать более навороченные способы разработки софта.
Что сказать — я тоже дико неодобряю это развитие событий, но понимаю что в глобальном смысле в этом есть некая логика.
Фактически пользователей вынуждают оплачивать более навороченные способы разработки софта.
Я где-то говорил, что стоимость оперативной памяти означает, что не надо оптимизировать код? Я лишь сказал, что это (небольшая экономия памяти) не довод при выборе другого языка при прочих равных.
«В стартапе, если вы поставите на неверную технологию, ваши конкуренты сотрут вас с лица земли.»
Наивные влажные сны техногиков. Аудитории насрать на чём оно написано и насколько красиво отрефакторено. Куда важнее, что есть смайлики. И халява.
Наивные влажные сны техногиков. Аудитории насрать на чём оно написано и насколько красиво отрефакторено. Куда важнее, что есть смайлики. И халява.
Конкуренты != аудитория.
А ну, давайте, каждый заминусовавший комментарий выше, обоснует свой голос. :)
В цитате, на которую ссылаются на коммент выше ни слова нет про «аудиторию», речь исключительно о конкуренции и весь наезд про «влажные сны» — просто не по адресу. Такое бывает — быстро прочёл, ошибся, недопонял.
В цитате, на которую ссылаются на коммент выше ни слова нет про «аудиторию», речь исключительно о конкуренции и весь наезд про «влажные сны» — просто не по адресу. Такое бывает — быстро прочёл, ошибся, недопонял.
Конкуренты сотрут вас с лица земли если
1. Они лучше представляют себе доменную область
2. Они имеют большую экспертизу в области
3. Они имеют больший ресурс на маркетинг
4. Они имеют более квалифицированных программистов, способных создавать более предсказуемые и сопровождаемые продукты
5. Они принимают более правильные решения
…
101. Они пишут на Go, а вы — нет.
1. Они лучше представляют себе доменную область
2. Они имеют большую экспертизу в области
3. Они имеют больший ресурс на маркетинг
4. Они имеют более квалифицированных программистов, способных создавать более предсказуемые и сопровождаемые продукты
5. Они принимают более правильные решения
…
101. Они пишут на Go, а вы — нет.
Не совсем понял, почему в этом треде, но очевидно, что вопрос языка для стартапа подразумевается в контексте «при прочих равных».
А в этом мире где-то существуют прочие равные? :-)
А вообще — для стартапов решают языки, с большим количеством стабильных и удобных third-party и прочих building blocks — чтобы стартаперы не столько писали очередной oauth-client или еще что-то такое — а просто собирали из кирпичиков свой Proof Of Concept — который, в случае успеха, и можно будет начать переписывать на более подходящем для этого языке.
Но, к слову, Го действительно хорош и приятен в мире, где third-party менее важны
А вообще — для стартапов решают языки, с большим количеством стабильных и удобных third-party и прочих building blocks — чтобы стартаперы не столько писали очередной oauth-client или еще что-то такое — а просто собирали из кирпичиков свой Proof Of Concept — который, в случае успеха, и можно будет начать переписывать на более подходящем для этого языке.
Но, к слову, Го действительно хорош и приятен в мире, где third-party менее важны
Речь, скорее, о том, что если выбрана неверная технология (не масштабируема и т.п.), то в какой-то момент стартап не сможет развиваться. Тут то конкуренты вас и обгонят, если не прогадали с изначальным выбором.
Опять сказочки о том, что «неверно выбранная технология не позволит вам развиваться». По моим скромным наблюдениям есть одна неверная технология, которая мешает развиваться — это нехватка денег. Вот если выбрана технология нехватки денег, тогда да, с масштабированием начинаются проблемы. И не только с ним.
Почему сказочки?
Возьмите две крайности для примера: один стартап(А) выбрал Ruby, второй (Б) выбрал Asm для написания REST-бекенда. Знаю смешно, но я намеренно утрирую. Стартап Б пишет 8 месяцев современный REST-бекенд для API, стартап А за это время уже давным давно выходит на рынок, зарабатывает популярность и продается Гуглу.
Даже в более мягком сценарии — нужно менять/рефакторить код под новые условия/обстоятельства — у стартапа А на это уходит месяц, у стартапа Б ведущий программист вешается от депрессии (или увольняется), и еще год уходит на рефакторинг.
Сводить это к «технологии нехватки денег» — имхо, неверно. Да, можно вбухать еще кучу бабла, набрать рок-звезд по ассемблеру — но разве это решит проблему концептуально и будет правильно?
Возьмите две крайности для примера: один стартап(А) выбрал Ruby, второй (Б) выбрал Asm для написания REST-бекенда. Знаю смешно, но я намеренно утрирую. Стартап Б пишет 8 месяцев современный REST-бекенд для API, стартап А за это время уже давным давно выходит на рынок, зарабатывает популярность и продается Гуглу.
Даже в более мягком сценарии — нужно менять/рефакторить код под новые условия/обстоятельства — у стартапа А на это уходит месяц, у стартапа Б ведущий программист вешается от депрессии (или увольняется), и еще год уходит на рефакторинг.
Сводить это к «технологии нехватки денег» — имхо, неверно. Да, можно вбухать еще кучу бабла, набрать рок-звезд по ассемблеру — но разве это решит проблему концептуально и будет правильно?
> Даже в более мягком сценарии — нужно менять/рефакторить код под новые условия/обстоятельства — у стартапа А на это уходит месяц, у стартапа Б ведущий программист вешается от депрессии (или увольняется), и еще год уходит на рефакторинг.
Давайте будем реалистами, уволиться как раз лид из А, который вместо «Go» выучит «Bar» и пойдёт в следующий стартап продвигать очередную превосходную технологию.
К тому времени мода на Go пройдёт, а замену ему будут искать год, пока не забьют и перепишут на Java.
Давайте будем реалистами, уволиться как раз лид из А, который вместо «Go» выучит «Bar» и пойдёт в следующий стартап продвигать очередную превосходную технологию.
К тому времени мода на Go пройдёт, а замену ему будут искать год, пока не забьют и перепишут на Java.
Фейсбук написан на PHP. Вот уж хуже язык для такого проекта выбрать было просто невозможно. И Фейсбук от этого сомнительного решения страдает, швыряя бабло в проблему и надеясь решить её таким образом. Но у Фейсбука это бабло есть и проблема, в итоге, так или иначе решится.
Ну можно, конечно, писать все на Haskell, заодно занимаясь изобретением драйвера для монги, но DigitalOcean почему-то выбрал golang.
В котором, кстати, драйвер один из самых лучших, и используется 10gen в mongo-tools и MMS.
В котором, кстати, драйвер один из самых лучших, и используется 10gen в mongo-tools и MMS.
Ну можно, конечно, писать все на Haskell, заодно занимаясь изобретением драйвера для монги
Зачем? hackage.haskell.org/package/mongoDB
Подозреваю, что библиотек на разные случаи жизни у хаскеля даже побольше, чем у го.
Зачем — не знаю. Зато знаю, что драйвер на го юзают разработчики монги сами, хотя он был написан не их сотрудником.
Была статья про хаскель в продакте — habrahabr.ru/post/193722 — оттуда и взял.
Комьюнити у go больше, чем у хаскеля уже в несколько раз.
Была статья про хаскель в продакте — habrahabr.ru/post/193722 — оттуда и взял.
Комьюнити у go больше, чем у хаскеля уже в несколько раз.
Была статья про хаскель в продакте — habrahabr.ru/post/193722 — оттуда и взял.
Гм. Там было про «поддерживать», а не «изобретать», это две большие разницы. Ну и неизвестно, в каком состоянии был го-драйвер на тот момент (2012).
Комьюнити у go больше, чем у хаскеля уже в несколько раз.
Не расскажете, как меряли?
Как обычно, по гитхабу: Haskell vs go
А если ограничить по 5к звездам, то хаскель вообще пропадет, а у го останется 16 проектов.
В каком состоянии был го драйвер — уже другой вопрос :)
Знаете, что самое интересное?
github.com/mongodb-haskell/mongodb это форк github.com/selectel/mongoDB-haskell
Selectel.
Там даже целая цепочка форков. Выводы я даже боюсь делать.
То есть каждый раз мейнтейнеры бросали поддержку либы. Это просто само за себя говорит и даже не смешно, честное слово.
Получается, даже программисты selectel забили на поддержку? Что в комьюнити вообще творится?
А сравнивать либу на go и на haskell вообще не имеет смысла по популярности.
А если ограничить по 5к звездам, то хаскель вообще пропадет, а у го останется 16 проектов.
В каком состоянии был го драйвер — уже другой вопрос :)
Знаете, что самое интересное?
github.com/mongodb-haskell/mongodb это форк github.com/selectel/mongoDB-haskell
Selectel.
Там даже целая цепочка форков. Выводы я даже боюсь делать.
То есть каждый раз мейнтейнеры бросали поддержку либы. Это просто само за себя говорит и даже не смешно, честное слово.
Получается, даже программисты selectel забили на поддержку? Что в комьюнити вообще творится?
А сравнивать либу на go и на haskell вообще не имеет смысла по популярности.
Ну а mgo создавался еще с «Mon Dec 27 15:38:02 2010», так что в 2012 был более чем юзабелен.
А почему именно по гитхабу? Многие хаскелисты предпочитают darcs и hackage или свои песочницы, так что сравнение некорректное.
А если, например, посчитать по активности на StackOverflow (и репутации лучших экспертов) — раз и два, народу в IRC (#haskell, #go-nuts), гугль-трендам, даже индексу TIOBE — сравнение идёт не в пользу го, и уж точно не «больше в несколько раз». Так что я бы поостерёгся с такими радикальными утверждениями.
Так-так, и о чём же это говорит? Возможно, о том, что желающие помейнтейнить и допилить хаскель-либу всегда находятся, и дело это несложное? Ой, нет, я всё-таки остерегусь судить о целом коммьюнити по одному пакету.
А если, например, посчитать по активности на StackOverflow (и репутации лучших экспертов) — раз и два, народу в IRC (#haskell, #go-nuts), гугль-трендам, даже индексу TIOBE — сравнение идёт не в пользу го, и уж точно не «больше в несколько раз». Так что я бы поостерёгся с такими радикальными утверждениями.
Это просто само за себя говорит
Так-так, и о чём же это говорит? Возможно, о том, что желающие помейнтейнить и допилить хаскель-либу всегда находятся, и дело это несложное? Ой, нет, я всё-таки остерегусь судить о целом коммьюнити по одному пакету.
Активность в stackoverflow очень показательна:
просмотров одинаково, время создания одинаково, но вот вопросов по хаскелю более чем в два раза больше возникло.
Ну и еще по stackoverflow:
Haskell: active 2 months ago
Golang: active yesterday
Хотя я не очень понимаю, что это значит.
Индекс TIOBE — абсолютно нерепрезентативен для go.
Если у вас есть большая площадка для opensource проектов чем github, то я с радостью посмотрю на цифры, которые она даст. Пока что хаскель там в 10 раз проигрывает go, по проектам, у которых больше 100 звезд, и в ∞ раз по проектам, у которых 5к звезд.
И я позволю себе сделать допущение, что более-менее популярный opensource проект будет иметь хотя бы зеркало на гитхабе.
Давайте сравним по top 10 проектам на Haskell и на Golang тогда.
Для меня сравнение по гитхабу более, чем корректное. У go там реальные проекты, которые используются тысячами людей. У haskell — библиотеки.
Docker, syncthing, kubernetes, etcd, да тот же самый github/hub — продукты.
По индексу tiobe хаскель ниже D, nuff said.
просмотров одинаково, время создания одинаково, но вот вопросов по хаскелю более чем в два раза больше возникло.
Ну и еще по stackoverflow:
Haskell: active 2 months ago
Golang: active yesterday
Хотя я не очень понимаю, что это значит.
Индекс TIOBE — абсолютно нерепрезентативен для go.
Если у вас есть большая площадка для opensource проектов чем github, то я с радостью посмотрю на цифры, которые она даст. Пока что хаскель там в 10 раз проигрывает go, по проектам, у которых больше 100 звезд, и в ∞ раз по проектам, у которых 5к звезд.
И я позволю себе сделать допущение, что более-менее популярный opensource проект будет иметь хотя бы зеркало на гитхабе.
Давайте сравним по top 10 проектам на Haskell и на Golang тогда.
Для меня сравнение по гитхабу более, чем корректное. У go там реальные проекты, которые используются тысячами людей. У haskell — библиотеки.
Docker, syncthing, kubernetes, etcd, да тот же самый github/hub — продукты.
По индексу tiobe хаскель ниже D, nuff said.
но вот вопросов по хаскелю более чем в два раза больше возникло
Ну да. Это может свидетельствовать как о том, что язык более сложный, так и о том, что изучающих его больше.
Индекс TIOBE — абсолютно нерепрезентативен для go.
Ну с той же убедительностью — количество звёздочек на гитхабе абсолютно нерепрезентативны для %langname%.
И я позволю себе сделать допущение, что более-менее популярный opensource проект будет иметь хотя бы зеркало на гитхабе.
Очсмелое допущение. Как минимум двух, пожалуй, самых популярных хаскельных программ — Darcs и xmonad — там нет.
Да и свет клином не сошёлся на этом вашем гитхабе. Я вот, например, битбакет предпочитаю.
Если у вас есть большая площадка для opensource проектов чем github, то я с радостью посмотрю на цифры, которые она даст.
hackage.haskell.org
У go там реальные проекты, которые используются тысячами людей. У haskell — библиотеки.
Это по-прежнему мало чего говорит о размерахязыкового коммьюнити — скорее, о его практичности. Я ещё могу поверить в то, что программисты на го пишут больше полезного софта, а на хаскеле — факториалов и учебников по монадам. Но откуда якобы следует, что первых «в разы» больше, чем вторых, кроме каких-то циферок на отдельно взятом гитхабе, не пойму.
Ну да. Это может свидетельствовать как о том, что язык более сложный, так и о том, что изучающих его больше.
Изучающих там одинаковое количество, если примерно.
Да, это говорит о том, что разработка языке Haskell более сложна.
Ну с той же убедительностью — количество звёздочек на гитхабе абсолютно нерепрезентативны для %langname%.
Значит, признаем, что D и Dart намного популярнее Haskell?
Да и свет клином не сошёлся на этом вашем гитхабе. Я вот, например, битбакет предпочитаю.
Еще раз: если у вас есть большая площадка для opensource проектов чем github, то я с радостью посмотрю на цифры, которые она даст.
Я ещё могу поверить в то, что программисты на го пишут больше полезного софта, а на хаскеле — факториалов и учебников по монадам.
Возможно, это так и есть, и сообщества сравнимы. Видимо из-за того, что сейчас я направлен на практичность и opensource софт, я воспринимаю реальность слегка искаженно :) С «разами» я погорячился.
«Превосходя посредственность» («Beating the averages» — ориг).
Типичная «оговорочка». Посредственный — это mediocre. А average — это средний. Это очень хорошо видно вот в этой фразе:
If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business.
В ней речь идет о том, что если вы делаете «как все», то вы и получите «как у всех» — что для стартапа смертельно.
Да, я вообще в черновике это перевёл в лоб как «Побеждая середнячков» :) — ну, оно и по контексту оригинальной статьи так. Но всё таки не звучало, и лучшего перевода я не нашел.
А «середнячков» тоже плохо, потому что это оценочное (в отличие от английского average). Напишите «средний уровень».
Собственно, в оригинале имеется в виду победа над статистическим распределением (навыков, качества и так далее).
Собственно, в оригинале имеется в виду победа над статистическим распределением (навыков, качества и так далее).
Резонно. Но, уже, пожалуй поздно менять, да и «Побеждая посредственность» выглядит немного лучше, чем «Побеждая средний уровень». Хотя мне оба не сильно нравятся, если честно. :) Но спасибо за вариант.
Понимаете ли… то, что оно для вас «лучше выглядит» означает, что вы так думаете: что «противники» Go — это посредственность. Я потому сразу и сказал, что это очень характерная оговорка.
Превосходя прочих.
Почему Го превосходит прочих.
Но я бы назвал
Выше радуги.
Почему Го выше радуги.
Много ассоциаций и таинственности.
Почему Го превосходит прочих.
Но я бы назвал
Выше радуги.
Почему Го выше радуги.
Много ассоциаций и таинственности.
А как сейчас модно деплоить go приложения? Есть какие-нибудь best practices?
В случае с рельсами это банальный конфиг для mina/capistrano, который работает из коробки (ну еще 5 строчек в конфиг nginx+passenger добавить).
В случае с go – непонятно, как перезапускать сервер после деплоя (делать init сервисы? Использовать какой-нибудь supervisord? Запускать и демонизировать руками?), как хранить и распространять, в случае веб-приложения, js/css/картинки, как минифицировать ассеты и прочее. Пытался поверхностно погуглить на эту тему – ничего полноценного и простого не нашел.
В случае с рельсами это банальный конфиг для mina/capistrano, который работает из коробки (ну еще 5 строчек в конфиг nginx+passenger добавить).
В случае с go – непонятно, как перезапускать сервер после деплоя (делать init сервисы? Использовать какой-нибудь supervisord? Запускать и демонизировать руками?), как хранить и распространять, в случае веб-приложения, js/css/картинки, как минифицировать ассеты и прочее. Пытался поверхностно погуглить на эту тему – ничего полноценного и простого не нашел.
А как сейчас модно деплоить go приложения? Есть какие-нибудь best practices?
Ну тут (не только касательно Go) зоопарк целый. Обычно пользуют те решения, к которым привыкли/есть в стеке.
Если не критичен простой, то банальным stop/change binary/start, если критичен — то разными методами zero downtime restart. Супервизор или systemd — и то и другое в ходу. Можно и через докер push/pull деплоить. Я думаю, что всего зоопарка решений я даже не знаю.
как хранить и распространять, в случае веб-приложения, js/css/картинки, как минифицировать ассеты и прочее
Я пользую go-bindata, но есть еще подобные проекты, вроде go-rice, там есть и удобные врапперы для использования с http-либой. Про минификацию — какие-то проскакивали решения (так не вспомню сходу, не пользую), но имхо, если речь о фронтенде, то лучше минифицировать стандартными решениями для фронтенд-разработки, и засовывать в assets уже минифицированный код.
Деплой сложнейший, целых два пункта:
Инит-скрипты, к счастью, в 90% случаев пишутся копированием соседнего инит-скрипта и исправлению в нём путей к бинарникам.
- Собрать пакет
- Поставить пакет
Инит-скрипты, к счастью, в 90% случаев пишутся копированием соседнего инит-скрипта и исправлению в нём путей к бинарникам.
А чем, собственно, Lisp, о котором и писал Грэхам, плох в роли стартап-оружия? Ведь там, всё то же самое плюс сетевые REPL-ы и разнообразные библиотеки, семантика которых отрабатывалась десятилетями. Любой современный Lisp типа Clojure, Shen или LFE существенно мощнее Go по скорости разработки кода.
Да, тут особый цинизм.
1. Взять статью Грэма о лиспе
2. Написать, что язык X проще «в написании», «в понимании», «для деплоя»
3. Толсто намекнуть, что остальные языки рядом не валялись, «тут слишком много плюсов и ноль минусов»
4. ???
5. PROFIT!!!
1. Взять статью Грэма о лиспе
2. Написать, что язык X проще «в написании», «в понимании», «для деплоя»
3. Толсто намекнуть, что остальные языки рядом не валялись, «тут слишком много плюсов и ноль минусов»
4. ???
5. PROFIT!!!
Не знаю, но я верю в эффективность конкурентных рынков. Если бы Lisp был так хорош и удачен, отвечал бы требованием времени и вписывался в экосистему, не сомневайтесь — его бы использовали, коммьюнити росло, а обучающие материалы и success stories появлялись бы экспоненциально. Видимо, чего-то нет.
Отвечу за себя — в моём понимании, Lisp даже не рассматривается как язык для серверного софта, особенно для стартапа. Если бы я нанял CTO и он бы мне сказал — будем писать на Lisp-е, я бы подробно пообщался с человеком, чтобы выяснить а) адекватно ли он понимает рынок существующих инструментов и языков, б) возможно я чего-то очень важного не знаю про Lisp и там действительно выгода на выгоде и выгодой погоняет. Так-то я вижу хайп вокруг Clojure, но пока тоже ни одного веского аргумента даже для «посмотреть более внимательно» я не имею — код, который мне попадается, мне не нравится — поэтому я пока отношу Clojure к «не подходят под личные предпочтения», но стараюсь регулярно присматриваться, всё таки этот рынок динамичный и упираться в одни технологии из принципа нельзя.
Отвечу за себя — в моём понимании, Lisp даже не рассматривается как язык для серверного софта, особенно для стартапа. Если бы я нанял CTO и он бы мне сказал — будем писать на Lisp-е, я бы подробно пообщался с человеком, чтобы выяснить а) адекватно ли он понимает рынок существующих инструментов и языков, б) возможно я чего-то очень важного не знаю про Lisp и там действительно выгода на выгоде и выгодой погоняет. Так-то я вижу хайп вокруг Clojure, но пока тоже ни одного веского аргумента даже для «посмотреть более внимательно» я не имею — код, который мне попадается, мне не нравится — поэтому я пока отношу Clojure к «не подходят под личные предпочтения», но стараюсь регулярно присматриваться, всё таки этот рынок динамичный и упираться в одни технологии из принципа нельзя.
1. А его используют и коммьюнити достаточно велико. «Проблема» в том, что Lisp-ы простые, как валенки. Там нет хитрых синтаксических правил. Там есть очень хорошие практики программирования, наработанные за много лет. Хорошая документация. Собственно, даже обсуждать-то и нечего. Все возникающие вопросы решаются за 5 минут прямо в REPL при помощи встроенной документации. Поэтому в интернетах обсуждать почти нечего. Это Вам не TeX и не Haskell. Поэтому, вроде как, и создаётся ощущение, что «никто не пользуется». На самом деле, пользуются многие. Сама Google вот, например.
2. На Lisp-е надо попробовать сначала пописать. И Вы сразу же обнаружите, что пункт «б». Если просто читать код, то он всегда будет казаться непривычным и, поэтому, корявым. Но если начать писать, то сразу становится очевидной элегантность и мощь подхода.
Я вот тоже считал Lisp-ы чем-то странноватым и корявым, пока не заставил себя порешать на Clojure задачки из SPOJ (мотивирован был тем, что ну не могут такие люди, как Грэхам, Норвиг и целая студия Naughty Dog отдавать предпочтение неэффективному инструменту, должно быть в Lisp-ах что-то).
Первая эмоция — восторг от мощи, лаконичности и поддержки со стороны редакторов или IDE (всё же отуствие синтаксиса — это огромное облегчение для автоматизации, поэтому автоматизации там дофигища). Сразу начинаешь себя ощущать эльфом 80-го уровня от программирования. Писал до этого, в основном, на Си, Bash, Python и Go. Ни в какое сравнение. Clojure многократно удобнее.
3. Лично мои аргументы в пользу Lisp-ов:
3.1. Naughty Dog писали Uncharted на Lisp-е. Получился задорный первый в мире стриминг уровней.
3.2. Грэхам написал первый в мире байесовский спам-фильтр на Lisp.
3.3. Норвиг написал первое в мире руководство по практическому AI на Lisp.
3.4. Хики написал первую в мире распределённую базу знаний на Clojure.
3.5. Фьючерсы появились сначала в Lisp-ах.
Ну и т.д. Если копаться, то много чего «первого в мире» было понаписано сначала на Lisp-ах. Процесс разработки способствует именно такому исследовательскому стилю программирования.
4. Я не утверждаю, что вот Lisp-ы — это такая серебрянная пуля. Но, определённо, Lisp-ы под статью Грэхама подходят гораздо в большей степени, чем Go. В Go ещё много чего нет, что уже давно и эффективно есть в Lisp-ах. Я бы CTO, ориентированного на Lisp не стал бы прогонять. А дал бы ему задачку и посмотрел бы, как быстро он её решит.
2. На Lisp-е надо попробовать сначала пописать. И Вы сразу же обнаружите, что пункт «б». Если просто читать код, то он всегда будет казаться непривычным и, поэтому, корявым. Но если начать писать, то сразу становится очевидной элегантность и мощь подхода.
Я вот тоже считал Lisp-ы чем-то странноватым и корявым, пока не заставил себя порешать на Clojure задачки из SPOJ (мотивирован был тем, что ну не могут такие люди, как Грэхам, Норвиг и целая студия Naughty Dog отдавать предпочтение неэффективному инструменту, должно быть в Lisp-ах что-то).
Первая эмоция — восторг от мощи, лаконичности и поддержки со стороны редакторов или IDE (всё же отуствие синтаксиса — это огромное облегчение для автоматизации, поэтому автоматизации там дофигища). Сразу начинаешь себя ощущать эльфом 80-го уровня от программирования. Писал до этого, в основном, на Си, Bash, Python и Go. Ни в какое сравнение. Clojure многократно удобнее.
3. Лично мои аргументы в пользу Lisp-ов:
3.1. Naughty Dog писали Uncharted на Lisp-е. Получился задорный первый в мире стриминг уровней.
3.2. Грэхам написал первый в мире байесовский спам-фильтр на Lisp.
3.3. Норвиг написал первое в мире руководство по практическому AI на Lisp.
3.4. Хики написал первую в мире распределённую базу знаний на Clojure.
3.5. Фьючерсы появились сначала в Lisp-ах.
Ну и т.д. Если копаться, то много чего «первого в мире» было понаписано сначала на Lisp-ах. Процесс разработки способствует именно такому исследовательскому стилю программирования.
4. Я не утверждаю, что вот Lisp-ы — это такая серебрянная пуля. Но, определённо, Lisp-ы под статью Грэхама подходят гораздо в большей степени, чем Go. В Go ещё много чего нет, что уже давно и эффективно есть в Lisp-ах. Я бы CTO, ориентированного на Lisp не стал бы прогонять. А дал бы ему задачку и посмотрел бы, как быстро он её решит.
Я бы сказал, что такой комментарий к статье получше, чем исходная статья.
Если бы выражался в стиле современной прессы — «убийца статьи» :)
А вы только на Clojure писали из лисп-подобных?
Не подскажете хорошую книгу для описания как применять Лисп на практике?
SICP я прочёл и примеры прорешал.
Вот хотелось бы всё-таки помимо теоретико-интеллектуального профита (улучшение кода LINQ, python и т.д.) получить ещё и практический.
И, повторюсь, комментарий просто великолепный.
Если бы выражался в стиле современной прессы — «убийца статьи» :)
А вы только на Clojure писали из лисп-подобных?
Не подскажете хорошую книгу для описания как применять Лисп на практике?
SICP я прочёл и примеры прорешал.
Вот хотелось бы всё-таки помимо теоретико-интеллектуального профита (улучшение кода LINQ, python и т.д.) получить ещё и практический.
И, повторюсь, комментарий просто великолепный.
1. Lisp-ы часто, на самом деле, встречаются в системах, как встроенные языки. Поэтому довелось программировать ещё и на Sсheme. Но в этих случаях я особо не рефликсировал и не сравнивал с другими языками. Просто не было выбора, в тонкости не вникал, оптимальных решений не искал. С Clojure я в более тесных отношениях (в основном, из-за желания освоивть JVM и программирование для браузеров, а то отстал как-то от жизни).
2. Я вот сейчас пытаюсь прочитать AI: Modern Approach. Вот тут алгоритмы из книги, реализованные на Common Lisp (не самый лучший Lisp, как мне кажется, но Норвиг просто жгёт. Даже если нет никакого желания учить Lisp этот код стоит почитать): aima.cs.berkeley.edu/lisp/doc/overview.html
2. Я вот сейчас пытаюсь прочитать AI: Modern Approach. Вот тут алгоритмы из книги, реализованные на Common Lisp (не самый лучший Lisp, как мне кажется, но Норвиг просто жгёт. Даже если нет никакого желания учить Lisp этот код стоит почитать): aima.cs.berkeley.edu/lisp/doc/overview.html
Оу, оу, оу! Ещё одну замечательную книжку чуть не забыл: Vector Models for Data-Parallel Computing. Опять же, отсюда пошло всё современное GPGPU.
Спасибо за ответ!
AIMA я читал, правда как ИИСП :) И упражнения не решал, т.к. LISP не знал.
Как-нибудь наверно вернусь и посмотрю на код.
Про векторные модели тоже посмотрю обязательно.
Я как-то нашёл ещё одну книгу, сам не читал, но сдаётся мне, что здесь Норвиг жжёт не менее :)
Если серьёзно, то для целей обучения Лиспу она наверно подходит ещё больше
Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp
AIMA я читал, правда как ИИСП :) И упражнения не решал, т.к. LISP не знал.
Как-нибудь наверно вернусь и посмотрю на код.
Про векторные модели тоже посмотрю обязательно.
Я как-то нашёл ещё одну книгу, сам не читал, но сдаётся мне, что здесь Норвиг жжёт не менее :)
Если серьёзно, то для целей обучения Лиспу она наверно подходит ещё больше
Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp
Я сам использую go, люблю его, но приведение последнего сравнения про переход с rails/django на go из-за простоты в деплое неадекватный. Если даже не брать во внимание что вы сравниваете web — фреймворки с яп, аргументы, что мол для них нужно capfile писать, а там один бинарник, и не нужен nginx/haproxy как то слишком. Вы пайплайн ассетов в бинарник засунете? Nginx/Haproxy Вы для одного хоста используете и лоадбалансер (как минимум, как вы понимаете, вы же сами недавно перевод делали про роль go в docker/coreos/hashicorp) не нужен? Не go-third-party зависимостей у Вас в проекте не бывает? Вы с помощью «rsync symlink и run» (тут вообще посмеялся) миграцию откатите?
Мне, честно, очень нравится golang, но я не понимаю, почему его то с clojurescript сравнивают, то с веб фреймворками.
Мне, честно, очень нравится golang, но я не понимаю, почему его то с clojurescript сравнивают, то с веб фреймворками.
Вы пайплайн ассетов в бинарник засунете?
У меня в проектах это делается автоматически через go generate, да. Но речь же не только об ассетах, там достаточно сложности, от которой single binary избавляет.
почему его то с clojurescript сравнивают, то с веб фреймворками.
Я думаю, причина тут банально в том, что задача «бекенд для мобильного приложения для стартапа» — это популярная задача, и способы её решить — одна из обсуждаемых тем, и Go тут явно игрок.
Задачка:
Есть база невалидных паспортов www.fms.gov.ru/upload/expired-passports/list_of_expired_passports.csv.bz2
требуется утилитка для проверки паспорт нормальный или нет.
Требования:
1) минимум занимаемого места на диске, минимум оперативки, минимум cpu, отрабатывать должна быстро.
2) обновляется раз в сутки
3) базы данных не использовать.
4) не российскими паспортами можно(нужно) пренебречь.
Пример работы:
Обновление, разархивацию отдается на откуп cron, bash.
С удовольствием посмотрю на реализацию на Go и сравню со своим вариантом.
Есть база невалидных паспортов www.fms.gov.ru/upload/expired-passports/list_of_expired_passports.csv.bz2
требуется утилитка для проверки паспорт нормальный или нет.
Требования:
1) минимум занимаемого места на диске, минимум оперативки, минимум cpu, отрабатывать должна быстро.
2) обновляется раз в сутки
3) базы данных не использовать.
4) не российскими паспортами можно(нужно) пренебречь.
Пример работы:
/var/www/passports$ du -h --max-depth=1 .
351M ./passports
366M .
> # Размер подготовленных данных
[host]/var/www/passports$ time ./passports_check 0000000000
1
> # плохой паспорт
./passports_check 0000000000 0,00s user 0,00s system 75% cpu 0,004 total
[host]/var/www/passports$ time ./passports_check 0000000005
0
> # хороший паспорт
./passports_check 0000000005 0,00s user 0,00s system 76% cpu 0,004 total
Обновление, разархивацию отдается на откуп cron, bash.
С удовольствием посмотрю на реализацию на Go и сравню со своим вариантом.
Интересный у вас подход )
Но если ваши главные требования «минимум оперативки и минимум cpu» — то это лучше на C делать. Все-таки Go жертвует немного памятью и cpu, в пользу простоты языка — и это был сознательный компромисс. Сейчас актуальнее экономить время и силы, потраченные на реализацию кода, а не килобайты ОЗУ, которое, в сравнении со стоимостью человеко-часа сейчас совсем дешевое.
По поводу вашего условия — а алгоритм определения «хороший/плохой» укажите, а то пока ясно только, что 0000000000 — хороший, а 0000000005 — плохой :)
Но если ваши главные требования «минимум оперативки и минимум cpu» — то это лучше на C делать. Все-таки Go жертвует немного памятью и cpu, в пользу простоты языка — и это был сознательный компромисс. Сейчас актуальнее экономить время и силы, потраченные на реализацию кода, а не килобайты ОЗУ, которое, в сравнении со стоимостью человеко-часа сейчас совсем дешевое.
По поводу вашего условия — а алгоритм определения «хороший/плохой» укажите, а то пока ясно только, что 0000000000 — хороший, а 0000000005 — плохой :)
Ups, sorry, пока редактировал ошибся.
В файле список плохих паспортов, номер паспорта это 10 значное число.
Если номер паспорта входит в этот список он плохой(1), если нет, то хороший(0).
А на тему экономии времени — силы, там около 100 строк кода включая импорты библиотек.
И результат тоже в виде статически скомпилированного бинарника.
В файле список плохих паспортов, номер паспорта это 10 значное число.
Если номер паспорта входит в этот список он плохой(1), если нет, то хороший(0).
А на тему экономии времени — силы, там около 100 строк кода включая импорты библиотек.
И результат тоже в виде статически скомпилированного бинарника.
А, ясно. Хотя тогда непонятно требование к «не российскими паспортами можно(нужно) пренебречь».
Вообще, вот такое «сравнение» по хорошему вы должны сделать самостоятельно — всё таки для сравнения производительности такой задачи, как «перелопатить csv» файлик, тут важнее выбрать правильный подход к задаче и правильно оценить компромиссы между нагрузкой на IO, CPU и памятью. Не говоря уже о том, что если файл обновляется раз в сутки, то лучше его один раз отсортировать/свести и все проверки делать уже на подготовленном датасете. Тоесть или вы имплементируйте — или опишите точно ваше решение.
К примеру, решение «в лоб» у меня отняло 15 минут, но оно, явно не самое эффективное, и можно оптимизировать. Задействуется 1 кор CPU, полный проход на моем макбуке занимает 2m23s. Хотя это решение — полноценный тул, с тестами, бенчмарком, комментариями, обработкой параметров командной строки и обработкой ошибок.
Вообще, вот такое «сравнение» по хорошему вы должны сделать самостоятельно — всё таки для сравнения производительности такой задачи, как «перелопатить csv» файлик, тут важнее выбрать правильный подход к задаче и правильно оценить компромиссы между нагрузкой на IO, CPU и памятью. Не говоря уже о том, что если файл обновляется раз в сутки, то лучше его один раз отсортировать/свести и все проверки делать уже на подготовленном датасете. Тоесть или вы имплементируйте — или опишите точно ваше решение.
К примеру, решение «в лоб» у меня отняло 15 минут, но оно, явно не самое эффективное, и можно оптимизировать. Задействуется 1 кор CPU, полный проход на моем макбуке занимает 2m23s. Хотя это решение — полноценный тул, с тестами, бенчмарком, комментариями, обработкой параметров командной строки и обработкой ошибок.
Присмотрелся к вашему выводу:
а) размер файла по ссылке там 1Гб
б) 0.004 секунды на весь поиск? Это означает, что данные как-то подготовлены уже. За такое время даже считать диска ни один самый шустрый IO не даст.
Что-то либо я недопонял, либо вы не договорили)
а) размер файла по ссылке там 1Гб
б) 0.004 секунды на весь поиск? Это означает, что данные как-то подготовлены уже. За такое время даже считать диска ни один самый шустрый IO не даст.
Что-то либо я недопонял, либо вы не договорили)
Данные готовите как хотите, по ним и ищете.
У меня размен подготовленных данных
351M ./passports
Полный перебор это понятно что не вариант.
Читается с диска, обычный hdd.
Озу по моему в районе 3 мегабайт отъедает.
Да 0.004 секунды на весь поиск.
Не российские паспорта с буквами. Их в процессе парсинга файла пропускаем.
Размер csv 1G, количество записей ~92 миллиона.
Обновляется один раз в сутки, готовим датасет, потом по нему ищем.
Бенчмари, тесты не особо нужны, задачка слишком маленькая, комментарии по желанию.
Обработка командной строки по желанию, руками это никто не запускает.
У меня это тупо 2 утилиты генерятся с одного кода.
Подготовка датасета:
> passports_db list_of_expired_passports.csv
проверка паспорта:
> passports_check 0000000000
Будет код кидайте ссылку на github, завтра скомпилирую, сравню.
У меня размен подготовленных данных
351M ./passports
Полный перебор это понятно что не вариант.
Читается с диска, обычный hdd.
Озу по моему в районе 3 мегабайт отъедает.
Да 0.004 секунды на весь поиск.
Не российские паспорта с буквами. Их в процессе парсинга файла пропускаем.
Размер csv 1G, количество записей ~92 миллиона.
Обновляется один раз в сутки, готовим датасет, потом по нему ищем.
Бенчмари, тесты не особо нужны, задачка слишком маленькая, комментарии по желанию.
Обработка командной строки по желанию, руками это никто не запускает.
У меня это тупо 2 утилиты генерятся с одного кода.
Подготовка датасета:
> passports_db list_of_expired_passports.csv
проверка паспорта:
> passports_check 0000000000
Будет код кидайте ссылку на github, завтра скомпилирую, сравню.
По результату расскажу детальный алгоритм своего кода, ну и ссылку на исходники дам.
По сути задача в том, чтобы построить индекс (binary tree?) и по нему уже искать совпадение.
Ну или bloom filter.
Для binary tree есть boltdb, основанный на «memory-mapped» файлах и B+tree, может потреблять довольно много памяти, если ему дать. Boltdb — embedded, и попадает под условие «не использовать базы данных».
Я бы для скорости запустил это как сервер, доступный по http ручке, тогда бы не пришлось каждый раз гонять данные из оперативной памяти на диск и обратно.
351М это очень хороший результат по моей оценке, у вас написан хороший алгоритм.
Разница в интересных вам характеристиках больше зависит от выбранного алгоритма, чем от того, на каком языке реализовывать :)
Если среди компилируемых смотреть, конечно.
По моим оценкам Go будет медленней в 3-2.5 раза решению на C++.
Просто не понятно, что вам интересно.
Ну или bloom filter.
Для binary tree есть boltdb, основанный на «memory-mapped» файлах и B+tree, может потреблять довольно много памяти, если ему дать. Boltdb — embedded, и попадает под условие «не использовать базы данных».
Я бы для скорости запустил это как сервер, доступный по http ручке, тогда бы не пришлось каждый раз гонять данные из оперативной памяти на диск и обратно.
351М это очень хороший результат по моей оценке, у вас написан хороший алгоритм.
Разница в интересных вам характеристиках больше зависит от выбранного алгоритма, чем от того, на каком языке реализовывать :)
Если среди компилируемых смотреть, конечно.
По моим оценкам Go будет медленней в 3-2.5 раза решению на C++.
Просто не понятно, что вам интересно.
bloom filter не подходит, нужна 100% гарантия точности в обе стороны.
embedded в принципе можно, размер на диске больше будет, на вскидку.
А смысл в http протоколе? тогда уж лучше redis или memcached протокол. Избыточности меньше а кода столько же. Как сервис не реализовано потому как нет необходимости, да и выигрыша не будет, процессы которые дергают короткоживущие, соединение хранить не получится. Данные с диска в оперативку постоянно не гоняются, дисковый кэш срабатывает.
Мне интересно решение в лоб человеком который постоянно пишет на go. Сама реализация, выбор алгоритмов, структуры данных которые будут использоваться.
Язык очень простой, задача тоже. Go по скорости и ресурсам здесь за глаза.
Кода здесь много быть не должно, ну пара сотен строк кода это наверно максимум.
embedded в принципе можно, размер на диске больше будет, на вскидку.
А смысл в http протоколе? тогда уж лучше redis или memcached протокол. Избыточности меньше а кода столько же. Как сервис не реализовано потому как нет необходимости, да и выигрыша не будет, процессы которые дергают короткоживущие, соединение хранить не получится. Данные с диска в оперативку постоянно не гоняются, дисковый кэш срабатывает.
Мне интересно решение в лоб человеком который постоянно пишет на go. Сама реализация, выбор алгоритмов, структуры данных которые будут использоваться.
Язык очень простой, задача тоже. Go по скорости и ресурсам здесь за глаза.
Кода здесь много быть не должно, ну пара сотен строк кода это наверно максимум.
bloom filter можно использовать с чем-нибудь еще для отлова false-positive
Основная сложность задачи — выбор и реализация алгоритма.
В лоб с boltb получается индекс где-то раз в 10-20 больше, чем у вас по диску, и он довольно долго строится. По оперативке и cpu — примерно так же, как у вас.
Как-то иначе решать задачу у меня пока не хватило времени, если бы она стояла передо мной — я бы просто взял БД и загрузил в нее данные.
Хотя и не в 10-20, а меньше 10, но все равно он слишком долго строится.
Основная сложность задачи — выбор и реализация алгоритма.
В лоб с boltb получается индекс где-то раз в 10-20 больше, чем у вас по диску, и он довольно долго строится. По оперативке и cpu — примерно так же, как у вас.
Как-то иначе решать задачу у меня пока не хватило времени, если бы она стояла передо мной — я бы просто взял БД и загрузил в нее данные.
Хотя и не в 10-20, а меньше 10, но все равно он слишком долго строится.
Ясно, ну я продолжать не буду с таким количеством guesswork — а вот когда расскажете алгоритм, то будет интересно его таки имплементировать и сравнить результаты.
Про бенчмарки, тесты и прочее я специально упомянул, что это хоть и «не особо нужно», но это слишком просто делается в Go, чтобы это не делать всегда :)
Кстати, солидарен с комментом выше, я бы тоже сделал веб-сервис, который бы и обновлял данные при поступлении новых, и обрабатывал запросы на проверку.
Про бенчмарки, тесты и прочее я специально упомянул, что это хоть и «не особо нужно», но это слишком просто делается в Go, чтобы это не делать всегда :)
Кстати, солидарен с комментом выше, я бы тоже сделал веб-сервис, который бы и обновлял данные при поступлении новых, и обрабатывал запросы на проверку.
Требование к месту оперативке и тд, взяты не на пустом месте, это вполне реальный кейс.
Выбор С тут особенного выигрыша не даст, на самом деле написать под эти требования можно на любом компилируемом языке.
Выбор С тут особенного выигрыша не даст, на самом деле написать под эти требования можно на любом компилируемом языке.
Что-то медленный у вас алгоритм получается, ради интереса набросал вариант на PHP (даже не сильно оптимизированный).
Единственное время замерял в самом PHP, чтобы исключить затраты на компиляцию.
Поиск 1000 случайных паспортов, занимает 0.09 секунды, или 0.09 мс на один паспорт. И это при каждом поиске еще файлы с данными открываются, если открытие файла вынести из цикла то скорость увеличится до 0.03 мс на запрос.
Ищет по двум файлам (которые в принципе можно склеить, лень было) общим объемом 181 МБ. Можно конечно еще оптимизировать, если нужно много паспортов проверять за раз.
Если интересно могу выложить.
Единственное время замерял в самом PHP, чтобы исключить затраты на компиляцию.
Поиск 1000 случайных паспортов, занимает 0.09 секунды, или 0.09 мс на один паспорт. И это при каждом поиске еще файлы с данными открываются, если открытие файла вынести из цикла то скорость увеличится до 0.03 мс на запрос.
Ищет по двум файлам (которые в принципе можно склеить, лень было) общим объемом 181 МБ. Можно конечно еще оптимизировать, если нужно много паспортов проверять за раз.
Если интересно могу выложить.
почему базы данных не использовать?
Помоем как раз самый простой и надежный способ использовать sqlite.
На подготовку данных уйдет порядка минуты наверное, но потом по индексу искать будет очень быстро, нужна же только одна таблица с полем integer ( так как РФ паспорта вроде не имеют букв в номере).
Помоем как раз самый простой и надежный способ использовать sqlite.
На подготовку данных уйдет порядка минуты наверное, но потом по индексу искать будет очень быстро, нужна же только одна таблица с полем integer ( так как РФ паспорта вроде не имеют букв в номере).
Потому что задача измерить производительность языка, насколько я понимаю.
для измерения языка автор бы привел алгоритм и измерение скорости языка заключалось бы в сравнении скорости выполнения этого алгоритма на разных языках на одной машине.
Тут задача о правильном алгоритме, как по мне в sqlite есть нужные правильные алгоритмы и изобретать велосипед тут нужно только имея очень суровые обоснования.
Тут задача о правильном алгоритме, как по мне в sqlite есть нужные правильные алгоритмы и изобретать велосипед тут нужно только имея очень суровые обоснования.
Любая база съест места на порядок больше, хотя конечно возможны варианты. И она здесь тупо излишняя, это фиксированный кейс, один тип запроса, всегда одни и те же данные.
Посмотрел по коду:
17 строк упаковка данных в бинарный формат и сортировка.
11 строк проверка паспорта.
Велосипед даже до колеса не дотягивает. )
Посмотрел по коду:
17 строк упаковка данных в бинарный формат и сортировка.
11 строк проверка паспорта.
Велосипед даже до колеса не дотягивает. )
ну sqlite подхода есть еще большое преимущество — можно делать пачку конкурентных read-only запросов используя ту-же память но утилизируя разные ядра процессора, распаралеливая тем самым нагрузку.
sqlite не сильно подходит, слишком здоровый файл получится, нужно будет 6 байтовый integer использовать (так как в 4 байта не влазит), это только данные будут занимать 520 МБ, а с индексом и больше гига может. В то время как я набросал вариант со своим бинарным форматом, которому хватает 181 МБ, да и по скорости выиграет у sqlite, причем на порядки.
Ну и продолжение сказочки:
Появилась тема на рынке, народ покумекал и решил бабло заколачивать.
админ chemistmail побыстрому зафигачил свой сервис на haskell, взял атом в облаке, и процесс пошел.
программист zapimir тоже по быстрому зафигачил аналог на php, взял такой же атом, и тоже зарабатывает деньги.
А группа парней решила откусить кусок от пирога который делят chemistmail и zapimir, собрались они в команду,
написали свой сервис на go, с документацией, тестами и прочими плюшками.
Все хорошо, только база на один сервер не помещается, ну дело поправимое, шардинг не глупые люди придумали.
В итоге заняли они пару — тройку i7 с большими дисками, да вот не задача, стоимость запроса у них дороговатая получается, не получается у них кусок то откусить от рынка.
И где то они прокололись. Тут и сказочке конец, а кто слушал молодец.
PS: серебряная пуля не в языке, а в алгоритмах и структурах данных.
А когда на любой чих предлагается база данных, и говорится что там уже все придумали, получается тупо база данных, но ни как не сервис.
И на тему алгоритма. Решение в лоб.
Упаковка:
Чтоб быстро искать, нужно уложить данные чтоб их можно быстро читать.
У нас 10 значные числа, в Int32(Word32) влезет только 9 цифр.
Создаем 10 файлов от 0 до 9, по первой цифре определяем в каком файле паспорт будет храниться.
Оставшиеся 9 пакуем в Word32 и пишем сплошным потоком в файл. Получается каждые 4 байта паспорт.
После mmap и сортировка данных в каждом из файлов.
Для выборки:
mmap нужного файла по первой цифре, потом бинарный поиск.
Можно еще индекс сделать, будет еще быстрей, но мне и такого варианта хватило.
Если делать индекс, то делаем дерево для бинарного поиска ~ 90000 узлов на все. Это ~800к дополнительного места.
Больше делать смысла не вижу, размер блока при рандомном чтении 4к, то есть при таком размере индекса будет читаться одна страница, это 1024 паспорта.
Ну как то так.
zapimir: теперь можно и ваш вариант объяснить.
Появилась тема на рынке, народ покумекал и решил бабло заколачивать.
админ chemistmail побыстрому зафигачил свой сервис на haskell, взял атом в облаке, и процесс пошел.
программист zapimir тоже по быстрому зафигачил аналог на php, взял такой же атом, и тоже зарабатывает деньги.
А группа парней решила откусить кусок от пирога который делят chemistmail и zapimir, собрались они в команду,
написали свой сервис на go, с документацией, тестами и прочими плюшками.
Все хорошо, только база на один сервер не помещается, ну дело поправимое, шардинг не глупые люди придумали.
В итоге заняли они пару — тройку i7 с большими дисками, да вот не задача, стоимость запроса у них дороговатая получается, не получается у них кусок то откусить от рынка.
И где то они прокололись. Тут и сказочке конец, а кто слушал молодец.
PS: серебряная пуля не в языке, а в алгоритмах и структурах данных.
А когда на любой чих предлагается база данных, и говорится что там уже все придумали, получается тупо база данных, но ни как не сервис.
И на тему алгоритма. Решение в лоб.
Упаковка:
Чтоб быстро искать, нужно уложить данные чтоб их можно быстро читать.
У нас 10 значные числа, в Int32(Word32) влезет только 9 цифр.
Создаем 10 файлов от 0 до 9, по первой цифре определяем в каком файле паспорт будет храниться.
Оставшиеся 9 пакуем в Word32 и пишем сплошным потоком в файл. Получается каждые 4 байта паспорт.
После mmap и сортировка данных в каждом из файлов.
Для выборки:
mmap нужного файла по первой цифре, потом бинарный поиск.
Можно еще индекс сделать, будет еще быстрей, но мне и такого варианта хватило.
Если делать индекс, то делаем дерево для бинарного поиска ~ 90000 узлов на все. Это ~800к дополнительного места.
Больше делать смысла не вижу, размер блока при рандомном чтении 4к, то есть при таком размере индекса будет читаться одна страница, это 1024 паспорта.
Ну как то так.
zapimir: теперь можно и ваш вариант объяснить.
Никто, кроме меня, над этой задачей даже не пытался особо думать :)
Код, если вам интересно — тут: github.com/cydev/passport
Очевидно, что там бинарный поиск.
Я просто взял под число 5 байт и засунул их в boltdb как ключи.
Получилось 3гб индекс вместо 350м, строится довольно долго, но поиск не сильно медленней вашего решения.
Это все я делал после работы, да и то т.к. не мог заснуть, пока не решил интересную (для меня) задачку. Boltdb я выбрал из-за того, что искал буквально недавно решение для похожей задачи для своего opensource проекта. Да, мне не хватило знаний, чтобы сделать достаточно эффективное решение, но я и не говорю, что я гуру алгоритмов :)
Соглашусь с вами в том, что серебреная пуля — в алгоритмах, но мне кажется, что именно это вам несколько раз и отвечали в этой ветке, нет?
Код, если вам интересно — тут: github.com/cydev/passport
Очевидно, что там бинарный поиск.
Я просто взял под число 5 байт и засунул их в boltdb как ключи.
Получилось 3гб индекс вместо 350м, строится довольно долго, но поиск не сильно медленней вашего решения.
Это все я делал после работы, да и то т.к. не мог заснуть, пока не решил интересную (для меня) задачку. Boltdb я выбрал из-за того, что искал буквально недавно решение для похожей задачи для своего opensource проекта. Да, мне не хватило знаний, чтобы сделать достаточно эффективное решение, но я и не говорю, что я гуру алгоритмов :)
PS: серебряная пуля не в языке, а в алгоритмах и структурах данных.
Соглашусь с вами в том, что серебреная пуля — в алгоритмах, но мне кажется, что именно это вам несколько раз и отвечали в этой ветке, нет?
Ок, я решил в виде статьи оформить, а то смотрю как-то народ побаивается подобных решений и пытается ко всему прикрутить базу. Там опишу подробно алгоритм, и как генерировать файл, и выложу примеры.
Учитывая, что сам поиск элементарный, то возможно народ, поддержит идею портировать алгоритм, на разные языки, для сравнения.
Учитывая, что сам поиск элементарный, то возможно народ, поддержит идею портировать алгоритм, на разные языки, для сравнения.
Хотелось бы отметить, что статьи сего авторства имеют свою ценность, достаточно интересно читать. Буду рад, если в будущем столкнусь с очередным творчеством камрада divan0
Спасибо за труд.
Спасибо за труд.
Мда… про деплой вообще странный аргумент.
Это можно сказать про любую программу которая собирается в один бинарь.
Мы пишем на С! Это упрощает деплой.
Это можно сказать про любую программу которая собирается в один бинарь.
Мы пишем на С! Это упрощает деплой.
Окей, давайте пройдёмся по пунткам и сравним Go, например, c Python. Т.е. можно его сравнить и с Clojure, и со Scala, и c Erlang, и даже с Rust при желании, но пусть будет Python.
Как я понял, суть аргумента в количестве библиотек. Так вот, если найдёте какую-нибудь библиотеку для Go, для которой нет аналога на Python — сообщите. В качестве противоположного примера — NumPy и весь соответсвующий стек (включая SciPy, SciKit Learn, Pandas, NLTK и многие другие). Или или из разряда интеграций — OpenCV. Или даже попроще и ближе к областям, на которых Go специализируется — Apache Spark. Что примечательно, Python клиенты для последних двух систем включены с самого начала в основную сборку, наравне с основным языком этих систем.
Я тут понемногу провожу курс по Python для непрограммистов. Заходит на отлично. Мне стоит рискнуть и предложить им перейти на Go?
Не то, чтобы Go был сложен для понимания, но и самым простым его не назовёшь. Особенно рядом с Python.
Вот тут есть несколько моментов. С одной стороны, переключаться с dev серверов на production действительно нужно (кстати, в Go ведь веб-фреймворки умеют делать hot swap во время разработки? иначе совсем обидно будет, и сравнивать с возможностями питоновских веб-серверов нет смысла). С другой, а много вы тратите времени на деплой? Для меня это обычно час-полтора на создание полноценного скрипта установки и настройки задачи в Jenkins/TeamCity. Это на 2-3 месячный проект. Я думаю, можно пережить.
Несмотря на многозначный подзаголовок, абзац про производительность. И вот тут, наверное, кто-то всхлопнет руками, вспоминая, что Python — медленный. Так вот, чушь это всё. Т.е. если брать чистый интепретатор (причём, конечно же, CPython, а не модный PyPy, у которого тоже уже всё хорошо), то скорость исполнения кода действительно ниже, но, как я уже когда-то писал в комментариях на Хабре, Python никогда не идёт один, а опирается на супер-быстрые библиотеки на других языках. И, надо сказать, это даёт отличную производительность! Если брать веб-программирование (а мы же именно в его контексте Go рассматриваем, да? вроде бы кроме него этот язык пока нигде особо не отличился), то вот несколько примеров высоконагруженных проектов на Python. Есть, конечно, определённые типы проектов, которые я бы не взялся писать на Python из-за вопросов производительности, но то же самое я могу сказать и про любой другой язык или платформу.
Там выше ещё упоминали преимущество документации Go. Не знаю, насколько вы знакомы с экосистемой Python, но найти незадокументированные проекты довольно сложно. А для крупных и популярных проектов, документация вообще шикарная (посмотрите, например, API для работы с SciKit Learn — там вам не то, что цели и аргументы функции опишут, там вам всю связанную с этим теорию разжуют). Вообще, в Python как-то принято писать библиотеки людьми для людей, да так, чтобы читатель точно понял.
А, ну и да, документация, конечно же, встроенная — в виде docstrings: вы просто добавляете обычную строку как первое выражение вашей функции или класса, и интерпретатор сохраняет эту строку как аттрибут __doc__ вашего объекта. Никакого специального синтаксиса, хотя вы можете следовать одному из нескольких принятых шаблонов для повышения читабельности.
А ещё в Python есть REPL. Такая офигенская штука, которая улучшает возможности интерактивной разработки на 400%. Причём в отличие от какого-нибудь Go playground, REPL позволяет сохранять состояние (к примеру, соедение с БД или предвычесленные значения), читать на ходу ту самую документацию, инспектировать объекты и перезагружать отдельные определения прямо в работающей системе. Круто это или не круто — пусть каждый сам решает(да что тут решать, конечно круто), но скорость разработки, которая так важна в стартапах, однозначно повышает.
1. Прост в написании
Как я понял, суть аргумента в количестве библиотек. Так вот, если найдёте какую-нибудь библиотеку для Go, для которой нет аналога на Python — сообщите. В качестве противоположного примера — NumPy и весь соответсвующий стек (включая SciPy, SciKit Learn, Pandas, NLTK и многие другие). Или или из разряда интеграций — OpenCV. Или даже попроще и ближе к областям, на которых Go специализируется — Apache Spark. Что примечательно, Python клиенты для последних двух систем включены с самого начала в основную сборку, наравне с основным языком этих систем.
2. Прост в понимании
Я тут понемногу провожу курс по Python для непрограммистов. Заходит на отлично. Мне стоит рискнуть и предложить им перейти на Go?
Не то, чтобы Go был сложен для понимания, но и самым простым его не назовёшь. Особенно рядом с Python.
3. Прост для деплоя
Вот тут есть несколько моментов. С одной стороны, переключаться с dev серверов на production действительно нужно (кстати, в Go ведь веб-фреймворки умеют делать hot swap во время разработки? иначе совсем обидно будет, и сравнивать с возможностями питоновских веб-серверов нет смысла). С другой, а много вы тратите времени на деплой? Для меня это обычно час-полтора на создание полноценного скрипта установки и настройки задачи в Jenkins/TeamCity. Это на 2-3 месячный проект. Я думаю, можно пережить.
4. Готов к продакшену
Несмотря на многозначный подзаголовок, абзац про производительность. И вот тут, наверное, кто-то всхлопнет руками, вспоминая, что Python — медленный. Так вот, чушь это всё. Т.е. если брать чистый интепретатор (причём, конечно же, CPython, а не модный PyPy, у которого тоже уже всё хорошо), то скорость исполнения кода действительно ниже, но, как я уже когда-то писал в комментариях на Хабре, Python никогда не идёт один, а опирается на супер-быстрые библиотеки на других языках. И, надо сказать, это даёт отличную производительность! Если брать веб-программирование (а мы же именно в его контексте Go рассматриваем, да? вроде бы кроме него этот язык пока нигде особо не отличился), то вот несколько примеров высоконагруженных проектов на Python. Есть, конечно, определённые типы проектов, которые я бы не взялся писать на Python из-за вопросов производительности, но то же самое я могу сказать и про любой другой язык или платформу.
Там выше ещё упоминали преимущество документации Go. Не знаю, насколько вы знакомы с экосистемой Python, но найти незадокументированные проекты довольно сложно. А для крупных и популярных проектов, документация вообще шикарная (посмотрите, например, API для работы с SciKit Learn — там вам не то, что цели и аргументы функции опишут, там вам всю связанную с этим теорию разжуют). Вообще, в Python как-то принято писать библиотеки людьми для людей, да так, чтобы читатель точно понял.
А, ну и да, документация, конечно же, встроенная — в виде docstrings: вы просто добавляете обычную строку как первое выражение вашей функции или класса, и интерпретатор сохраняет эту строку как аттрибут __doc__ вашего объекта. Никакого специального синтаксиса, хотя вы можете следовать одному из нескольких принятых шаблонов для повышения читабельности.
А ещё в Python есть REPL. Такая офигенская штука, которая улучшает возможности интерактивной разработки на 400%. Причём в отличие от какого-нибудь Go playground, REPL позволяет сохранять состояние (к примеру, соедение с БД или предвычесленные значения), читать на ходу ту самую документацию, инспектировать объекты и перезагружать отдельные определения прямо в работающей системе. Круто это или не круто — пусть каждый сам решает
Если не зацикливаться на Django то в плане производительности руки развязываются совершенно.
Ну и в целом Django не то на что лучше равняться ИМХО.
ЗЫ писал на Pylons сейчас новые проекты пишу на Tornado.
Ну и в целом Django не то на что лучше равняться ИМХО.
ЗЫ писал на Pylons сейчас новые проекты пишу на Tornado.
Ну это скорее пример популярного и всё-равно-производительного. Так-то производительность вообще разная бывает: кроме веба есть ещё большие данные, графика, научные вычисления, скрипты деплоя и многое другое.
Вот вам статья от disqus, которые на своем опыте сравнили go и python.
highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html
highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html
а мы же именно в его контексте Go рассматриваем, да? вроде бы кроме него этот язык пока нигде особо не отличился
Как насчет Docker и Kubernetes?
Ну и еще у 10gen надо спросить. У них вроде тоже не веб-программирование.
Возможно, мы по разному понимаем слово «веб-программирования». Если верить Википедии, то есть два типа языков веб-программирования: клинетские и серверные. Естественно, речь идёт о серверных языках, и вроде как все ваши примеры как раз и попадают в эту категорию. Ну, docker можно ещё назвать областью администрирования серверов/виртуализации, допустим, но это тоже не сильно далеко. А как насчёт более отдалённых областей, не связанных с созданием серверных приложений? Скажем, есть ли в/на Go что-нибудь для data warehousing? Или для обработки графики? Или для создания нативных десктопных приложений? Или для биоинформатики? (Интересно, что 2я ссылка по запросу «golang bioinformatics» ведёт на пост в блоге, в котором автор называет go скучным и сравнивает его с Python :)).
Я не говорю, что ориентация Go на веб — это плохо, просто пытаюсь обвести область, в которой он силён и, как следствие, в которой стоит проводить сравнение.
Я не говорю, что ориентация Go на веб — это плохо, просто пытаюсь обвести область, в которой он силён и, как следствие, в которой стоит проводить сравнение.
Как я понял, суть аргумента в количестве библиотек.
Неверно поняли.
кстати, в Go ведь веб-фреймворки умеют делать hot swap во время разработки
Умеют.
С другой, а много вы тратите времени на деплой?.. час-полтора… Я думаю, можно пережить.
Да всё можно пережить. Но рынок движется другими силами.
Там выше ещё упоминали преимущество документации Go. Не знаю, насколько вы знакомы с экосистемой Python, но найти незадокументированные проекты довольно сложно.
Я очень рад за Python, что в третьей версии в нем достаточно неплохо обстоят дела с документацией. И я на самом деле желаю Питону долгих лет жизни, тем более, что и сам на нём писал. Но, пожалуйста, не воспринимайте посты про языки программирования отличные от Питона как критику в адрес последнего.
Все аргументы в стиле «а вот посмотрите, в языке Х фича Y тоже хорошая» заведомо обречены, потому что преимущество Go не в том, что в нём все мыслимые аспекты и фичи программирования на порядки лучше и качественней, чем в других языках программирования. Нет, и ещё раз нет.
Преимущество Go в сочетании тех или иных решений, которые именно в этом сочетании позволяют решать широкий круг актуальных для нашего конкретного времени, наших конкретных реалий и экосистем, задач, реальными не-сверх-идеальными программистами, и делать это быстро и качественно с минимальными затратами.
Поэтому, серъезно, никто не оспаривает то, насколько Питон классный язык — и по многим пунктам Zen of Python, они даже близки с Go — но примите плюрализм технологий как что-то хорошее, а не плохое. Все технологии, набирающие популярность, набирают её по какой-то объективной причине, хотите вы этого или нет, понимаете вы это или нет. И лучше их понимать.
Кроме того, особенно если вы ведете курсы по Питону — познакомьтесь с Go ближе: даже если вы не будете на нём писать, ваши познания и авторитет от знания ещё одного весомого современного языка программирования только вырастут. Тем более, что с Go на это нужно гораздо меньше времени.
Как я понял, суть аргумента в количестве библиотек.
Неверно поняли.
Тогда поясните, в чём суть аргемента. Я в том абзаце увидел упоминание стандартной библиотеки и пакетного менеджера. Ну ещё систему типов, но в том предложении стоит фраза «как по мне», с которой я спорить не могу, ибо мнение — это мнение.
Да всё можно пережить. Но рынок движется другими силами.
Час на деплой приложения каждые 2-3 месяца слабо повлияют на положение на рынке :)
Я очень рад за Python, что в третьей версии в нем достаточно неплохо обстоят дела с документацией.
И во второй — не хуже ;)
Преимущество Go в сочетании тех или иных решений, которые именно в этом сочетании позволяют решать широкий круг актуальных для нашего конкретного времени, наших конкретных реалий и экосистем, задач, реальными не-сверх-идеальными программистами, и делать это быстро и качественно с минимальными затратами.
Так вот почему именно такое сочетание, а не какое-то другое? Есть или какие-то метрики, по которым проводится сравнение? Есть ли истории успеха, на практике доказывающие, что Go rocks, в то время как все остальные suck? Просто вы в статье доказываете (ок, не вы, а изначальный автор, но вы ведь его в этом поддерживаете?), что Go превосходит посредственность (т.е. все эти другие, «обычные» языки и платформы), но тут же в комментариях говорите про плюрализм технологий. Вы говорите, что многие скоро перейдут на Go, но от своих знакомых я слышал только, как они пробовали язык и после одного проекта слазили на что-нибудь другое. В этом случае, при каких условиях нужно действительно переходить на Go и почему?
Просто вы в статье доказываете (ок, не вы, а изначальный автор, но вы ведь его в этом поддерживаете?), что Go превосходит посредственность (т.е. все эти другие, «обычные» языки и платформы), но тут же в комментариях говорите про плюрализм технологий.
Справедливости ради, в статье мнение автора(Didip Kerabat), а в комментах мнение переводчика статьи. Это разные люди.
Холиварный топик, смысла ноль зато куча наездов на другие языки.
Go это Си на стероидах причём с кривым синтаксисом. За невозможность сделать переход на новую строку нужно расстрелять.
вместо чего то такого:
На самом деле претензий к нему прилично и я вроде уже где то о них писал, накидывать не хочу (высказал самое вкусовое).
Автор просто не понимает о чём пишет. Nginx и тем более HAProxy ставится в первую очередь не для того, что бы скрыть Gunicorn (ни то ни другое не использовал, а юзал scgi/wscgi и напрямую в nginx)
Это точно стартап!? т.е. если у вас нагрузки для которых нужно столько инстансов (интересно, как тогда с БД всё работает? :) ) то мне кажется проект может не только на деплой время потратить.
В большинстве других случаев хватает git pull (PS на heroku будет git push ;) ).
Последние 2 проекта полностью писал на Tornado так что веб сокеты и асинхронность/корутины из коробки. К слову явной асинхронности в Go нету, что при некоторых юзе кейсах не хорошо. (и да я знаю про горутины это другое)
Короче простите, просто накипело. В последнее время на Go начинают ещё больше рукоплескать чем в своё время на Ruby и я этого не понимаю.
Быстрее ли разрабатывать на Go чем на Python/Ruby/JS? Нет, динамическую типизацию не от хорошей жизни придумали.
Мне кажется если взять современный C++ с smart points и к примеру CppCMS то и производительность будет выше и разработка проще.
Go это Си на стероидах причём с кривым синтаксисом. За невозможность сделать переход на новую строку нужно расстрелять.
db_session.Query(`SELECT user_id, password FROM users WHERE login = ? LIMIT 1`,
r.Form["login"][0]).Consistency(gocql.One).Scan(&user_id, &password);
вместо чего то такого:
db_session.Query(
"SELECT user_id, password FROM users WHERE login = ? LIMIT 1",
r.Form["login"][0]
)
.Consistency(gocql.One)
.Scan(&user_id, &password);
На самом деле претензий к нему прилично и я вроде уже где то о них писал, накидывать не хочу (высказал самое вкусовое).
Устанавливают Nginx/HAProxy перед приложением, потому что Unicorn или Gunicorn не готов принимать прямой траффик из интернета.
Автор просто не понимает о чём пишет. Nginx и тем более HAProxy ставится в первую очередь не для того, что бы скрыть Gunicorn (ни то ни другое не использовал, а юзал scgi/wscgi и напрямую в nginx)
Поднимают от 5 до 10 medium-инстасов на EC2
Пишут сложный pipeline для деплоя в cap или fab.
Это точно стартап!? т.е. если у вас нагрузки для которых нужно столько инстансов (интересно, как тогда с БД всё работает? :) ) то мне кажется проект может не только на деплой время потратить.
В большинстве других случаев хватает git pull (PS на heroku будет git push ;) ).
Как насчет вебсокетов? О, это будет отдельное приложение на Node, с таким же сложным pipeline для деплоя.
Последние 2 проекта полностью писал на Tornado так что веб сокеты и асинхронность/корутины из коробки. К слову явной асинхронности в Go нету, что при некоторых юзе кейсах не хорошо. (и да я знаю про горутины это другое)
Короче простите, просто накипело. В последнее время на Go начинают ещё больше рукоплескать чем в своё время на Ruby и я этого не понимаю.
Быстрее ли разрабатывать на Go чем на Python/Ruby/JS? Нет, динамическую типизацию не от хорошей жизни придумали.
Мне кажется если взять современный C++ с smart points и к примеру CppCMS то и производительность будет выше и разработка проще.
Websocket сервер на go выдержит нагрузки намного больше. чем сервер на tornado.
Причем не надо будет искать либ для асинхронного чего-либо, чтобы смочь в его eventloop.
Т.е. можно будет использовать любую библиотеку, которая есть на go.
Кстати, вот бенчмарки, немного относящиеся к теме:
www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=json&l=e80
На моих задачах был за вечер написан демон на go для вебсокет соединений, слушающий redis канал.
На 20 тысяч соединений он кушал всего 300-400 мегабайт оперативной памяти. Это был один процесс, работающий на одном ядре (из 24), и cpu usage был в среднем 15-20. Rps там был где-то 100.
Чтобы его задеплоить, мне пришлось скопировать бинарник на целевую машину.
Как бы вел себя tornado в таких условиях?
У меня самого по работе стек — питон, но его для таких кейсов как-то странно применять.
Вот недавно пытался хоть как-то разогнать питон, чтобы выдавал на моей машине хотя бы 100к rps.
Не смог.
Go:
Falcon за gunicorn, 8 процессов.
На go уже реализована вся нужная мне логика, а питон просто отдает статическую строчку.
Причем не надо будет искать либ для асинхронного чего-либо, чтобы смочь в его eventloop.
Т.е. можно будет использовать любую библиотеку, которая есть на go.
Кстати, вот бенчмарки, немного относящиеся к теме:
www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=json&l=e80
На моих задачах был за вечер написан демон на go для вебсокет соединений, слушающий redis канал.
На 20 тысяч соединений он кушал всего 300-400 мегабайт оперативной памяти. Это был один процесс, работающий на одном ядре (из 24), и cpu usage был в среднем 15-20. Rps там был где-то 100.
Чтобы его задеплоить, мне пришлось скопировать бинарник на целевую машину.
Как бы вел себя tornado в таких условиях?
У меня самого по работе стек — питон, но его для таких кейсов как-то странно применять.
Вот недавно пытался хоть как-то разогнать питон, чтобы выдавал на моей машине хотя бы 100к rps.
Не смог.
Go:
(tera-admin)ernado@nexus:/src/wrk$ ./wrk http://127.0.0.1:12602/b/0 -c 200
Running 10s test @ http://127.0.0.1:12602/b/0
2 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.20ms 1.17ms 17.55ms 89.80%
Req/Sec 71.28k 12.70k 101.56k 75.63%
1342963 requests in 10.00s, 152.86MB read
Requests/sec: 134304.13
Transfer/sec: 15.29MB
Falcon за gunicorn, 8 процессов.
(tera-admin)ernado@nexus:/src/wrk$ ./wrk http://127.0.0.1:16888/b/1 -c 200
Running 10s test @ http://127.0.0.1:16888/b/1
2 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 7.04ms 6.64ms 218.84ms 97.12%
Req/Sec 8.46k 2.05k 14.36k 70.77%
162267 requests in 10.00s, 27.85MB read
Requests/sec: 16225.89
Transfer/sec: 2.79MB
На go уже реализована вся нужная мне логика, а питон просто отдает статическую строчку.
Кстати, либа, которую я написал, выложили в опенсорс и она и лежит здесь.
А тут www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=query&l=e80 tornado рвёт Go…
(или тут вина MySQL? ^_^ )
(или тут вина MySQL? ^_^ )
За невозможность сделать переход на новую строку нужно расстрелять.
Ещё можно просто почитать описание языка, ну, или хотя бы, спросить у сообщества.
Вот так пишите (точку в конце строки, а не в начале):
db_session.
Query(
"SELECT user_id, password FROM users WHERE login = ? LIMIT 1",
r.Form["login"][0]
).
Consistency(gocql.One).
Scan(&user_id, &password)
Никогда не понимал такого синтаксиса, когда точку отсавляют на предыдущей строке. Ведь если я читаю начало строки и вижу
Синтаксис, предложенный выше, намного выразительнее в этом плане.
Consistency(gocql.One)то как я могу понять что это вызов из предыдущего результата? Больше похоже на вызов какой-то отдельной функции с параметром.
Синтаксис, предложенный выше, намного выразительнее в этом плане.
Не буду спорить, хоть мне и кажется важность этого момента излишне надуманной — единственный случай, где может случиться вот это «читаю начало строки и вижу» — это grep по имени функции (без параметра -C). В остальных случаях — в коде, в диффах, всегда виден предыдущие строки.
Но в целом такое ограничение — это результат грамматики языка. «Под капотом» Go использует точки с запятой, но их писать не обязательно — перед компиляцией Go «расставляет» точки запятой, и правило там такое — если в конце строки стоит идентификатор или один из токенов из списка (break continue fallthrough return ++ — ) }), то точка с запятой вставляется. Вот тут подробнее: golang.org/doc/effective_go.html#semicolons
Но в целом такое ограничение — это результат грамматики языка. «Под капотом» Go использует точки с запятой, но их писать не обязательно — перед компиляцией Go «расставляет» точки запятой, и правило там такое — если в конце строки стоит идентификатор или один из токенов из списка (break continue fallthrough return ++ — ) }), то точка с запятой вставляется. Вот тут подробнее: golang.org/doc/effective_go.html#semicolons
Как-то же javascript живёт с теми же необязательными «;» и позволяет писать точку для вызова метода хоть в начале строки, хоть в её конце. Можно даже точку вообще в отдельной строке сделать, а объект и метод выше и ниже точки…
Это не будет работать так как «SELECT на новой строке…
В Go можно писать проекты в произвольных директориях, не внутри GOPATH? Очень сильно смутил этот момент после прочтения документации, Go навязывает собсвтенную структуру директорий.
На GOPATH завязан тулинг (go get/go build/etc) — вам дают много удобств, ускоряющих разработку и просят лишь одну вещь — выберите директорию, где будет лежать код.
Если речь идёт о коде под конкретный проект, то посмотрите на gb: habrahabr.ru/post/259967
Если речь идёт о коде под конкретный проект, то посмотрите на gb: habrahabr.ru/post/259967
Можно. Только лучше для этого использовать реализацию Go из комплекта Gcc: там нет чёткой привязки к структуре проекта.
Ваш личный код может валяться где угодно, а подтыкаемые библиотеки лежат в gopath. Я так пишу мелкие тулзы, один gopath на все. Ну и посмотрите в сторону gb.
Go чрезвычайно хорош в той области для которой его изначально разрабатывали, а именно относительно несложные сетевые сервисы. Для быстрого прототипирования и написания достаточно больших веб-проектов оптимальнее использовать языки вроде Python или Ruby, тут большое количество библиотек, и REPL, и большой рынок специалистов, и много других плюсов. Кроме того, он весьма слабо подходит для написания высокопроизводительных систем требовательных ко времени отклика, не только из-за его относительной высокоуровневости, но, в основном, из-за GC останавливающего мир. Сам наткнулся на этот момент при написании сервиса обрабатывающего большое количество сетевых соединений, стоит чуть забыться (а в го это сделать ну очень легко) и мы получаем громадное количество мусора, приводящего к остановке программы на несколько секунд, что просто-напросто непростительно для подобных сервисов.
Таким образом, выскажу очевидность: у каждого инструмента есть свои (частично пересекающиеся) области применения, и не стоит путать агрессивный маркетинг и моду с объективными качествами языка, пытаясь выдавать его за святой грааль без которого вас задушат конкуренты. Кроме того, стоит скептично относиться к внезапному росту областей, в которых, как утверждается, может применяться язык, т.к. натягивание ужа на ежа редко приводит к положительным результатам.
Лично для себя я выбрал следующую тройку языков: Python, Go, Rust. Данный набор закрывает чрезвычайно широкую область задач, остаётся только, по возможности, правильно выбирать нужный язык для поставленной задачи.
Таким образом, выскажу очевидность: у каждого инструмента есть свои (частично пересекающиеся) области применения, и не стоит путать агрессивный маркетинг и моду с объективными качествами языка, пытаясь выдавать его за святой грааль без которого вас задушат конкуренты. Кроме того, стоит скептично относиться к внезапному росту областей, в которых, как утверждается, может применяться язык, т.к. натягивание ужа на ежа редко приводит к положительным результатам.
Лично для себя я выбрал следующую тройку языков: Python, Go, Rust. Данный набор закрывает чрезвычайно широкую область задач, остаётся только, по возможности, правильно выбирать нужный язык для поставленной задачи.
Полностью согласен.
Вопрос: а Rust случаем не может заменить Go?
Вопрос: а Rust случаем не может заменить Go?
Очень маловероятно, ибо у него, во-первых, значительно выше порог входа, во-вторых, его большая низкоуровневость даёт о себе знать, например, нужно много внимания уделять управлению памятью, больше думать о структуре кода и алгоритмов, ну и сам по себе код получается менее лаконичным по сравнению с Go. В общем, достаточно характерные и ожидаемые свойства по настоящему системного языка программирования.
Кроме того, он весьма слабо подходит для написания высокопроизводительных систем требовательных ко времени отклика, не только из-за его относительной высокоуровневости, но, в основном, из-за GC останавливающего мир.На reddit'е недавно проскакивал benchmark относящийся как раз к этому случаю. A также как Go работает на «слегка на другом железе» упомянутом mva выше в комментариях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Go превосходит посредственность