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 теперь на английском закрепили.
Теперь будет легче. Так развивается сообщество.
Читал несколько раз, когда изучал язык, собственно про impact on GC там ничего не сказано, это меня и смущало. Только синтаксические особенности, косметические и совсем очевидное про тяжеловесов.
Я убеждён, что скоро ещё больше китайских интернет-компаний присоединятся к тренду и перепишут свои системы на Go

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

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

Sign up to leave a comment.

Articles