Ну, основная идея описана в статье. Плавно на нее перейти можно, например, если уйти от flag.CommandLine (глобальный FlagSet) к FlagSet, объявленному внутри main.
Ясно, я понял так, что модули совсем не используются. Ну кривоватый хак – да, но первопричина тут – кривоватый дизайн, когда модуль безусловно экспортирует флаги, при чем в глобальный FlagSet.
Спасибо.
А как они появляются в бинарниках, если не используются? :) Или они объявляются где-то в третьем пакете? Можно написать кастомный PrintDefaults(), который будет принимать фильтр флага в виде префикса, например, или списка имен флагов.
Как можно называть дезинформацией то, что субъективно? То, что из статьи вынесены субъективные оценки – на мой взгляд плюс, хоть и имеет побочные эффекты в виде ошибочных интерпретаций.
Если бы ваше предположение о "главном критерии" было бы верным, то почему бы нам, например, не выбрать C или ассемблер?
Не пойму вашей позиции. Мы выбрали язык, на котором вот уже два года пишем сервисы. На момент выбора – Go в почте не было. На момент выбора – большинство специалистов писали на C, Perl и JavaScript. Как я уже сказал, независимо от ошибки, которую вы нашли, мы бы все равно выбрали Go. И не потому, что выбор предвзят, а по совокупности разных критериев. Вы хотите, чтобы мы передумали и начали писать на Rust?
Большую часть статьи занимают бенчмарки только по тому, что это наименее субъективная вещь. Сама статья, как это сказано в заключении, не имеет шансов быть объективной. Скажите, о какой дезинформации вы говорите?
Привет! Спасибо за найденную ошибку, это действительно fail. Безусловно, это нужно будет исправить и обновить результаты замеров.
Однако, раз уж ваш комментарий перерос в отдельную публикацию, хочется указать на некоторые моменты, которые вы решили не цитировать, но которые, тем не менее, определяют контекст сравнения.
Самое главное – статья 2015 года не называлась "какой язык быстрее". Она была о выборе языка программирования, и производительность написанных серверов была лишь одним из критериев. Это написано прямо в самом первом ее абзаце.
Если иметь это в виду, то разница, которую вы получили с исправлением, никак не влияет на наш выбор Go. Более того, в тестах так же есть обработчики без логики (GET /), в которых Rust был (и наверное есть) быстрее.
Дырок в функциональности Go нет. Дырка появилась бы во времени, которое пришлось бы потратить на призрачный профит переписывания функциональности nginx.
Ну и да, мы бросили усилия для того, чтобы в Go теперь тоже были высокопроизводительные вебсокеты =) На других языках они ведь тоже не сразу появились.
А вообще, что-то мне подсказывает, что в свете упоминания netty, уместно будет процитировать эту шутку:
A Google org once complained their rewrite from Java to Go had made things 10X slower until they noticed the graph was in micros not millis. https://t.co/2GtNfFvCPJ
Или вы решили через вопрос целесообразности nginx перед нашим WebSocket-сервером решили привести к тому, что нецелесообразно было пилить WebSocket-сервер? =)
Если вкратце – то да, может быть, но это будет крайне неудобно.
Подробнее тут.
Звучит полезно, но такого в flagutil нет. И, наверное, не будет. Проще сделать
cmd -help | fgrep yoogle.Отличная статья, спасибо! В контексте моднейших нынче youtube-шоу было бы интересно увидеть что-то подобное на эту тему :)
Ну, основная идея описана в статье. Плавно на нее перейти можно, например, если уйти от flag.CommandLine (глобальный FlagSet) к FlagSet, объявленному внутри main.
Ясно, я понял так, что модули совсем не используются. Ну кривоватый хак – да, но первопричина тут – кривоватый дизайн, когда модуль безусловно экспортирует флаги, при чем в глобальный FlagSet.
Спасибо.
А как они появляются в бинарниках, если не используются? :) Или они объявляются где-то в третьем пакете? Можно написать кастомный PrintDefaults(), который будет принимать фильтр флага в виде префикса, например, или списка имен флагов.
https://golang.org/pkg/os/#pkg-variables
Будет слайс нулевой длины.
Вы ошибаетесь.
Все верно. Пишешь код – пиши без багов!
Как можно называть дезинформацией то, что субъективно? То, что из статьи вынесены субъективные оценки – на мой взгляд плюс, хоть и имеет побочные эффекты в виде ошибочных интерпретаций.
Если бы ваше предположение о "главном критерии" было бы верным, то почему бы нам, например, не выбрать C или ассемблер?
Не пойму вашей позиции. Мы выбрали язык, на котором вот уже два года пишем сервисы. На момент выбора – Go в почте не было. На момент выбора – большинство специалистов писали на C, Perl и JavaScript. Как я уже сказал, независимо от ошибки, которую вы нашли, мы бы все равно выбрали Go. И не потому, что выбор предвзят, а по совокупности разных критериев. Вы хотите, чтобы мы передумали и начали писать на Rust?
Большую часть статьи занимают бенчмарки только по тому, что это наименее субъективная вещь. Сама статья, как это сказано в заключении, не имеет шансов быть объективной. Скажите, о какой дезинформации вы говорите?
Привет! Спасибо за найденную ошибку, это действительно fail. Безусловно, это нужно будет исправить и обновить результаты замеров.
Однако, раз уж ваш комментарий перерос в отдельную публикацию, хочется указать на некоторые моменты, которые вы решили не цитировать, но которые, тем не менее, определяют контекст сравнения.
Самое главное – статья 2015 года не называлась "какой язык быстрее". Она была о выборе языка программирования, и производительность написанных серверов была лишь одним из критериев. Это написано прямо в самом первом ее абзаце.
Если иметь это в виду, то разница, которую вы получили с исправлением, никак не влияет на наш выбор Go. Более того, в тестах так же есть обработчики без логики (GET /), в которых Rust был (и наверное есть) быстрее.
С GC дело обстоит неплохо. Это практически не влияет на мгновенную отдачу – GC случаются редко и на короткие промежутки времени (зависит от GOGC).
Кажется, это рекурсия!
Спору нет – erlang для этого, очевидно, хорош. Не зря WhatsApp рекорды по соединениям на одном сервере с ним ставил =)
Дырок в функциональности Go нет. Дырка появилась бы во времени, которое пришлось бы потратить на призрачный профит переписывания функциональности nginx.
Ну и да, мы бросили усилия для того, чтобы в Go теперь тоже были высокопроизводительные вебсокеты =) На других языках они ведь тоже не сразу появились.
А вообще, что-то мне подсказывает, что в свете упоминания netty, уместно будет процитировать эту шутку:
Или вы решили через вопрос целесообразности nginx перед нашим WebSocket-сервером решили привести к тому, что нецелесообразно было пилить WebSocket-сервер? =)
Эм, кажется мы друг друга не поняли. Мы же вроде не бросили кучу усилий и не писали велосипед на разработку web-сервера, а взяли nginx?