Нашла чем гордиться. И вообще, что за "миллениашки"? Это для миллениалов вы - малолетние зумерочки, а они для вас "Александры Васильевичи" и "Елены Дмитриевны", и на "Вы". Старших уважать надо
зумеры - ищут опыт, наставника. Ценят обстановку, интересные задачи, могут хлопнуть дверью и уволиться одним днем.
миллениалы - работают за деньги, ищут стабильный доход, готовы мириться с неидеальной обстановкой на работе, если за это хорошо платят.
Так блин, миллениалы не потому не ищут наставника, что они миллениалы. Миллениалы не ищут наставника, потому что им под сорок, в среднем - поздновато в 40 учиться работать! А зумеры могут хлопнуть дверью и не вернуться на работу после обеда не потому, что они зумеры, а потому что им по 20, у них юношеский максимализм, гормоны и инфантильное поведение.
Вся "разница между поколениями" сводится, внезапно, к тому, что семейные люди, уже состоявшиеся в профессии, не склонны искать себе наставника и работают за деньги, а нарастающие джуны ищут опыт и профессиональный рост.
Хотите сравнить зумеров/бумеров/миллениалов/кто-там еще есть - сравнивайте один возраст. Т.е. сравнивать нужно современных зумеров с тем, какими миллениалы были 20 лет назад (подскажу, такие же). А то, что в статье - бред и необоснованное развешивание ярлыков.
Ну что-то все ваши наблюдения различия между поколениями сводятся к тому, что одним уже под 40, у них семьи, дети, ответственность, а вторые - сами ещё дети, только учатся и им не страшно потерять работу (потому что их первые кормят пока ещё)
Можно даже не мечтать. Достаточно прозрачных смол нет и не предвидится (спекание производится методом засвета, а в прозрачной смоле паразитная засветка и блики убьёт любое подобие детализации/точности). Свет идет конусом, с линейными размерами беда бедовая - допуски в пределах 10-дюймовой платформы до миллиметра. Спекаемый слой - дискретный, картинка, состоящая из точек. Поверхность будет ребристая, а в случае постобработки - прощай форма.
Ниже ответ от "экспертов" - ненаучная дичь, не слушайте их.
пример с pypy выглядит несколько наивно. M:N асинхронность есть (подскажу, нет)? Ну тогда высказывания вида "питон выдает сравнимую производительность" превращаются в пшик.
К слову о том, зачем Go, если есть Java - все она же, M:N. Если она нужна, Go даёт весьма ощутимый выигрыш. Если нет - не дает. Все просто.
"Человек и сетевой инженер" взял не подходящий для его задач инструмент и жалуется, что инструмент ему не понравился. Про задачи, где Go подошел бы идеально, человек и инженер пишет какую-то оторванную от реальности околесицу (впрочем, как и про назначение той же Java). И про стек сбера и тбанка он странное пишет - Go у них отлично применяется.
В общем, человек и сетевой инженер решил порассуждать о материях, в которых ничего не понимает. Не разработчик он.
Хороший продукт это тот который появился в условиях свободного рынка, а не под упряжкой в телеге.
Давайте сойдемся на том, что хороший коммерческий продукт с гораздо большей вероятностью появится в условиях рыночной конкуренции. А то как агитка выглядит.
не, это не про "возможность роста" в том смысле, что могут вырасти. Там про то, что "бла-бла-бла, все дорожает, но нельзя исключать, что провайдеры просто задирают цены при любой возможности"
Оппортунистический рост цен - это типа "повышаем, потому что можем". Сложились условия на рынке, что у конкурентов либо нет аналога, либо миграция очень дорогая - поднимаем цены, потому что "а куда ты денешься с подводной лодки"
Думаю, наиболее легкое объяснение горутинам такое: горутина (goroutine) — это легковесный оберточный функционал над потоком.
Что такое "оберточный функционал над потоком"? Оно мало того, что не понятно, так еще и искажает суть явления.
A goroutine is a lightweight thread managed by the Go runtime.
Легковесный тред, управляемый рантаймом Go. Это не обертка над потоком. Обертка над потоком - это Machine. Горутина - это штука, которая исполняется на этом потоке.
Планировщик операционной системы, в которой работает программа, переключает Машины.
Планировщик операционной системы не имеет прямого отношения к "Машинам". Он тупо запускает N (GOMAXPROCS) системных тредов, в которых они потом так и живут, ничего он не переключает. А вот планировщик в рантайме Go распределяет горутины по машинам, на которых они исполняются.
Для запуска функции как горутину необходимо написать go func() , где func() - функция, которую хотите запустить.
Не совсем так. go func() не запускает функцию, а всего лишь ставит горутину в очередь исполнения, передает ее планировщику, чтобы он по возможности отдал ее одной из "машин" на исполнение.
Собственно, поэтому следующее тоже не совсем верно:
Ничего не произойдет, ведь горутина выполняется параллельно с "main()"
В вашем случае с некоторой ненулевой вероятностью горутина вообще не выполняется, тупо в очереди находится (тем более в go playground, который, возможно, вообще однопоточный)
// создаем WaitGroup
wg := &sync.WaitGroup{}
Вот тут & излишне. Дальше ваша wg передается замыканием, а замыкание в Go проходит по указателю.
"mutual exclusion", что в переводе означает "взаимное изолирование"
В переводе это означает "взаимное исключение"
это некая примитивная синхронизация
Это вы так synchronization primitive перевели? Не "некая примитивная синхронизация", а "примитив синхронизации". Как, к слову, и WaitGroup и даже, внезапно, канал.
Перед обновлением счетчика, мы вызываем "lock.Lock()" для создания блокировки. Теперь ни одна другая горутина не сможет использовать "counter".
Ну вы бы хоть рассказали, почему не сможет. Это примитив синхронизации. Он заблокирует горутину (да, он не значение блокирует, а горутину), пока инструкция не сможет быть исполнена.
Т.е. если вы лочите мьютекс из горутины №1, а потом пытаетесь сделать то же самое из горутины №2, то вторая горутина заблокируется, пока первая не разлочит мьютекс.
Кстати, раз уж вы решили разложить все по полочкам, то примитивы синхронизации надо было начинать с атомиков. Потому что у мьютекса и вейтгруппы внутри как раз они и есть.
Атомарные операции - это низкоуровневые примитивы синхронизации, которые обеспечивают способ выполнения операций чтения-модификации-записи (read-modify-write) над общими переменными без необходимости в блокировке (Атомарная операция — операция, которая либо выполняется целиком, либо не выполняется вовсе; операция, которая не может быть частично выполнена и частично не выполнена).
Ну вот, в формулировке read-modify-write, а в примере ниже save/load. Не надо так.
Ну и вот это "Атомарная операция — операция, которая либо выполняется целиком, либо не выполняется вовсе" - это скорее к теории баз данных формулировка, и это про транзакционность.
В трактовке многопоточных приложений - a sequence of instructions that are executed as a single, indivisible unit of work
Последовательность инструкций, исполняемых как одна неделимая единица работы. Т.е. это гарантия, что в процессе выполнения не произойдет переключение контекста.
Например i++ не атомарна. Это получение значения переменной + увеличение значения на 1 + запись значения в переменную - 3 операции, соседний поток может вклиниться между любой из них, что приведет к неконсистентности данных. Атомарные операции отличаются тем, что соседний поток вклиниться не может, они для того и нужны.
Технически - это конвейер, откуда можно считывать или помещать данные. То есть одна горутина может отправить данные в канал, а другая — считать помещенные в этот канал данные.
Ничего не понятно. Технически канал - примитив синхронизации, по сути - семафор.
Канал можно и закрыть.
Канал нужно закрывать. Просто за правило возьмите: как только записали в канал все, что хотели - закройте канал.
Для этого надо вызвать функцию close(Ваш канал), тем самым заблокировав доступ к чтению из него.
В смысле, заблокировав доступ к чтению??? Чтение из закрытого канала возвращает zero-value для типа канала. С чего оно заблокируется-то?
val, ok := <- Ваш канал, где val - переменная, в которую запишется значение с канала, если это возможно, а ok - булева переменная, где true означает, что из канала можно прочитать данные, а false - что он закрыт/невозможно считать.
Ну доку-то почитайте! false означает, что канал закрыт (и все значения из него прочитаны, в случае буферизованного канала). Никаких невозможно читать там нет, даже напротив, читать из него очень даже возможно.
С помощью for range можно читать данные из закрытого буферизированного канала, так как данные остаются в буфере даже после закрытия канала.
А без range'а нельзя? Данные в буфере пропадают? Что вы несете?
Если Вы будете считывать данные из пустого канала, Вы получите ошибку "Deadlock", которая появляется при бесконечном считывании из канала.
Дичь. Эталонная. Дедлок - это ситуация, когда все горутины находятся в спящем состоянии и не могут быть "разбужены", тчк.
select - это почти что switch, но без аргументов.
Гениальное определение. Неверное, ничего не объясняющее, но гениальное.
Вот такое будет ближе к истине:
Примитив синхронизации, блокирующий поток исполнения, пока один из case'ов не сможет быть выполнен.
Я долго писал эту статью, вытаскивая из каждого источника самое важно
Достаточно было одного источника, https://go.dev/doc/
Если речь не идет о специфическом ПО, работающем только под Windows, Linux может выполнять все задачи, которые обычно нужны среднестатистическому человеку. Это офис, серфинг по сети, программирование (тут есть специфика, конечно) и все такое прочее.
У вас "(тут есть специфика, конечно)" отклеилась. Правильно вот так:
офис (тут есть специфика, конечно), серфинг по сети, программирование и все такое прочее.
В заголовке - про извлечение данных из Linux, а в содержимом - gps, уровень wifi, уровень батареи и свободное место на диске.
Половина этого к Linux имеет весьма опосредованное отношение, вторая - вообще кроссплатформенными кутишными апи решается. И все это вместе достаточно сложно назвать прям уж "данными".
Признаться, ожидал какого-то сурового парсинга терабайтных файлов или анализа гигабайтных чанков логов ядра...
Нашла чем гордиться. И вообще, что за "миллениашки"? Это для миллениалов вы - малолетние зумерочки, а они для вас "Александры Васильевичи" и "Елены Дмитриевны", и на "Вы". Старших уважать надо
Различия между поколениями есть, но не те, что в статье перечислены. В статье - различия в возрастных категориях
Бро, это не я ярлыки вешаю, а автор(ка) статьи.
Она пишет:
зумеры - ищут опыт, наставника. Ценят обстановку, интересные задачи, могут хлопнуть дверью и уволиться одним днем.
миллениалы - работают за деньги, ищут стабильный доход, готовы мириться с неидеальной обстановкой на работе, если за это хорошо платят.
Так блин, миллениалы не потому не ищут наставника, что они миллениалы. Миллениалы не ищут наставника, потому что им под сорок, в среднем - поздновато в 40 учиться работать! А зумеры могут хлопнуть дверью и не вернуться на работу после обеда не потому, что они зумеры, а потому что им по 20, у них юношеский максимализм, гормоны и инфантильное поведение.
Вся "разница между поколениями" сводится, внезапно, к тому, что семейные люди, уже состоявшиеся в профессии, не склонны искать себе наставника и работают за деньги, а нарастающие джуны ищут опыт и профессиональный рост.
Хотите сравнить зумеров/бумеров/миллениалов/кто-там еще есть - сравнивайте один возраст. Т.е. сравнивать нужно современных зумеров с тем, какими миллениалы были 20 лет назад (подскажу, такие же). А то, что в статье - бред и необоснованное развешивание ярлыков.
Ну что-то все ваши наблюдения различия между поколениями сводятся к тому, что одним уже под 40, у них семьи, дети, ответственность, а вторые - сами ещё дети, только учатся и им не страшно потерять работу (потому что их первые кормят пока ещё)
не, просто Беббидж, видимо, ее настоящим отцом был. Такое нередко встречалось в благородных семействах...
поиск простых чисел!
Можно даже не мечтать. Достаточно прозрачных смол нет и не предвидится (спекание производится методом засвета, а в прозрачной смоле паразитная засветка и блики убьёт любое подобие детализации/точности). Свет идет конусом, с линейными размерами беда бедовая - допуски в пределах 10-дюймовой платформы до миллиметра. Спекаемый слой - дискретный, картинка, состоящая из точек. Поверхность будет ребристая, а в случае постобработки - прощай форма.
Ниже ответ от "экспертов" - ненаучная дичь, не слушайте их.
Действительно, отсутствие наследования - одно из самых странных наследований, какие я когда-либо видел)
пример с pypy выглядит несколько наивно. M:N асинхронность есть (подскажу, нет)? Ну тогда высказывания вида "питон выдает сравнимую производительность" превращаются в пшик.
К слову о том, зачем Go, если есть Java - все она же, M:N. Если она нужна, Go даёт весьма ощутимый выигрыш. Если нет - не дает. Все просто.
"Человек и сетевой инженер" взял не подходящий для его задач инструмент и жалуется, что инструмент ему не понравился. Про задачи, где Go подошел бы идеально, человек и инженер пишет какую-то оторванную от реальности околесицу (впрочем, как и про назначение той же Java). И про стек сбера и тбанка он странное пишет - Go у них отлично применяется.
В общем, человек и сетевой инженер решил порассуждать о материях, в которых ничего не понимает. Не разработчик он.
Давайте сойдемся на том, что хороший коммерческий продукт с гораздо большей вероятностью появится в условиях рыночной конкуренции. А то как агитка выглядит.
не, это не про "возможность роста" в том смысле, что могут вырасти. Там про то, что "бла-бла-бла, все дорожает, но нельзя исключать, что провайдеры просто задирают цены при любой возможности"
Оппортунистический рост цен - это типа "повышаем, потому что можем". Сложились условия на рынке, что у конкурентов либо нет аналога, либо миграция очень дорогая - поднимаем цены, потому что "а куда ты денешься с подводной лодки"
Если вы не против, покритикую:
Что такое "оберточный функционал над потоком"? Оно мало того, что не понятно, так еще и искажает суть явления.
A goroutine is a lightweight thread managed by the Go runtime.
Легковесный тред, управляемый рантаймом Go. Это не обертка над потоком. Обертка над потоком - это Machine. Горутина - это штука, которая исполняется на этом потоке.
Планировщик операционной системы не имеет прямого отношения к "Машинам". Он тупо запускает N (GOMAXPROCS) системных тредов, в которых они потом так и живут, ничего он не переключает. А вот планировщик в рантайме Go распределяет горутины по машинам, на которых они исполняются.
Не совсем так. go func() не запускает функцию, а всего лишь ставит горутину в очередь исполнения, передает ее планировщику, чтобы он по возможности отдал ее одной из "машин" на исполнение.
Собственно, поэтому следующее тоже не совсем верно:
В вашем случае с некоторой ненулевой вероятностью горутина вообще не выполняется, тупо в очереди находится (тем более в go playground, который, возможно, вообще однопоточный)
Вот тут & излишне. Дальше ваша wg передается замыканием, а замыкание в Go проходит по указателю.
В переводе это означает "взаимное исключение"
Это вы так synchronization primitive перевели? Не "некая примитивная синхронизация", а "примитив синхронизации". Как, к слову, и WaitGroup и даже, внезапно, канал.
Ну вы бы хоть рассказали, почему не сможет. Это примитив синхронизации. Он заблокирует горутину (да, он не значение блокирует, а горутину), пока инструкция не сможет быть исполнена.
Т.е. если вы лочите мьютекс из горутины №1, а потом пытаетесь сделать то же самое из горутины №2, то вторая горутина заблокируется, пока первая не разлочит мьютекс.
Кстати, раз уж вы решили разложить все по полочкам, то примитивы синхронизации надо было начинать с атомиков. Потому что у мьютекса и вейтгруппы внутри как раз они и есть.
Ну вот, в формулировке read-modify-write, а в примере ниже save/load. Не надо так.
Ну и вот это "Атомарная операция — операция, которая либо выполняется целиком, либо не выполняется вовсе" - это скорее к теории баз данных формулировка, и это про транзакционность.
В трактовке многопоточных приложений - a sequence of instructions that are executed as a single, indivisible unit of work
Последовательность инструкций, исполняемых как одна неделимая единица работы. Т.е. это гарантия, что в процессе выполнения не произойдет переключение контекста.
Например i++ не атомарна. Это получение значения переменной + увеличение значения на 1 + запись значения в переменную - 3 операции, соседний поток может вклиниться между любой из них, что приведет к неконсистентности данных. Атомарные операции отличаются тем, что соседний поток вклиниться не может, они для того и нужны.
Ничего не понятно. Технически канал - примитив синхронизации, по сути - семафор.
Канал нужно закрывать. Просто за правило возьмите: как только записали в канал все, что хотели - закройте канал.
В смысле, заблокировав доступ к чтению??? Чтение из закрытого канала возвращает zero-value для типа канала. С чего оно заблокируется-то?
Ну доку-то почитайте! false означает, что канал закрыт (и все значения из него прочитаны, в случае буферизованного канала). Никаких невозможно читать там нет, даже напротив, читать из него очень даже возможно.
А без range'а нельзя? Данные в буфере пропадают? Что вы несете?
Дичь. Эталонная. Дедлок - это ситуация, когда все горутины находятся в спящем состоянии и не могут быть "разбужены", тчк.
Гениальное определение. Неверное, ничего не объясняющее, но гениальное.
Вот такое будет ближе к истине:
Примитив синхронизации, блокирующий поток исполнения, пока один из case'ов не сможет быть выполнен.
Достаточно было одного источника, https://go.dev/doc/
вероятно, будет. Планировщик же.
В любом случае, меньше - абсолютно точно не будет. Насколько больше - мерить надо. Возможно, единицы процентов, а может быть, и десятки.
пользователи меняют процессоры в ноутбуках? А вы точно программист?
У вас "(тут есть специфика, конечно)" отклеилась. Правильно вот так:
Можно и я покритикую?
В заголовке - про извлечение данных из Linux, а в содержимом - gps, уровень wifi, уровень батареи и свободное место на диске.
Половина этого к Linux имеет весьма опосредованное отношение, вторая - вообще кроссплатформенными кутишными апи решается. И все это вместе достаточно сложно назвать прям уж "данными".
Признаться, ожидал какого-то сурового парсинга терабайтных файлов или анализа гигабайтных чанков логов ядра...
Фигня там, а не e2e. end-to-end с MitM в комплекте
для интереса: чем вызвано "нехотение"? Отторжение cvs как таковых, или просто другая cvs'ка была "ближе к телу"?
может, пограничные сети?