Qihoo 360 и Go

[QtRoS]

Последние статьи так и подбивают ознакомиться с этим чудо-языком!

[nwalker]

Познакомьтесь лучше с Erlang. По мере знакомства нездоровые желания плавно сойдут на нет.

[cy-ernado]

Нездоровые желания изучать Erlang? ;)

[nwalker]

Ну, если вы сторонник hype-driven development…

Если говорить по теме — даже просто отказавшись от го в пользу эрланга, они бы решили проблему stop-the-world gc и сильно облегчили бы себе жизнь в плане работы с памятью.

[neolink]

ага и писали бы свои сервисы лет по пять
по поводу gc уже в августе должен выйти 1.5 в котором всё будет немного по другому

[dmbreaker]

Я бы сказал «сильно по другому». И лучше.

[AterCattus]

Даже в Go 1.3/1.4, где еще StW GC, на реальном использовании время работы GC меньше 1%. Трудно представить сферу применения (для рассматриваемых ЯП), когда эта величина критично высока.
А в 1.5 вообще обещают красоту.

[dmbreaker]

На Go добиться stop the world проще простого — создаете несколько миллионов указателей и приложение на Go начинает тупить каждые две минуты. Решение одно — избавляться в данных от указателей везде, где это возможно. Не факт, что 1.5 решит эту проблему, а не «размажет ее ровным слоем».

[AterCattus]

С нормальным кодом в Go сложно упереться в GC. Понятно, что если хочется, то легко, но это в любом ЯП можно наговнокодить именно с учетом конкретных слабых мест.
У меня в приложеньке постоянно создаваемые десятки миллионов короткоживующих указателей (и данных, на которые они указывают). Про GC даже не приходится задумываться.

[dmbreaker]

Я как раз о том, что упереться в GC проще простого. Достаточно в большом кол-ве долгоживущих данных иметь указатели.
Пока вы больших данных в памяти не держите — у вас нет проблем. Как только много данных, то GC стучит в дверь.
Причем вы не можете легко избавиться от указателей. Потому что они везде :) В слайсах, мапах, строках и интерфейсах.

[AterCattus]

Я просто как раз решал на Go задачу, крайне похожую на описанную в посте. И эти жуткие десятки гигабайт хипа и паузы на GC под секунду (последствия) мне кажутся дикими. Разве что они долго хранили (зачем?) отсылаемые данные.

[Xlab]

Указатели нужно применять с умом. В документации нет пояснения, когда разумнее использовать именно указатель, поэтому большинство использует их по-умолчанию для консистентности сигнатур методов.

Как только программист натыкается на GC, то начинаются оптимизиации, но это всё в соответствии с задачами, которые решаются.

[dmbreaker]

Да, но в документации нет упоминаний о том, что указатели зло. Поэтому все натыкаются, а потом уже начинаются оптимизации :)

[cy-ernado]

Просто не все пишут приложения на 60G кучи :)
У badoo точно такие же проблемы были, эта проблема обсуждена в 2013, вот и Qihoo теперь на английском закрепили.
Теперь будет легче. Так развивается сообщество.

[Xlab]

Читал несколько раз, когда изучал язык, собственно про impact on GC там ничего не сказано, это меня и смущало. Только синтаксические особенности, косметические и совсем очевидное про тяжеловесов.

[Pryada]

Я убеждён, что скоро ещё больше китайских интернет-компаний присоединятся к тренду и перепишут свои системы на Go

Уже сейчас на гитхабе много китайских репозиториев с Го.
А учитывая их специфику, что не проект — то хайлоад, может получиться очень интересно.

[Xlab]

Там в Китае с Go такой хайп, вот пост на HN — Why is Golang popular in China?

[mukizu]

Ну, даже два популярных (если не самых популярных) web-фреймворков — китайские.

[dblokhin]

Пару примеров бы конкретных оптимизаций, паттернов и тех рудиментов, которые решают какие-то проблемы с памятью.

[AterCattus]

Сейчас же система развёрнута на 400 серверах, поддерживает 200+ миллионов активных соединений и обеспечивает отправку более чем 10 миллиардов сообщений ежедневно.

Сначала возник вопрос, зачем так много машин для такого небольшого суточного объема.
Но тут стало все понятно: не очень как-то они хорошо сделали, с Go можно сделать сильно лучше.

размер кучи достигал 69G, паузы GC составляли по 3-6 секунд