Comments 21
Последние статьи так и подбивают ознакомиться с этим чудо-языком!
+11
Познакомьтесь лучше с Erlang. По мере знакомства нездоровые желания плавно сойдут на нет.
-13
+3
Ну, если вы сторонник hype-driven development…
Если говорить по теме — даже просто отказавшись от го в пользу эрланга, они бы решили проблему stop-the-world gc и сильно облегчили бы себе жизнь в плане работы с памятью.
Если говорить по теме — даже просто отказавшись от го в пользу эрланга, они бы решили проблему stop-the-world gc и сильно облегчили бы себе жизнь в плане работы с памятью.
0
ага и писали бы свои сервисы лет по пять
по поводу gc уже в августе должен выйти 1.5 в котором всё будет немного по другому
по поводу gc уже в августе должен выйти 1.5 в котором всё будет немного по другому
+5
Даже в Go 1.3/1.4, где еще StW GC, на реальном использовании время работы GC меньше 1%. Трудно представить сферу применения (для рассматриваемых ЯП), когда эта величина критично высока.
А в 1.5 вообще обещают красоту.
А в 1.5 вообще обещают красоту.
0
На Go добиться stop the world проще простого — создаете несколько миллионов указателей и приложение на Go начинает тупить каждые две минуты. Решение одно — избавляться в данных от указателей везде, где это возможно. Не факт, что 1.5 решит эту проблему, а не «размажет ее ровным слоем».
0
С нормальным кодом в Go сложно упереться в GC. Понятно, что если хочется, то легко, но это в любом ЯП можно наговнокодить именно с учетом конкретных слабых мест.
У меня в приложеньке постоянно создаваемые десятки миллионов короткоживующих указателей (и данных, на которые они указывают). Про GC даже не приходится задумываться.
У меня в приложеньке постоянно создаваемые десятки миллионов короткоживующих указателей (и данных, на которые они указывают). Про GC даже не приходится задумываться.
0
Я как раз о том, что упереться в GC проще простого. Достаточно в большом кол-ве долгоживущих данных иметь указатели.
Пока вы больших данных в памяти не держите — у вас нет проблем. Как только много данных, то GC стучит в дверь.
Причем вы не можете легко избавиться от указателей. Потому что они везде :) В слайсах, мапах, строках и интерфейсах.
Пока вы больших данных в памяти не держите — у вас нет проблем. Как только много данных, то GC стучит в дверь.
Причем вы не можете легко избавиться от указателей. Потому что они везде :) В слайсах, мапах, строках и интерфейсах.
0
Указатели нужно применять с умом. В документации нет пояснения, когда разумнее использовать именно указатель, поэтому большинство использует их по-умолчанию для консистентности сигнатур методов.
Как только программист натыкается на GC, то начинаются оптимизиации, но это всё в соответствии с задачами, которые решаются.
Как только программист натыкается на GC, то начинаются оптимизиации, но это всё в соответствии с задачами, которые решаются.
0
Да, но в документации нет упоминаний о том, что указатели зло. Поэтому все натыкаются, а потом уже начинаются оптимизации :)
0
Я убеждён, что скоро ещё больше китайских интернет-компаний присоединятся к тренду и перепишут свои системы на Go
Уже сейчас на гитхабе много китайских репозиториев с Го.
А учитывая их специфику, что не проект — то хайлоад, может получиться очень интересно.
+2
Там в Китае с Go такой хайп, вот пост на HN — Why is Golang popular in China?
+4
Ну, даже два популярных (если не самых популярных) web-фреймворков — китайские.
0
Пару примеров бы конкретных оптимизаций, паттернов и тех рудиментов, которые решают какие-то проблемы с памятью.
0
Сейчас же система развёрнута на 400 серверах, поддерживает 200+ миллионов активных соединений и обеспечивает отправку более чем 10 миллиардов сообщений ежедневно.
Сначала возник вопрос, зачем так много машин для такого небольшого суточного объема.
Но тут стало все понятно: не очень как-то они хорошо сделали, с Go можно сделать сильно лучше.
размер кучи достигал 69G, паузы GC составляли по 3-6 секунд
+1
Sign up to leave a comment.
Qihoo 360 и Go