Pull to refresh

Comments 21

Последние статьи так и подбивают ознакомиться с этим чудо-языком!
Познакомьтесь лучше с Erlang. По мере знакомства нездоровые желания плавно сойдут на нет.
Нездоровые желания изучать Erlang? ;)
Ну, если вы сторонник hype-driven development…

Если говорить по теме — даже просто отказавшись от го в пользу эрланга, они бы решили проблему stop-the-world gc и сильно облегчили бы себе жизнь в плане работы с памятью.
ага и писали бы свои сервисы лет по пять
по поводу gc уже в августе должен выйти 1.5 в котором всё будет немного по другому
Я бы сказал «сильно по другому». И лучше.
Даже в Go 1.3/1.4, где еще StW GC, на реальном использовании время работы GC меньше 1%. Трудно представить сферу применения (для рассматриваемых ЯП), когда эта величина критично высока.
А в 1.5 вообще обещают красоту.
На Go добиться stop the world проще простого — создаете несколько миллионов указателей и приложение на Go начинает тупить каждые две минуты. Решение одно — избавляться в данных от указателей везде, где это возможно. Не факт, что 1.5 решит эту проблему, а не «размажет ее ровным слоем».
С нормальным кодом в Go сложно упереться в GC. Понятно, что если хочется, то легко, но это в любом ЯП можно наговнокодить именно с учетом конкретных слабых мест.
У меня в приложеньке постоянно создаваемые десятки миллионов короткоживующих указателей (и данных, на которые они указывают). Про GC даже не приходится задумываться.
Я как раз о том, что упереться в GC проще простого. Достаточно в большом кол-ве долгоживущих данных иметь указатели.
Пока вы больших данных в памяти не держите — у вас нет проблем. Как только много данных, то GC стучит в дверь.
Причем вы не можете легко избавиться от указателей. Потому что они везде :) В слайсах, мапах, строках и интерфейсах.
Я просто как раз решал на Go задачу, крайне похожую на описанную в посте. И эти жуткие десятки гигабайт хипа и паузы на GC под секунду (последствия) мне кажутся дикими. Разве что они долго хранили (зачем?) отсылаемые данные.
Указатели нужно применять с умом. В документации нет пояснения, когда разумнее использовать именно указатель, поэтому большинство использует их по-умолчанию для консистентности сигнатур методов.

Как только программист натыкается на GC, то начинаются оптимизиации, но это всё в соответствии с задачами, которые решаются.
Да, но в документации нет упоминаний о том, что указатели зло. Поэтому все натыкаются, а потом уже начинаются оптимизации :)
Просто не все пишут приложения на 60G кучи :)
У badoo точно такие же проблемы были, эта проблема обсуждена в 2013, вот и Qihoo теперь на английском закрепили.
Теперь будет легче. Так развивается сообщество.
UFO landed and left these words here
Читал несколько раз, когда изучал язык, собственно про impact on GC там ничего не сказано, это меня и смущало. Только синтаксические особенности, косметические и совсем очевидное про тяжеловесов.
Я убеждён, что скоро ещё больше китайских интернет-компаний присоединятся к тренду и перепишут свои системы на Go

Уже сейчас на гитхабе много китайских репозиториев с Го.
А учитывая их специфику, что не проект — то хайлоад, может получиться очень интересно.
Ну, даже два популярных (если не самых популярных) web-фреймворков — китайские.
Пару примеров бы конкретных оптимизаций, паттернов и тех рудиментов, которые решают какие-то проблемы с памятью.
Сейчас же система развёрнута на 400 серверах, поддерживает 200+ миллионов активных соединений и обеспечивает отправку более чем 10 миллиардов сообщений ежедневно.

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

Sign up to leave a comment.

Articles