Если бы канал был не буферизованный, то горутина, в которой происходит отправка результата в канал, была бы вынуждена дожидаться, пока значение, отправленное ею в канал, будет прочитано. Это потенциальный дедлок как минимум. О том, что лавинообразное создание таких горутин может привести у OOM, я и не говорю.
Поэтому да - если горутина, отправляющая в канал, должна ждать, когда из канала кто-то прочитает, то однозначно нужно использовать небуферизованный канал. Когда же горутина может отправить в канал и дальше себе работать - стоит создавать буферизованные каналы.
Для получения результата так или иначе ты должен заблокировать основной поток. В примере автора просто нет имитации выполнения полезных действий между запуском задачи и получением из неё результата, поэтому кажется что пример максимально высосан из пальца.
А мне нравится пхп. Я когда пишу на нём, представляю что он как этакий гопник с тупой мордой и замашками зэка, который вырос и наконец остепенился, устроился на работу и даже успешно торгует на бирже. Но замашки зэка никуда не делись.
Попроси человека, который десять лет пишет на пхп с использованием Symfony, написать небольшое приложение-API на го хотя бы с использованием Gin, и можно запасаться попкорном. Symfony - комбайн, в то время как Gin - просто серп, позволяющий не рвать зерно руками.
С тезисом, что поначалу собственный код на Го кажется уродливым убожеством, полностью соглашусь. Добавлю только, что спустя четыре года работы на языке полюбить его я смог, а вот писать на нём код, который мне нравится визуально, так и не сумел.
В Go реализованы Stackfull корутины? Неожиданно. Особенно если вспомнить, что минимальный размер стека горутины составляет 2 Кб, что, если верить статье, соответствует размеру стека Stackless корутин. Или у меня большой пробел в знаниях и я где-то пропустил что горутины это не корутины и где-то под капотом горутины работают поверх корутин? Кто-нибудь может ткнуть меня носом в нужную информацию?
Наверное, вопрос больше в том, как человек воспринимает сам комит. Я так понимаю, для тебя коммит - это нечто совершённое, поэтому тебе удобнее описывать его в прошедшем времени. Типа, человек склонирует репозиторий и в этом репозитории уже всё произошло.
Я же, например, воспринимаю коммит чуть иначе. Для меня он характеризует изменение, которое произойдёт с исходниками, если применить этот коммит. Поэтому мне проще и удобнее описывать его как "что он делает" или "что сделает".
Хм, если бы не этот пост, я бы и не задумался об этом никогда...
А, то есть оно не на постоянке работает и ведёт статистику, а только по необходимости. То есть не фиксирует проблему со стопроцентной вероятностью, а просто может указать на возможный источник проблемы. Понял, спасибо.
Мне выше уже писали что вся статья - сплошная ирония, но, если честно, даже перечитав по второму кругу я не уловил ни иронии, ни стёба. Похоже, пора в отпуск.
За всё время работы с Rust я пользовался отладчиком, может быть, однажды, вся остальная отладка шла через printf.
Вот тут я что-то не уловил. В чём заключается сложность расставить брейкпойнты и запустить отладку Раста нажатием одной кнопки в VSCode, как вы описали это для C++?
Если бы канал был не буферизованный, то горутина, в которой происходит отправка результата в канал, была бы вынуждена дожидаться, пока значение, отправленное ею в канал, будет прочитано. Это потенциальный дедлок как минимум. О том, что лавинообразное создание таких горутин может привести у OOM, я и не говорю.
Поэтому да - если горутина, отправляющая в канал, должна ждать, когда из канала кто-то прочитает, то однозначно нужно использовать небуферизованный канал. Когда же горутина может отправить в канал и дальше себе работать - стоит создавать буферизованные каналы.
Я вот читаю твои комменты, и у меня вопрос назрел. Ты же троллишь, да?)
Самое сложное в SOLID - это вспомнить расшифровку аббревиатуры.
Но n-0 == n, что на 1 превышает максимальный индекс в коллекции. Зачем так делать?
Для получения результата так или иначе ты должен заблокировать основной поток. В примере автора просто нет имитации выполнения полезных действий между запуском задачи и получением из неё результата, поэтому кажется что пример максимально высосан из пальца.
Разве прерывание родительского контекста не вызывает прерывания всех его дочерних контекстов?
А мне нравится пхп. Я когда пишу на нём, представляю что он как этакий гопник с тупой мордой и замашками зэка, который вырос и наконец остепенился, устроился на работу и даже успешно торгует на бирже. Но замашки зэка никуда не делись.
И это великолепно.
Ага, понимаю, кодинг по расчёту :)
go vet ткнёт носом в строку с затенением.
Попроси человека, который десять лет пишет на пхп с использованием Symfony, написать небольшое приложение-API на го хотя бы с использованием Gin, и можно запасаться попкорном. Symfony - комбайн, в то время как Gin - просто серп, позволяющий не рвать зерно руками.
С тезисом, что поначалу собственный код на Го кажется уродливым убожеством, полностью соглашусь. Добавлю только, что спустя четыре года работы на языке полюбить его я смог, а вот писать на нём код, который мне нравится визуально, так и не сумел.
В Go реализованы Stackfull корутины? Неожиданно. Особенно если вспомнить, что минимальный размер стека горутины составляет 2 Кб, что, если верить статье, соответствует размеру стека Stackless корутин. Или у меня большой пробел в знаниях и я где-то пропустил что горутины это не корутины и где-то под капотом горутины работают поверх корутин? Кто-нибудь может ткнуть меня носом в нужную информацию?
Иванов! Тысяча отжиманий! Один! Два! Три!... Пятьдесят четыре! Что, Иванов, сдох? Вот и отец твой тоже!
Наверное, вопрос больше в том, как человек воспринимает сам комит. Я так понимаю, для тебя коммит - это нечто совершённое, поэтому тебе удобнее описывать его в прошедшем времени. Типа, человек склонирует репозиторий и в этом репозитории уже всё произошло.
Я же, например, воспринимаю коммит чуть иначе. Для меня он характеризует изменение, которое произойдёт с исходниками, если применить этот коммит. Поэтому мне проще и удобнее описывать его как "что он делает" или "что сделает".
Хм, если бы не этот пост, я бы и не задумался об этом никогда...
А, то есть оно не на постоянке работает и ведёт статистику, а только по необходимости. То есть не фиксирует проблему со стопроцентной вероятностью, а просто может указать на возможный источник проблемы. Понял, спасибо.
А если переключение между вкладками происходит для, например, сравнения цен - такой пользователь тоже попадёт под фильтр?
Мне выше уже писали что вся статья - сплошная ирония, но, если честно, даже перечитав по второму кругу я не уловил ни иронии, ни стёба. Похоже, пора в отпуск.
Другое - это, например, Кложур. Вот там отладка действительно при первом знакомстве вызывает взрыв головы)
Вот тут я что-то не уловил. В чём заключается сложность расставить брейкпойнты и запустить отладку Раста нажатием одной кнопки в VSCode, как вы описали это для C++?