Всем привет) Прошу прощения, я точно не первый кто задаёт это вопрос, но кто нибудь знает хороший видеокурс по Go?) Спасибо)

Не, у похапе совсем другая песня - там уровень вхождения низкий. А у плюсов, просто масса. Слишком много написано, и все это надо как-то поддерживать. Но когда эта масса будет вытеснена другими языками - исчезать он будет очень быстро

у PHP тоже не малая часть сайтов, если что а так да я согласен

у PHP тоже не малая часть сайтов, если что а так да я согласен

~83% веба, ага

~83% веба, ага

И как правило, самые унылые 85%

И как правило, самые унылые 85%

95% сайтов унылые

95% сайтов унылые

с тех же ~17% аналогичная ситуация

95% сайтов унылые

Тем более. Особенно учитывая переход вэба от сайтов к социалкам, площадкам и т.д.

с тех же ~17% аналогичная ситуация

Я имел в виду 95% от общего числа сайтов

Тумблр тому показатель

Могу поспорить, что у большинства айтишников закладки в браузере сходятся на 40% минимум

С плюсами в некоторых областях может только раст посоперничать

Го можно выбросить из сравнения из-за gc

Всем привет) Прошу прощения, я точно не первый кто задаёт это вопрос, но кто нибудь знает хороший видеокурс по Go?) Спасибо)

https://www.coursera.org/learn/golang-webservices-1 https://www.coursera.org/learn/golang-webservices-2

https://www.coursera.org/learn/golang-webservices-1 https://www.coursera.org/learn/golang-webservices-2

Спасибо)

Го можно выбросить из сравнения из-за gc

https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/

https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/

Даже самый лучший GC не сравнится с кодом ручного менеджмента, ибо это чисто физически невозможно, но на то чтобы безупречно менеджить память вручную - уйдут годы практики и обучения

не сравнится в чем?

не сравнится в чем?

manual memory management

я понял

я не понял, по какому параметру мы сравниваем его с gc

Очевидно по производительности и латенси.

ну-ну.

нет, теоретически оно так

Сильно теоретически

вот-вот

практически - ни разу мне лично gc не мешал

имеется ввиду, что Go чисто физически не может достичь уровня производительности C/C++ (написанного с умом). Но это как обычно вечный вопрос tradeoff'ов, либо человеко-часы, либо циклы процессора и второе становится всё дешевле.

думаю с приходом ИИ ситуация рано или поздно перевернётся и код будет эффективнее писать компилятор на базе ИИ.

думаю с приходом ИИ ситуация рано или поздно перевернётся и код будет эффективнее писать компилятор на базе ИИ.

Останется только написать тз

послушайте, ну ведь это ерунда. мы не упираемся нигде в gc. мы упираемся в сеть, упираемся в диск, упираемся в скорость работы памяти. а в gc- нет, не упираемся. бул у меня в начале 90-х такой знакомый программист. он дизассемблировал comand.com и прочел код работы с диском. и выяснил, что работа с диском там чрезвычайно неэффективна. и переписал все "как следует". и его код был даже сильно лучше, я его видел. но! он не смог даже процента разницы намерять. потому, что диск меееедленный...

Останется только написать тз

я не говорю что программы будет писать ИИ, я говорю что исполняемый код будет писать ИИ

послушайте, ну ведь это ерунда. мы не упираемся нигде в gc. мы упираемся в сеть, упираемся в диск, упираемся в скорость работы памяти. а в gc- нет, не упираемся. бул у меня в начале 90-х такой знакомый программист. он дизассемблировал comand.com и прочел код работы с диском. и выяснил, что работа с диском там чрезвычайно неэффективна. и переписал все "как следует". и его код был даже сильно лучше, я его видел. но! он не смог даже процента разницы намерять. потому, что диск меееедленный...

ну вы - мб

я упирался

знаю людей которые упирались

так расскажи же, где!

так расскажи же, где!

да банально - берем наш гошный графитный стек, задаем пачку тяжелых запросов и видимо что гц начинает жрать 20 ядер из 24

притом в какой-то момент перестает успевать подбирать мусор и приходит оом

четко видно на профилировщике

реально доступных (непомарканных) объектов - 1ГБ

то что помаркано на удаление - 127ГБ

но неподчищено

так это, может, пул? может, не gc плохой, а руки, того, кривоваты?

так это, может, пул? может, не gc плохой, а руки, того, кривоваты?

какой пул? Что вы несете?

Просто GC плохо себя ведет когда ему прилетает много новых короткоживущих объектов

Я упирался в GC, когда писал на го риал тайм под девайс на мипс. Пришлось выключить GC и пускать его ручками, когда бывали простои

а это для меня увы нормальный юзкейс со стороны внешних пользователей

решение у него есть - фактически писать свой аллокатор памяти и не триггерить гц никогда

а все объекты выделять черзе кастомный алокатор

тогда все зашибись, работает отлично

решение у него есть - фактически писать свой аллокатор памяти и не триггерить гц никогда

кто сказал C++

кто сказал C++

вот-вот (

@onokonem считаешь что руки кривые, весь код на гитхабе, PRs are welcome

предлагаю показать как надо что ли, тогда

какой пул? Что вы несете?

если реально используется 1GB, а вы навыделяли и освободили 128GB - это значит, что с аллокацией что-то не так. и первое, что приходит на ум - https://golang.org/pkg/sync/#Pool. если он не решает задачу - можно написать свой переиспользователь объектов.

предлагаю показать как надо что ли, тогда

я теперь, мать его, go-евангелист. я теперь скринкасты и блогпосты пишу, а не код. опухну скоро.

но, если будет денек свободный, погляжу обязательно

только надо будет мне рассказать, как проблема воспроизводится

только надо будет мне рассказать, как проблема воспроизводится

да элементарно - ставится стек, делается пара сотен запросов которые вытягивают по 20-30ГБ на фронтэнд )

с малым интервалом времени

результат гарантирован

если реально используется 1GB, а вы навыделяли и освободили 128GB - это значит, что с аллокацией что-то не так. и первое, что приходит на ум - https://golang.org/pkg/sync/#Pool. если он не решает задачу - можно написать свой переиспользователь объектов.

да, GC не справляется с sweep фазой

и не успевает подбирать мусор

sync.Pool не совсем поможет к сожалению

а пробовали?

а пробовали?

думал над этим, из очевидных минусов - пострадает скорость анмаршалинга просядет, плюс писать свою собственную реализацию gRPC и протобуфа - то еще удовольствие

проще заворкэраундить в моем случаи проблему тем что таки запилить стриминг данных

ERROR: S client not available

он сильно generic, поэтому слегка useless для разных corner cases, и свой-под-задачу обычно эффективнее.

@onokonem там спорные моменты есть

проблему не решит координально

потому что от кучи мусора прилетающего по сети не спасет

оттянет неизбежное - да

сильно? на полгода

по сети прилетает массив байт (и егонадо принять в буфер, выделенный раз и навсегда) и анмаршалить можно в объект, тоже выделенный раз и навсегда

по сети прилетает массив байт (и егонадо принять в буфер, выделенный раз и навсегда) и анмаршалить можно в объект, тоже выделенный раз и навсегда

не понимаю как это поможет, потому что объектов много )

и параллельных запросов тоже много

основная проблема то как раз в том, что в случаи с Го нет возможности сказать "вот это все - мусор, убери"

и честно говоря выглядит проще просто выделить кусок памяти и заниматься ручным менеджментом памяти на нем

и ждать пока таки нам завезут request oriented gc

не понимаю как это поможет, потому что объектов много )

чой-та их много? их на 1GB

чой-та их много? их на 1GB

ну вот той то )

то что в снэпшоте видно 1 ГБ используемый не значит что не было иначе чуток раньше

увы, но клиенты внешние - это люди, они делают странную хрень

и это считается нормой

основная проблема то как раз в том, что в случаи с Го нет возможности сказать "вот это все - мусор, убери"

кстати с чем конкретно это связанно?

с тем, как gc устроен.

кстати с чем конкретно это связанно?

с тем что авторы Го оптимизировали GC под лейтенси и минимизацию stop the world

поэтому очень много чего делается в бэкграунде

и когда у тебя очень много (сотни тысяч или миллионы) новых объектов в секунду, а сами объекты короткоживущие, все становится очень грустно

с тем, как gc устроен.

я потому-что всегда задавался вопросом "в чём собственно проблема гибридного механизма управления памятью?" но никогда особо не копался глубже

с тем что авторы Го оптимизировали GC под лейтенси и минимизацию stop the world

и правильно сделали

и правильно сделали

ну не совсем правильно )

и когда у тебя очень много (сотни тысяч или миллионы) новых объектов в секунду, а сами объекты короткоживущие, все становится очень грустно

ну вот от короткоживучести должен помочь пул.

точнее это ок для части кейсов

ну вот от короткоживучести должен помочь пул.

с ним будет печалька когда у тебя объектов миллионы )

ты мерял?

к тому же пулл работает интересно

миллионы - это ведь не очень много

ты мерял?

в другом проекте мерял