Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 179
Да нет, код нормальный, все ок. Но в общем тестировать хелло ворлды бесполезно, это про производительность — есть мнение, что тормозить будет не питоно код на некоторых задачах.
Второе — библиотека под Го бедна как мышь в коммунистической церкви.
Но как я понимаю будут следующие части, и там вы учтете мои замечания и разгромите по всем фронтам.
Второе — библиотека под Го бедна как мышь в коммунистической церкви.
Но как я понимаю будут следующие части, и там вы учтете мои замечания и разгромите по всем фронтам.
Второе — библиотека под Го бедна как мышь в коммунистической церкви.Список библиотек (неофициальный, один из) на данный момент составляет список в 10 экранов: go-lang.cat-v.org/pure-go-libs
Посмотрите, вы удивитесь, там есть всё «для повседневной жизни», а чего не хватает можно написать самому. И получить от этого кайф!
Это вы на чистом Гоу библиотеки написали, а есть ещё биндинги: go-lang.cat-v.org/library-bindings
Там и мой, кстати, есть. Биндинг к GD.
Там и мой, кстати, есть. Биндинг к GD.
> есть мнение, что тормозить будет не питоно код на некоторых задачах.
Вспомни, как тормозит и как быстра джинджа. Но она-то быстра по сравнению с джангой, а так она всегда тянет заметный кусок времени обработки запроса, на более быстром языке оно было бы быстрее.
Еще пример — я долго пользовался sr, а потом написал goreplace поиграться и потому, что питон бегает по диску и матчит файлы регекспами в 5 (в среднем) раз медленнее. Это учти еще, что регекспы в го написаны на го, т.е. они заведомо медленнее питоновских — и не на си, и не так вылизаны.
С другой стороны, я слабо представляю себе здоровенный веб-сайт без SQLAlchemy. Такое дело, в общем.
> Второе — библиотека под Го бедна как мышь в коммунистической церкви.
Го, конечно, не питон, но у него даже стдлиб очень-очень неплохой.
Вспомни, как тормозит и как быстра джинджа. Но она-то быстра по сравнению с джангой, а так она всегда тянет заметный кусок времени обработки запроса, на более быстром языке оно было бы быстрее.
Еще пример — я долго пользовался sr, а потом написал goreplace поиграться и потому, что питон бегает по диску и матчит файлы регекспами в 5 (в среднем) раз медленнее. Это учти еще, что регекспы в го написаны на го, т.е. они заведомо медленнее питоновских — и не на си, и не так вылизаны.
С другой стороны, я слабо представляю себе здоровенный веб-сайт без SQLAlchemy. Такое дело, в общем.
> Второе — библиотека под Го бедна как мышь в коммунистической церкви.
Го, конечно, не питон, но у него даже стдлиб очень-очень неплохой.
Еще пример — я долго пользовался sr, а потом написал goreplace поиграться и потому, что питон бегает по диску и матчит файлы регекспами в 5 (в среднем) раз медленнее.О, знакомый аватар! Забавная штука выходит: когда-то зафолловил ваш твиттер, «чтобы не забыть», но это касалось питона и js, а теперь опять в круге моего интереса — Go. Погляжу как goreplace написан, на первый взгляд недурный код:)
;) Ну там такое, нельзя сказать, чтоб очень хорошо всë было, но работает. Я думаю, что можно и посимпатичнее некоторые места сделать, но я привык писать на питоне, теперь вон на кофескрипте, а го всë-таки чуть более низкоуровневый и некоторые моменты выглядят сильно иначе.
Впрочем, я заглянул внутрь — я там уже от глобальной переменной избавился кое-как, оказывается, аж на душе полегчало. Полезно забывать, что сделал что-то хорошее — еще раз испытываешь приятные ощущения. :))
Впрочем, я заглянул внутрь — я там уже от глобальной переменной избавился кое-как, оказывается, аж на душе полегчало. Полезно забывать, что сделал что-то хорошее — еще раз испытываешь приятные ощущения. :))
Может лучше сразу транслятор php в Go делать?
Расскажите, а за что минусы?
Лично мне Go нравится и я планирую использовать его в дальнейшем. При этом есть большое количество рабочего отлаженного кода на php, который взять и переписать в один заход сложно. Классно было бы оттранслировать его хотя бы в качестве эксперимента.
И лексический анализатор php тут недавно был.
Или у нас тут только идеология на кону, а практические вопросы миграции не интересны?
Лично мне Go нравится и я планирую использовать его в дальнейшем. При этом есть большое количество рабочего отлаженного кода на php, который взять и переписать в один заход сложно. Классно было бы оттранслировать его хотя бы в качестве эксперимента.
И лексический анализатор php тут недавно был.
Или у нас тут только идеология на кону, а практические вопросы миграции не интересны?
Минусы за что не знаю, но предположу, что ваш комментарий восприняли за своеобразный троллинг или стёб. Как фразу «а чего бы не изобрести до кучи и карманный стеллар-конвертор»?
Если по сути, то весьма затруднительно трансляция кода PHP в GO — у языков слишком разные архитектура и подходы к решению задач. В лучшем случае вы получите код того же качества, какой получается при переводе книги Google Translate. И правка займёт времени больше, чем переписывание того же кода с нуля и ручками.
Просто для примера. В PHP динамическая типизация, а в Go — строгая. И это лишь первый камень. Кроме того вы забываете о том, в каком мире мы живём. Никого на рынке особо не волнуют проблемы отстающих. Если у нас в руках есть инструмент, обеспечивающий преимущество, то зачем нам плодить себе конкурентов, упрощая им вход в сегмент?
Если по сути, то весьма затруднительно трансляция кода PHP в GO — у языков слишком разные архитектура и подходы к решению задач. В лучшем случае вы получите код того же качества, какой получается при переводе книги Google Translate. И правка займёт времени больше, чем переписывание того же кода с нуля и ручками.
Просто для примера. В PHP динамическая типизация, а в Go — строгая. И это лишь первый камень. Кроме того вы забываете о том, в каком мире мы живём. Никого на рынке особо не волнуют проблемы отстающих. Если у нас в руках есть инструмент, обеспечивающий преимущество, то зачем нам плодить себе конкурентов, упрощая им вход в сегмент?
А для сравнения страничку на PHP?
У вас слишком искуственные тесты. Много ума не надо, написать Hello World. Вы сделайте псевдокнтроллер, который читает данные из фейковой модели, проверяет права доступа и отдает в фейковую вьюху. В таких, приближенных к реальности условиях, будет гораздо более объективный тест.
Для Питона, естественно, надо подключить всю махину Джанго.
А так, ваши тесты больше походят на тесты неадекватов из shootout.alioth, которые меряют для PHP скорость построения двоичного дерева и подобную дребедень. Покажите мне хоть один сайт, который строит красно-черные деревья при выводе страницы.
У вас слишком искуственные тесты. Много ума не надо, написать Hello World. Вы сделайте псевдокнтроллер, который читает данные из фейковой модели, проверяет права доступа и отдает в фейковую вьюху. В таких, приближенных к реальности условиях, будет гораздо более объективный тест.
Для Питона, естественно, надо подключить всю махину Джанго.
А так, ваши тесты больше походят на тесты неадекватов из shootout.alioth, которые меряют для PHP скорость построения двоичного дерева и подобную дребедень. Покажите мне хоть один сайт, который строит красно-черные деревья при выводе страницы.
В реальных условиях у нас уже год крутится в продакшене несколько решений на Go. И там результаты ещё более впечатляют. Как я уже говорил в комментариях к предыдущим топикам по Go, переписывание кода с Python на Go позволило комфортно уместить систему на одном сервере, вместо пяти. Приведёнными же здесь тестами я показал лишь самый базис, а уже по мере развития статей дойдём и до реального полноценного веб-приложения. С базой данных, темплетами, проверкой прав пользователей и всеми привычными плюшками.
Зачем же сразу django сюда? Все правильно сравнивают — без фреймворков.
А то смотите как бы при сравнивании скорости на фреймворках вместо django на стороне питона на ринг не вышел какой-нить cyclone(гибрид twisted & tornado) да еще и запущенный через pypy… Django не лучший показатель скорости в питоне.
А то смотите как бы при сравнивании скорости на фреймворках вместо django на стороне питона на ринг не вышел какой-нить cyclone(гибрид twisted & tornado) да еще и запущенный через pypy… Django не лучший показатель скорости в питоне.
Django показатель скорости разработки сайтов на ней)))
Честно говоря у меня руки чесались написать код вебсервера и роутера на пайтоне исключительно используя built-in. Но к своему стыду я совершенно забыл как это делается. Поэтому и взял paste с минимальной надстройкой — вряд ли кто-либо из питонистов усомнится в зрелости этого проекта или заподозрит Ian Bicking в криворукости :)
docs.python.org/library/internet.html Вам в помощь.
Хотя заюзан webapp2. Надо попробовать tornado например.
Тест с тысячей запросов, это не серьезно. Для получения корректных данных их должно быть хотя-бы 50 тысяч. И вот, что любопытно:
дает 12337.72 запр/сек, а вот такое:
грузит на 50% все мои 4 ядра и дает всего 3821.04 запр/сек.
Видимо с параллельностью там все еще не так хорошо, как хотелось бы.
taskset 1 go run habr.go
taskset 2 ab -c 100 -n 100000 http://127.0.0.1:3000/
дает 12337.72 запр/сек, а вот такое:
go run habr.go
taskset 2 ab -c 100 -n 100000 http://127.0.0.1:3000/
грузит на 50% все мои 4 ядра и дает всего 3821.04 запр/сек.
Видимо с параллельностью там все еще не так хорошо, как хотелось бы.
Увы, на моём ноутбуке тесты с большими нагрузками не выдерживались Python-версией вообще, поэтому я и предложил поэкспериментировать самостоятельно.
Что касается параллельности, то следует учитывать три нюанса:
1. Скрипт не был усложнён и тюнингован (см. GOMAXPROCS, например).
2. «Распараллеливание» задач оставляется на усмотрение разработчика, путём запуска уже внутри программы goroutines.
3. В некоторой непредсказуемости результатов виновен ещё и сборщик мусора.
Что касается параллельности, то следует учитывать три нюанса:
1. Скрипт не был усложнён и тюнингован (см. GOMAXPROCS, например).
2. «Распараллеливание» задач оставляется на усмотрение разработчика, путём запуска уже внутри программы goroutines.
3. В некоторой непредсказуемости результатов виновен ещё и сборщик мусора.
Загрузку cpu не замерял, но для 10000 и 100000 запросов получил для go, соответственно,
10439.43 и 8253.92, для nginx в случае 100000 — 17700. Если поднять worker_processes, то для nginx будет порядка 19400rps.
Как ни странно, при GOMAXPROCS(12) rps упал (5415.19, 3204.39). Как улучшить — пока не знаю, видимо, действительно проблема в сборщике мусора.
Машина: 2x6-core xeon, 24G.
10439.43 и 8253.92, для nginx в случае 100000 — 17700. Если поднять worker_processes, то для nginx будет порядка 19400rps.
Как ни странно, при GOMAXPROCS(12) rps упал (5415.19, 3204.39). Как улучшить — пока не знаю, видимо, действительно проблема в сборщике мусора.
Машина: 2x6-core xeon, 24G.
Тоже ломаю голову и мучаю Golang-nuts. Хотя в реальной ситуации с такими нагрузками встречаться почти не приходится, всё же хочется большей предсказуемости.
И спасибо за участие.
И спасибо за участие.
http {
tcp_nodelay on;
accept_mutex off;
access_log off;
server {
location ~ ^/(.+)$ {
return 200 "Hello, $1!";
}
}
}И сменить ab на что-нибудь другое. Медленный ab с вышеприведенным конфигом легко станет узким местом.
Вряд ли проблема в сборщике мусора. Скорее в планировщике.
Кстати, я недавно делал статью о производительности горутин. И в качестве вывода могу сказать, что выделение очень быстрой функции (например если она работает быстрее чем 10-кратное вычисление sqrt(13)) при GOMAXPROCS > 1 действительно снижает производительность.
Кстати, я недавно делал статью о производительности горутин. И в качестве вывода могу сказать, что выделение очень быстрой функции (например если она работает быстрее чем 10-кратное вычисление sqrt(13)) при GOMAXPROCS > 1 действительно снижает производительность.
*выделение очень быстрой функции в горутину
Имхо, в goroutines и по идее не стоит запихивать слишком лёгкие ответвления. Проще их выполнить в основном потоке. В GR я обычно запихиваю логгинг или запись в базу того, что не требует вывода подтверждения.
Я вот сейчас еще раз проверил исходники. net/http сервер на каждый http запрос создает новую горутину. Поэтому и получается не очень-то быстро для такого простого случая.
P.S. Кстати, при тестировании нужно еще и смотреть, чтобы http headers совпадали.
P.S. Кстати, при тестировании нужно еще и смотреть, чтобы http headers совпадали.
Ничего себе, «недавно» — в прошлом году :)
Переносите статью в хаб Go, статья интересная.
Переносите статью в хаб Go, статья интересная.
Скорость hello world'a — это единственный аргумент?
ЗЫ: Какие ключи VM были во время запуска java тестов? Как вообще проходило тестирование?
ЗЫ: Какие ключи VM были во время запуска java тестов? Как вообще проходило тестирование?
Как вы думаете, помню ли я конфигурацию тестовых стендов двухлетней давности? Предложите оптимальную с вашей точки зрения конфигурацию и код, а я охотно проверю.
Скорость hello world'a — это единственный аргумент?А для кого, как ни для вас, автор написал следующие строки:
Подозреваю, что кого-то не устроит методика тестирования, настройки по умолчанию или отсутствие реализации на других языках. С удовольствием выслушаю ваши предложения и повторю тесты.
Предлагайте свои, менее синтетические тесты, модернизируйте написанное, участвуйте в процессе. В поиске рождается истина, как бы банально это не звучало!
Введение — огo-go!
Стиль написания, заgoловки, все эти habri et orbi — снимаю шляпу.
Немало авторов на Хабре владеют предметом, но владеть еще и слогом на том же уровне, что и у вас — далеко немногие. Респект!
И ждём продолжения цикла!
Стиль написания, заgoловки, все эти habri et orbi — снимаю шляпу.
Немало авторов на Хабре владеют предметом, но владеть еще и слогом на том же уровне, что и у вас — далеко немногие. Респект!
И ждём продолжения цикла!
Как то быстро кончилось. Ждем продолжение, пока комментировать что то я считаю рано.
Спасибо за статью.
Честно, но даже с поправкой на не совсем привычный (лично мне) стиль оформления кода на Python он кажется чище и проще, чем код на Go. Наверное, это подсознательная реакция на символы:
Честно, но даже с поправкой на не совсем привычный (лично мне) стиль оформления кода на Python он кажется чище и проще, чем код на Go. Наверное, это подсознательная реакция на символы:
{ } * from gevent import http
def callback(request):
request.add_output_header('Content-Type', 'text/html')
print 'Serving on 8088...'
http.HTTPServer(('0.0.0.0', 8088), callback).serve_forever()
Requests per second: 16830.99 [#/sec] (mean)
Ваш пример на Go — Requests per second: 10671.47 [#/sec] (mean), машинка четырехядерная.
Всем понятно что в данном случае чистый C победил, но уж если тестировать хелловорлды, то честно, задействуя все возможности обширных библиотек ;)
Я пожалуй потрачу немного времени, и разделю с вами любовь к питону в комментариях к вашим постам.
Могу ли я попросить тот же код, но с роутером, разбирающим регулярку в адресе? Чтобы соответствовать Go-коду. И опять же, в случае с gevent мы приходим к тому же, к чему бы пришли и с Tornado — к сравнению несколько разных механизмов. А значит пришлось бы вводить и другой код на Go, например с использованием Twister.go
Регулярка ничего не меняет, но вы не поняли меня.
Хелловорлды несерьезно, и я вам наглядно показал, что питон в хелловорлдах ну просто ой какой шустрый, что конечно же неправда, так как не может питон быть шустрым, все же знают.
Поэтому и предлагаю продолжить на более серьезном материале — вы подаете статью, а я пытаюсь побить Go на python :) Будет весело.
from gevent import http
import re
root = re.compile('^/$')
def callback(request):
if root.match(request.uri):
request.add_output_header('Content-Type', 'text/html')
request.send_reply(200, "OK", '<b>hello world</b>')
else:
request.add_output_header('Content-Type', 'text/html')
request.send_reply(404, "Not Found", "<h1>Not Found</h1>")
print 'Serving on 8088...'
http.HTTPServer(('0.0.0.0', 8088), callback).serve_forever()
Хелловорлды несерьезно, и я вам наглядно показал, что питон в хелловорлдах ну просто ой какой шустрый, что конечно же неправда, так как не может питон быть шустрым, все же знают.
Поэтому и предлагаю продолжить на более серьезном материале — вы подаете статью, а я пытаюсь побить Go на python :) Будет весело.
Принимаю! Но возможно и вы кое чего не поняли. Речь идёт не столько о чистой скорости, но и о ресурсах.
Не не не Девид Блейн! Если мы о ресурсах — то это С/++, все остальное — о производительности разработчика.
Ну, манипулируя средой выполнения можно регулировать потребляемые ресурсы и без C/++ даже для одного и того же кода. Например, важно количество оперативки — отрубаем нафиг всякое кэширование в ней. Минимизируем иопсы — наоборот кэшируем всё, что можно. А если задача стоит «приложение должно занимать не более 20 Мбайт на воркер», то можно сменить язык и не столь радикально, как в случае с C/++, пускай даже на них оно будет занимать 2 Мбайта.
При всём уважении, вынужден отправить пригласить вас на Википедию — ознакомится с понятием эффективность по Парето.
Все это круто, но без фреймворка аля Django или Rails, обеспечивающего сопоставимое удобство разработки, я пока кодить на Go сайты не буду.
«Habri et orbi» — это очень круто. Я бы вообще предложил в качестве motto на заглавную вынести.
Спасибо за статью, занимательно вышло.
Толко вот от компилируемого языка я ожидал намного больше 5000 rps.
Прошу не убивать сильно за нахальность, но такого же результата легко добиться используя динамический язык с более приятным синтаксисом да ещё внутри фреймворка.
А без фреймворка данный язык поднимается до 7000 rps.
Я НЕ пытаюсь сказать что одно лучше другого!
Просто для меня довольно странно увидеть такой результат от Go. Он у меня на полке академических приоритетов первым стоит.
Автор, может вы что-то не то сделали?
Толко вот от компилируемого языка я ожидал намного больше 5000 rps.
Прошу не убивать сильно за нахальность, но такого же результата легко добиться используя динамический язык с более приятным синтаксисом да ещё внутри фреймворка.
А без фреймворка данный язык поднимается до 7000 rps.
Я НЕ пытаюсь сказать что одно лучше другого!
Просто для меня довольно странно увидеть такой результат от Go. Он у меня на полке академических приоритетов первым стоит.
Автор, может вы что-то не то сделали?
Ведь rps зависит от машины, на которой запускается тест. У автора все-таки Celeron. На моей машине (AMD Phenom X4 940) этот пример выдает 12000 rps, что почти соответствует указанной разнице в 2-3 раза в сравнении с программой на C или C++ (моя программка на C++ выдает 28000 rps, как и nginx). В общем не так много, как хотелось бы, но и не так уж мало.
Смотрите на цифру иначе — мы получили половину скорости Nginx без плясок с бубном и на слабом железе. Nginx в данном случае слабо зависит от железа, поскольку его быстродействие давно уже упирается не в CPU/RAM, а скорее в NET/HTTP. А вот у Go-реализации есть ещё большой задел для разгона. Есть он и у динамических/интерпретируемых языков, но меньше (по ряду причин). Ну и ещё раз не поленюсь повторить — оптимальность достигается не только быстродействием, но и «системными требованиями», которые у Go значительно ниже.
Убедительно, но пока сам не проверю не успокоюсь :)
Наверное и настал тот день когда я начну пляски в стиле Go
Наверное и настал тот день когда я начну пляски в стиле Go
Как верно уже отметили важна разница относительная, а не абсолютная.
Наглядно отрыв компилируемого Go от Python показан на страничке:
Benchmarking Go and Python Web server
Наглядно отрыв компилируемого Go от Python показан на страничке:
Benchmarking Go and Python Web server
Проверил, успокоился :)
15k на моём железе.
солидно.
начинаем осваивать.
15k на моём железе.
солидно.
начинаем осваивать.
нет, не тоже самое
Porsche — это Запорожец + реактивный двигатель?
MySql и Sphinx, Apache и nginx
Кота и камень, апельсин и мандарин?
По-поводу
GO разве не тоже самое, что PHP + Zend?
Совсем не понял.
И, да. Питону тыщу лет, руби не нравится синтаксисом, Java нравится, но писать на ней вебаппы нед сил, так что Go для меня оптимальный выбор. Молодой, шустрый с красивым синтаксисом. Тыкаю палочкой его уже пару недель, думаю о том где бы выгоднее применить.
Если бы я сравнил ещё и с Java, то кто-нибудь попросил сравнить ещё и с Ruby, Haskell, JavaScript, etc.
За счёт чего Go быстрее — объяснить несложно. Во-первых, это язык компилируемый. Во-вторых, со строгой типизацией. В-третьих, он архитектурно изначально задумывался и создавался как язык современный, то есть «из коробки» заточенный под многоядерность и многопоточность. «Старым» языкам приходится тянуть на себе бремя обратной совместимости — как со своими прошлыми версиями, так и со старым железом. Потенциал Go же раскрывается в первую очередь именно в многопоточности и параллельности. Т.е. в реальном приложении мы лёгким движением руки выдёргиваем любую функцию из основного потока последовательности обработки и отправляем его в goroutines, не дожидаясь результатов.
За счёт чего Go быстрее — объяснить несложно. Во-первых, это язык компилируемый. Во-вторых, со строгой типизацией. В-третьих, он архитектурно изначально задумывался и создавался как язык современный, то есть «из коробки» заточенный под многоядерность и многопоточность. «Старым» языкам приходится тянуть на себе бремя обратной совместимости — как со своими прошлыми версиями, так и со старым железом. Потенциал Go же раскрывается в первую очередь именно в многопоточности и параллельности. Т.е. в реальном приложении мы лёгким движением руки выдёргиваем любую функцию из основного потока последовательности обработки и отправляем его в goroutines, не дожидаясь результатов.
Лет пять назад меня пытались убедить в том, что Python или Ruby не найдут широкого применения в web :) И аргументы были почти такими же: дескать, программирование на PHP требует от разработчика меньше усилий.
Но давайте смотреть в глаза суровой правде. Времена вольницы в Сети подходят к концу, как закончилась когда-то эпоха Дикого Запада. Всё большую роль играют деньги (и немалые), корпорации и ужесточающаяся конкуренция. Последняя является двигателем прогресса, просто вынуждая конкурентов адаптировать новые технологии, позволяющие снизить себестоимость. Сейчас этот тренд отчётливо заметен, но с перекосом в удешевление (упрощение) разработки. Но у такого метода есть свои недостатки, позволяющие атаковать рынок с другой стороны — со стороны снижения постоянных издержек на инфраструктуру.
Но давайте смотреть в глаза суровой правде. Времена вольницы в Сети подходят к концу, как закончилась когда-то эпоха Дикого Запада. Всё большую роль играют деньги (и немалые), корпорации и ужесточающаяся конкуренция. Последняя является двигателем прогресса, просто вынуждая конкурентов адаптировать новые технологии, позволяющие снизить себестоимость. Сейчас этот тренд отчётливо заметен, но с перекосом в удешевление (упрощение) разработки. Но у такого метода есть свои недостатки, позволяющие атаковать рынок с другой стороны — со стороны снижения постоянных издержек на инфраструктуру.
Я извиняюсь, но насколько я могу судить, сайтов на РНР пока всё же больше, чем на Ruby или Python.
Популярность языка РНР всё также выше (она падает, но всё никак не упадёт) его конкурентов (на хабре где-то даже графики были — можете поискать, если не верите).
Простите за оффтопик, теперь по теме: язык Go заинтересовал, ваши статьи также подогревают любопытство. С большим интересом буду ждать ваших дальнейших статей, и спасибо за эту.
Популярность языка РНР всё также выше (она падает, но всё никак не упадёт) его конкурентов (на хабре где-то даже графики были — можете поискать, если не верите).
Простите за оффтопик, теперь по теме: язык Go заинтересовал, ваши статьи также подогревают любопытство. С большим интересом буду ждать ваших дальнейших статей, и спасибо за эту.
Рискну и сам нарваться на гнилые помидоры, но меня цинично радует изобилие PHP-разработчиков и общий консерватизм. Это позволяет мне (и мне подобным) демпировать цены за счёт более низких постоянных издержек.
Меня вот общий консерватизм не радует. Выбора средств обычно не предоставляют. LAMP и всё, хорошо если можно выбрать фреймворк/CMS.
Когда вы пишете что-либо серьёзное, о виртуальном хостинге речь даже не заходит. А если говорить о заказчиках, то их предубеждения легко можно переломить цифрами себестоимости.
Виртуальные хостинги не только для PHP есть. А LAMP это не только виртуальные хостинги. Но хотят LAMP.
Прекрасно вас понимаю, сам работал на таких условиях много лет назад. Но тогда я один из первых (ну может в сотне первых) российских разработчиков сделал рискованную ставку на Python, что позволило (не без тяжкого труда) вырваться из этого «порочного круга» и выйти на международный рынок, где как раз начиналась эпидемия Python/Django и Ruby/Rails.
Сейчас ситуация мне видится аналогичной — спрос на HighLoad достаточно высок, а предложения весьма ограничены. Следовательно, выходя на рынок с высокопроизводительными технологиями и конкурентноспособными ценами у поколенияNext Go есть все шансы обогнать на голову мейнстримщиков.
Сейчас ситуация мне видится аналогичной — спрос на HighLoad достаточно высок, а предложения весьма ограничены. Следовательно, выходя на рынок с высокопроизводительными технологиями и конкурентноспособными ценами у поколения
Я ближе к VolCh в отношении консерватизма в вопросе выбора ЯП.
Вопрос достаточно масштабный и уходит корнями как в систему образования, так и в смежные области.
Насчёт изобилия РНР-разработчиков: самое грустное тут то, что 90% из них не знают язык даже процентов на 25.
По языку Go: мне очень понравился акцент на новизне языка. Ведь действительно, в основном тормоза из-за обратной совместимости (которую, к слову, всё чаще не боятся ломать). Остаётся надеяться, что проектировщики языка достаточно продумали его, чтобы, скажем, через 3-4 года не прийти к возу, что «и ныне там».
Вопрос достаточно масштабный и уходит корнями как в систему образования, так и в смежные области.
Насчёт изобилия РНР-разработчиков: самое грустное тут то, что 90% из них не знают язык даже процентов на 25.
По языку Go: мне очень понравился акцент на новизне языка. Ведь действительно, в основном тормоза из-за обратной совместимости (которую, к слову, всё чаще не боятся ломать). Остаётся надеяться, что проектировщики языка достаточно продумали его, чтобы, скажем, через 3-4 года не прийти к возу, что «и ныне там».
Странные удивления: порой задумываюсь, а не сделать ли какой-нибудь проект на чём-нибудь отличном от php (но не опускаясь до сей — к сожалению основательно подзабыл язык) на каком-нибудь rubi/python/etc, смотрю что есть на рынке хостинга…
К сожалению российский хостинг ассортиментом за небольшие деньги не отличается…
Хотя это я смотрел года два назад, может что-то изменилось?
К сожалению российский хостинг ассортиментом за небольшие деньги не отличается…
Хотя это я смотрел года два назад, может что-то изменилось?
Есть недорогие предложения под python/ruby (вернее в подробности не вникал, но позиционируются как django- или rails-ready). Не говоря о большом количестве недорогих VDS. Но с VDS свои тараканы, если никсы не знаете на уровне администратора. Я вот не знаю, просто пользователь — поднять сервер по хауту худо-бедно могу, но как, например, его правильно обновлять толком и не знаю, если приходится обходиться без стандартных средств ОС для этого.
За 100-200 рублей в месяц вполне можно позволить себе VDS, пригодный для развёртывания сервера и Go проектов. Вот буквально через пару часов мы уже непосредственно и приступим к этому на практике.
тыкните, пожалуйста в vds 100-200 рублей в месяц (в гугле забанили:)…
В общем я пока что vds дешевле 300-500 рублей в месяц не находил…
В общем я пока что vds дешевле 300-500 рублей в месяц не находил…
Смотрите на цену первых двух тарифов. Никто не говорит, что это надежный хостер и что это пригодно для серьёзных проектов. Но для «попробовать», например, развернуть сервер с Go-проектами — вполне!
fastvps.ru/vds/ вот самый дешевый меньше 200 р/мес.
Ну и меньше 300 рублей www.hetzner.de/en/hosting/produkte_vserver/vq7
Плюс облачные VDS (например от селектел) обходиться могут ещё дешевле, если нагрузка не постоянна.
Ну и меньше 300 рублей www.hetzner.de/en/hosting/produkte_vserver/vq7
Плюс облачные VDS (например от селектел) обходиться могут ещё дешевле, если нагрузка не постоянна.
Высокая нагрузка = приток денег. Если формула не работает, что-то сделано не так :)
Для старта может хватить 100-200 рублей, отправленных на баланс clodo.ru или того же селектела. И с первой же секунды онлайн, начинается бомбардировка потенциальных рекламодателей или инвесторов. Если деньги не находятся, сносим всё к чертям и начинаем новый проект.
Для старта может хватить 100-200 рублей, отправленных на баланс clodo.ru или того же селектела. И с первой же секунды онлайн, начинается бомбардировка потенциальных рекламодателей или инвесторов. Если деньги не находятся, сносим всё к чертям и начинаем новый проект.
А в чём он требует больше усилий? Пока количество строк сопоставимо, плюс python подключает сторонний фреймворк и сам код выглядит немного более «грязным» «шумным».
Кое-кто из ветеранов веб-разработки (а именно bolk) уже сравнивал Go, и с Java в том числе.
Спасибо за статью! Жду продолжения и возможности поучаствовать в совместной разработке действующего веб-проекта. Из анонса продолжения меня больше всего интересует часть «Компилируем и запихиваем несколько Go-серверов под Nginx.» :)
Можете участвовать уже сейчас :) А то я сижу тут и ломаю голову над тем, какой бы быстренько сообразить проектик-стартапец, чтобы на него пришли поглазеть хотя бы миллион пользователей.
Я с недавних пор хочу себе сервис, являющийся универсальным оповещателем. Например, существует много способов получения контента:
1) Зайти на сайт и посмотреть, нет ли чего новенького.
2) RSS.
3) Twitter.
4) Email.
…
Следить за всем этим многообразием тяжело, и даже если удастся собрать себе подборку того, что действительно полезно — то нужно все равно проверять N источников каждый день (заходить на почту, в RSS-ридер, в Twitter и на некоторые сайты).
Хотелось бы сервис, который позволял бы настраивать «маршруты» оповещения о новом контенте, например:
1) Если на сайте NNN.com появилась новая статья — запостить в твиттер новую запись.
2) Если в заданном RSS появилась новая запись — прислать мне email.
3) Создать RSS ленту из записей заданного твиттера.
И т.п. Таким образом человек может проверять одно место на выбор (создать себе twitter-аккаунт, за которым следить, завести отдельную почту или проверять одну RSS-ленту), в котором будет собрана вся интересующая его информация (по крайней мере ссылки на нее).
Не знаю правда, на сколько интересен данный сервис может быть для всех остальных. Но нагрузку он должен генерировать сам по себе очень неплохую (постоянный pulling). Ну и масштабируемую архитектуру тут несложно придумать и реализовать.
1) Зайти на сайт и посмотреть, нет ли чего новенького.
2) RSS.
3) Twitter.
4) Email.
…
Следить за всем этим многообразием тяжело, и даже если удастся собрать себе подборку того, что действительно полезно — то нужно все равно проверять N источников каждый день (заходить на почту, в RSS-ридер, в Twitter и на некоторые сайты).
Хотелось бы сервис, который позволял бы настраивать «маршруты» оповещения о новом контенте, например:
1) Если на сайте NNN.com появилась новая статья — запостить в твиттер новую запись.
2) Если в заданном RSS появилась новая запись — прислать мне email.
3) Создать RSS ленту из записей заданного твиттера.
И т.п. Таким образом человек может проверять одно место на выбор (создать себе twitter-аккаунт, за которым следить, завести отдельную почту или проверять одну RSS-ленту), в котором будет собрана вся интересующая его информация (по крайней мере ссылки на нее).
Не знаю правда, на сколько интересен данный сервис может быть для всех остальных. Но нагрузку он должен генерировать сам по себе очень неплохую (постоянный pulling). Ну и масштабируемую архитектуру тут несложно придумать и реализовать.
Думаю, ifttt.com вам в помощь
Смотрю на ваш код и думаю — круто, так мало кода.
Я вот пишу на Java и кода естественно в разы больше.
Всегда хотелось найти время и изучить какой-то динамический язык, для домашних целей конечно.
Думаю для java-разработчика единственным динамическим языком будет groovy, хотя может я ошибаюсь.
И да, интересная статья, жду продолжения.
Я вот пишу на Java и кода естественно в разы больше.
Всегда хотелось найти время и изучить какой-то динамический язык, для домашних целей конечно.
Думаю для java-разработчика единственным динамическим языком будет groovy, хотя может я ошибаюсь.
И да, интересная статья, жду продолжения.
2. Код на языке Go
5. Для сравнения добавим ещё и nginx,…
4. Тестовый стенд…
5. Замеры…
6. Результаты забегов
Хитрую нумерацию пунктов списка вы тоже унаследовали из своего юридического прошлого?)
Я правильно понял, что приложения на python и go немного разнятся по функциональности? На python обрабатывает только GET запросы, а на go все, даже типа DELETE или HEAD?
Хотелось бы чтобы были ещё освещены методики/средства сборки/развёртывания (если они нужны), чтобы минимизировать время простоя продакшен серверов при обновлениях приложения. Желательно о сборке в неидентичных окружениях (без фанатизма, собирать под Windows приложение, которое должно будет работать под Linux не нужно, а вот собрать под Gentoo/Arch, которое будет работать под Debian/CentOS — частая, по-моему задача). Есть ли какие-то менеджеры зависимостей, репозитории и т. п. В общем в идеале должна отдаваться команда типа
А так огромное спасибо за статью, с нетерпением жду продолжения.
Хотелось бы чтобы были ещё освещены методики/средства сборки/развёртывания (если они нужны), чтобы минимизировать время простоя продакшен серверов при обновлениях приложения. Желательно о сборке в неидентичных окружениях (без фанатизма, собирать под Windows приложение, которое должно будет работать под Linux не нужно, а вот собрать под Gentoo/Arch, которое будет работать под Debian/CentOS — частая, по-моему задача). Есть ли какие-то менеджеры зависимостей, репозитории и т. п. В общем в идеале должна отдаваться команда типа
go deploy и на «чистом» сервере должно развёртываться приложение.А так огромное спасибо за статью, с нетерпением жду продолжения.
Пожелания зафиксировал. Увы, я старый дебианщик и не знаю слов любви к rpm и portage :)
Ну, про Gentoo/Arch я упомянул в заботе о более продвинутых хаброюзерах чем я. У меня Ubuntu на десктопе и Debian на сервере. Про deb пакеты со всеми зависимостями я даже не заикаюсь (это был бы вообще идеал), но очень бы хотелось избежать компиляции на сервере и какой-то инструмент получения зависимостей (названия-версии либ и т. п.), чтобы на сервер можно было бы ставить только рантайм, скомпилированный на другой машине (на крайний случай можно виртуалку с целевой ОС поднять), без компилятора.
P.S. А насчёт функциональности я прав?
Есть у меня мнение, что «тру» гентушники и без моих потугов прекрасно переведут информацию на свой язык :) Чем хорош Debian, так это тем, что можно говорить на одном языке с Ubuntu-пользователями. То есть понятно и профессионалам, и начинающим.
Что касается компиляции и переносимости, то Go создаёт кошерный ELF, который можно смело копировать на любую Linux систему и он будет работать точно так же. Но и Go-компиляция на сервере не так страшна, как может показаться. Быстрая и нетребовательная компиляция Go — это одна из его фишек. Настолько быстрая, что есть даже проект Go-pages, позволяющий работать в PHP/JSP-style. То есть код остаётся открытым сорцом, а веб-сервер компилирует его на лету, как это делали бы интерпретаторы.
Что касается компиляции и переносимости, то Go создаёт кошерный ELF, который можно смело копировать на любую Linux систему и он будет работать точно так же. Но и Go-компиляция на сервере не так страшна, как может показаться. Быстрая и нетребовательная компиляция Go — это одна из его фишек. Настолько быстрая, что есть даже проект Go-pages, позволяющий работать в PHP/JSP-style. То есть код остаётся открытым сорцом, а веб-сервер компилирует его на лету, как это делали бы интерпретаторы.
Есть языки которые никуда не денутся: FORTRAN, LISP, COBOL, C/C++ и наверное уже Java, просто ввиду количества написанного и требующего поддержки кода. Tcl/Tk тоже давно и для ряда задач прочно занял свое место и Erlang и Objective C. Ну и Haskell как академический язык. Мне вот что интересно, создатели вот этих Go и C# знакомы с этими языками? Чего, людям грамотным, может нехватать в LISP'e? Сомневаюсь что кроме борьбы за рынок и запудривания юных мозгов есть хоть что-то в этих новоделах.
Пардон, описался, конечно же «не хватать».
Зачем нужны отвёртки, если есть замечательные молотки?
Разные инструменты нужны для разных задач, а Вездесущий, Естественный, Лучший, Образцовый, Супер-Инструмент, Предписанный Единым Диктатором — это утопия.
Разные инструменты нужны для разных задач, а Вездесущий, Естественный, Лучший, Образцовый, Супер-Инструмент, Предписанный Единым Диктатором — это утопия.
Честно говоря, не ожидал другого ответа. Одна риторика с привкусом маркетинга и ничего по существу. Разумеется для разного типа задач или вследствие сложившейся практики, нужны разные языки — для расчетов фортран, для системного программирования С/С++, в банках COBOL и т.д. Любой проффесиональный разработчик со стажем обычно владеет палитрой языков и освоение нового языка — не большая проблема. Проблема возникает, когда новичкам, подсовывают проприетарные разработки, до того как они (новички) получают кругозор на базе накопленного сообществом опыта. Возникает не только вопрос зачем но и кому это нужно. Например кому было нужно изучение MFC? Или J#? И где теперь асы этой чудо технологии? А по поводу создателей языка — зачем они это сделали вопрос 10й, вы же не зовете нас ставить Plan 9 в качестве ОС? И должны ли мы сказать спасибо за UTF-8? Вопрос, когда у языка будет стандарт и кто будет за него отвечать.
В чем проприетарщина? BSD лицензия же
BDB и MySQL тоже open source, что же с ними случилось? И с Java я боюсь мы наплачемся, после того как Oracle купила SUN. Очевидно же, что Go нужен Google'у, который я кстати нежно люблю, но при этом понимаю, что коммерческая организация не можеть быть матерью Терезой.
А должна ей быть? Разве плохо умело совмещать общественные интересы и собственные?
Мне до сих пор нравится. Но если Google начнет превращаться в компьютерного «компрачикоса» как было с Microsoft'ом по ряду технологий, то я буду вопить об этом во все горло!!!
Ммм, и что же случилось с mysql?
И чем плоха поддержка корпорацией? Языки программирования и прочая ИТ-инфраструктура существуют лишь потому, что нужны бизнесу, а не потому, что имеют какую-то самостоятельную ценность.
И чем плоха поддержка корпорацией? Языки программирования и прочая ИТ-инфраструктура существуют лишь потому, что нужны бизнесу, а не потому, что имеют какую-то самостоятельную ценность.
Рад, что не обманул ваших чаяний! Вот только огорчает тот факт, что вы не потрудились изучить первоисточники. Он не есть проприетарный, а OpenSource, под лицензией BSD. То что его разработали при поддержке и деятельном участии Google, не делает из него Большого Кузена.
Вы говорите об опыте, а я часто называю это костностью и консерватизмом, препятствующим развитию технологий. А во многих случаях и наследованием накопленных ошибок и предрассудков.
Скажите, любезнейший оппонент, готовы ли вы своё бурчание отстаивать на деле? Давайте возьмём задачу, для которой Go подходит лучше других (по моему скромному мнению) и устроим состязание — вы воплотите её в жизнь своими привычными инструментами, а я — своими.
Люблю азарт погони.
Вы говорите об опыте, а я часто называю это костностью и консерватизмом, препятствующим развитию технологий. А во многих случаях и наследованием накопленных ошибок и предрассудков.
Скажите, любезнейший оппонент, готовы ли вы своё бурчание отстаивать на деле? Давайте возьмём задачу, для которой Go подходит лучше других (по моему скромному мнению) и устроим состязание — вы воплотите её в жизнь своими привычными инструментами, а я — своими.
Люблю азарт погони.
Про косность и консерватизм мы поговорим, когда на этом вашем Go полетят спутники в космос, ну или ему доверят хоть сколько нибудь серьезные индустриальные вопросы. Сомневаюсь, что семантика Go лучше чем у всех остальных языков, ну а если уж там такой чудо компилятор, в чем я тоже мягко говоря сомневаюсь — то имеет смысл написать транслятор с известных языков в Go и дело с концом. Спасите же уже бедных PHPшников. По поводу состязания, прошу прощения, но для меня в нем нет никакого интереса, да и времени мягко говоря жалко. Тем не менее, с удовольствием почитаю, следующие статьи из цикла. Не отвлекайтесь на мое бурчание :)
А никто и не говорит об обратном!
Просто есть понятин «нишевости», Go может занять свою нишу занять (я имеюю ввиду нишу инструмента для разработки hi-load веб-приложений), у него есть все предпосылки. Осталось только понравиться разработчикам.
Нет, по сути, никакого противопоставления…
Просто есть понятин «нишевости», Go может занять свою нишу занять (я имеюю ввиду нишу инструмента для разработки hi-load веб-приложений), у него есть все предпосылки. Осталось только понравиться разработчикам.
Нет, по сути, никакого противопоставления…
сорри, за опечатки.
С достаточно высокоуровневыми фреймворками он может, думаю, покуситься и не только на хайлоад, но и на типичные ниши php/python/ruby/java/C# в вебе. Причём, по идее, для выполнения одних и тех же задач на сравнимом уровне абстракции ему потребуется меньше ресурсов (cpu и mem) как для нативно компилируемого языка со статической типизацией, которым никто из «конкурентов» не является.
И раз уж зашла речь о создателях языка, то адресуйте своё негодование непосредственно им:
Робу Пайку и Кену Томпсону.
Уверен, что они сгорят от стыда и будут посыпать пеплом друг друга головы :)
Робу Пайку и Кену Томпсону.
Уверен, что они сгорят от стыда и будут посыпать пеплом друг друга головы :)
:) Или написать в блог «Я негодую», литературно оформить своё открытое письмо и собрать подписи. Уверен придут к комментарии многие, чтобы разделить свою злость.
PS: удивляет на Хабре превуалирующий негативизм в отношении всего нового, причём это не здоровый хладнокровный скептицизм, какой был бы вполне уместен, а какая-то кровавая пелена, затмевающая всё и вся.
PS: удивляет на Хабре превуалирующий негативизм в отношении всего нового, причём это не здоровый хладнокровный скептицизм, какой был бы вполне уместен, а какая-то кровавая пелена, затмевающая всё и вся.
ну как же, столько сил положено в изучение существующих языков, а тут все прахом пойдёт!
А вы, сударь, не удивляйтесь, а радуйтесь, как это делаю я. Чем больше консерваторов, тем меньше конкуренция :) Поэтому я и не бросаюсь на амбразуры убеждать людей в том, что Go является аватаром Абсолюта, цифровой реинкарнацией Будды или Истинным Воплощением Летающего Макаронного Монстра :)
Sapienti sat, как говорили мудрые латиняне.
Sapienti sat, как говорили мудрые латиняне.
По-моему, сейчас большинство новых языков (и сопутствующих инструментов) решают одну задачу — увеличение производительности разработчиков без уменьшения, как минимум, надежности. C# так вообще, по-моему, явная попытка улучшить Java или, как минимум учесть её недостатки.
А общая цель — уменьшение времени реакции разработчиков на новые/изменившиеся требования бизнеса и, желательно, снижение стоимости этого времени, то есть более низкая квалификация по сути.
А общая цель — уменьшение времени реакции разработчиков на новые/изменившиеся требования бизнеса и, желательно, снижение стоимости этого времени, то есть более низкая квалификация по сути.
Полностью согласен с последним абзацем.
Вообще Абельсон и Сусман выразились по этому поводу.
По поводу Java'ы — она на моей памяти, тоже создавалась как cross платформенный С++, с учетом недостатков С++.
Вообще Абельсон и Сусман выразились по этому поводу.
По поводу Java'ы — она на моей памяти, тоже создавалась как cross платформенный С++, с учетом недостатков С++.
Java создавалась по принципу «write once. run anywhere.»
Опыт брался из пачки языков, в том числе C и C++, синтаксис унаследовали от C++ для облегчения изучения (теми, кто знает C++)
Опыт брался из пачки языков, в том числе C и C++, синтаксис унаследовали от C++ для облегчения изучения (теми, кто знает C++)
Может Java хороша для разработчиков (бог, миловал), но с точки зрения пользователя ужас-ужас.
чем плоха java с точки зрения пользователя?
Прожорливостью. Я так и не смог заставить себя работать в Eclipse, предпочитая лёгкий Geany.
Ужасно всё тормозное, несовместимости версий и тд.
Лично я отказался бы от её установки вообще, но клиент-банк на ней, к сожалению.
Лично я отказался бы от её установки вообще, но клиент-банк на ней, к сожалению.
Простите, что тормозное, перечислите пожалуйста.
Про какую несовместимость версий вы говорите?
Про какую несовместимость версий вы говорите?
Выше уже написали, нет смысла повторяться.
Плюс любой другой неразрабовский софт, тот же банковский к примеру, обладает той же ресурсо-прожорливостью.
Плюс любой другой неразрабовский софт, тот же банковский к примеру, обладает той же ресурсо-прожорливостью.
имхо C# писалось MS как свой велосипед и им в итоге и стало.
Ни адекватной кроссплатформенности ни полной скорости C++ в нём не получилось…
Ни адекватной кроссплатформенности ни полной скорости C++ в нём не получилось…
Если гоняться за скоростью, то почему бы тогда не писать проекты на модулях для nginx? как например openresty.org
Вот недавно ребята мерили производительность nginx + модуль lua-resty-redis
Там обычный HelloWorld выдает 120k rps. А если еще и с запросом в redis то около 47-50k rps.
Вот недавно ребята мерили производительность nginx + модуль lua-resty-redis
Там обычный HelloWorld выдает 120k rps. А если еще и с запросом в redis то около 47-50k rps.
Гонки идут не за скорость, а за оптимальность. Т.е. за соотношение быстродействия ко времени, затрачиваемому на разработку.
Я уже делал пару приложений чисто на nginx + модули и не сказал бы что было долго.
Например чат — где все было nginx + nginx-push-module + nginx-echo-module и еще определение местоположения и вывод на карту гугла пользователей nginx-geoip-module итд итп и ниодного файлика — все в конфиге — скорость разработки высокая.
Еще nginx-redis2 модуль забыл.
Было бы интересно прочитать пост на эту тему :)
Я начинал писать, но так и не дописал. В черновиках есть. Вместо nginx-http-push теперь использую nginx-http-push-stream(с поддержкой WebSocket)
Надо дописать с учетом использования другого модуля.
Надо дописать с учетом использования другого модуля.
Вспомнил что уже был пост на эту тему. Кто-то для игры-приложения вконтакте использовал модуль nginx-http-push и приводили примеры. Найти сейчас не смог. А свое через недельку где-нить опубликую.
Нашел случайно habrahabr.ru/post/139339/
Вот, кстати, что может ждать тех, кто решится использовать Go для создания сайта — groups.google.com/d/msg/golang-nuts/qxlxu5RZAl0/kDYtyHr4XXQJ
Просто нужно использовать 64-битную операционную систему.
Ничего себе fix :(
Ну а какие вообще плюсы у 32-битной платформы для вебсервера?
Меньшее потребление памяти. В контексте VPS, облаке или огромном количестве клиентов, память играет важную роль.
Меня опередили в ответе. Память, и еще раз память.
Так ведь память как раз несложно докупить. В самом самом худшем случае потребление вырастет в два раза :)
Нет, я, конечно, понимаю, что баг есть баг, и его надо бы пофиксить. Но ничего смертельного тут нету. Вряд ли это остановит кого-то от использования Go.
Нет, я, конечно, понимаю, что баг есть баг, и его надо бы пофиксить. Но ничего смертельного тут нету. Вряд ли это остановит кого-то от использования Go.
Кстати, если почитать внимательно ветку по проблеме, то оказывается, что утечка памяти имеет место быть и на 64-битной ОС
Это issue 909, и пока он не закрыт.
Это issue 909, и пока он не закрыт.
Неприятную штуку какую вы откопали…
Ничего страшного. Смотрите под другим углом — у какой реализации не бывает проблем с long-live или memory-leaks? Ну и если почитать issue вниимательно, то проблема происходит при определённых условиях, мягко говоря редких для web-dev. Причём это тот самый случай, когда программист использует Go калькой другого языка, не учитывая его специфики.
Меньшее потребление памяти. В контексте VPS, облаке или огромном количестве клиентов, память играет важную роль.
Извиняюсь, промахнулся. Это ответ на habrahabr.ru/post/141426/#comment_4733239
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Go for IT. Часть первая