Может быть GO стоит больше придерживаться "своих рамок" и сказать нашим "братьям" из функционального программирования, чтобы те ушли восвояси и перестали просить добавлять подобные вещи, которые делают GO гораздо более сложным языком.
Может быть, Go нужно было еще больше "gate-keep" и просто сказать "functional-bros", чтобы они ушли и перестали просить о таких функциях, которые делают Go гораздо более сложным и комплексным языком.
Транспорт транспорту рознь. Вы хоть по электронной почте можете данные транспортировать, но коли уж взялись писать статью и делите ее на слои, то хорошо бы соблюдать точность.
на транспортном уровне у нас для передачи данных используется преимущественно TCP или UDP и это граница ОС - на этом уровне у нас еще нет возможности пилить что-то свое, так что тут все вросло корнями. А вот выше этого уровня уже идут всякие современные QUIC и чего пожелаете, и все это поверх UDP можно намонстрякать.
Статья о том, что есть в основном совсем немного общих случаев, когда нам нужна многопоточность.
Первый, самый основной, наверно, - это когда у вас есть несколько акторов, которые просто заставляют ваше приложение создавать новый поток выполнения. К примеру обработка HTTP запросов. Так вот эта на первый взгляд довольно простая тема, это не про эту статью.
Второй случай - это когда вам нужно в процессе какой то обработки взять да и сходить по сети в разные места или в одно, но много раз. Так вот этот случай хорошо параллелится, но тут обязательно нужно ограничение, просто бросить в чужой сервис 100 тысяч запросов - это жестоко и непрофессионально. Статья объясняет, что в таких случаях ограничивать кол-во потоков числом ядер процессора - это ошибка.
Третий случай - это локальные вычисления внутри одной машины. Добавил я эту тему сюда чисто потому, что вышло интересно. Вот тут нужно ограничивать кол-во потоков числом ядер, это факт. Попробуйте ка запустить 100 тысяч параллельных вычислений хэша. Ваш процессор потонет в переключениях контекста и вымываниях кеша. По крайней мере, мой ПК так и не смог справиться с той же самой задачей за разумный срок.
Так что ваше "если горутин меньше миллиона, то это все еще окей" - это сомнительное заявление.
точно. вот я балда. ни разу за все время разработки не видел такого и даже не было необходимости в этом
а знаете, что интересно?
а то, что пока вы делаете cap(ch) - len(ch) - там уже все поменяется и тот канал, который вы определили, как свободный, на самом деле будет уже под завязку
такова конкурентность
А почему бы вам не сделать всего один канал и несколько читающих воркеров? зачем вам несколько каналов, я право не понимаю
Интересно (для меня) новыми красками в новых реалиях заиграл ваш комментарий. В суровой реальности, где иностранные компании под влиянием конгломерата и самого обыкновенного фашизма забывают обо всех принципах и нормах международного права...
Я просто не представляю, что бы я - Русский (с большой буквы) человек - делал бы сейчас, работая на европейскую (с маленькой) компанию.
Деньги пахнут - и именно это заставляет меня гордиться своим местом - разработчик в Российской компании, которая занимается Информационной Безопасностью.
Поглядел оригинал, там вот это написано:
Может быть GO стоит больше придерживаться "своих рамок" и сказать нашим "братьям" из функционального программирования, чтобы те ушли восвояси и перестали просить добавлять подобные вещи, которые делают GO гораздо более сложным языком.
Может быть, Go нужно было еще больше "gate-keep" и просто сказать "functional-bros", чтобы они ушли и перестали просить о таких функциях, которые делают Go гораздо более сложным и комплексным языком.я с этого чуть не помер
Вижу, что страничке уже сто лет, но я просто это тут оставлю, вдруг кому-то пригодится.
Пользуюсь вот этим:
https://scanapp.org/html5-qrcode-docs/
вот тут демо: https://blog.minhazav.dev/research/html5-qrcode
Спасибо, друг
Ах, до меня дошло. Вы используете не OSI модель. А какую то упрощенную.
Если простыми словами и для обывателя, то да, вполне можно назвать QUIC транспортным уровнем
Транспорт транспорту рознь. Вы хоть по электронной почте можете данные транспортировать, но коли уж взялись писать статью и делите ее на слои, то хорошо бы соблюдать точность.
Физический <- Канальный <- Сетевой <- Транспортный <- ...
на транспортном уровне у нас для передачи данных используется преимущественно TCP или UDP и это граница ОС - на этом уровне у нас еще нет возможности пилить что-то свое, так что тут все вросло корнями. А вот выше этого уровня уже идут всякие современные QUIC и чего пожелаете, и все это поверх UDP можно намонстрякать.
А как у Автора QUIC попал во второй, транспортный уровень?
А чем докажете, что SQLite - это СУБД?
И как у нее с `отказоустойчивость и масштабируемость` ?
Кек
Автор пишет про СУБД, а вы говорите "я SQLite использую"
Ну ок, я вообще все в файлы пишу, а автор про файлы ничего не сказал...
Извините за сарказм, но все (кроме вас) пользуются тем, о чем автор написал
Зачем мне нули и зачем куда?
Статья же не об этом. А о том, что если вы ограничиваете кол-во запущенных горутин, то этот как минимум должно быть осознанно и обоснованно.
Но так вот в тему. GO тоже умеет в CUDA
Если что, я тогда поясню...
Статья о том, что есть в основном совсем немного общих случаев, когда нам нужна многопоточность.
Первый, самый основной, наверно, - это когда у вас есть несколько акторов, которые просто заставляют ваше приложение создавать новый поток выполнения. К примеру обработка HTTP запросов. Так вот эта на первый взгляд довольно простая тема, это не про эту статью.
Второй случай - это когда вам нужно в процессе какой то обработки взять да и сходить по сети в разные места или в одно, но много раз. Так вот этот случай хорошо параллелится, но тут обязательно нужно ограничение, просто бросить в чужой сервис 100 тысяч запросов - это жестоко и непрофессионально. Статья объясняет, что в таких случаях ограничивать кол-во потоков числом ядер процессора - это ошибка.
Третий случай - это локальные вычисления внутри одной машины. Добавил я эту тему сюда чисто потому, что вышло интересно. Вот тут нужно ограничивать кол-во потоков числом ядер, это факт. Попробуйте ка запустить 100 тысяч параллельных вычислений хэша. Ваш процессор потонет в переключениях контекста и вымываниях кеша. По крайней мере, мой ПК так и не смог справиться с той же самой задачей за разумный срок.
Так что ваше "если горутин меньше миллиона, то это все еще окей" - это сомнительное заявление.
Если ваша реализация деревьев на ГО тормозит, значит вы неправильно написали =P
Вы наверно использовали ссылочные типы (указателями вощем), а надо было построить дерево на слайсе.
Ловите вот пример реализации такого дерева на ГО https://github.com/iv-menshenin/tree
Бэнчмарков не делал и с C++ не сравнивал
точно. вот я балда. ни разу за все время разработки не видел такого и даже не было необходимости в этом
а знаете, что интересно?
а то, что пока вы делаете cap(ch) - len(ch) - там уже все поменяется и тот канал, который вы определили, как свободный, на самом деле будет уже под завязку
такова конкурентность
А почему бы вам не сделать всего один канал и несколько читающих воркеров? зачем вам несколько каналов, я право не понимаю
какой то не гошный подход
Признаюсь, что отстал от жизни
Покажите, как определить в канале свободное место, пожалуйста
Подскажите. что это за термин такой "более свободный канал"?
Самое главное, как вы определяете свободность канала?
Кажецца вы не поняли посыл. Я согласен со всем, чт вы сказали, но не понял с какой из моих идей вы спорите =)
Я бы не рекомендовал убеждать в этом.
Но если очень надо, то нужно искать преимущества вашего решения.
Я как то раз сделал вот как: напрогал прототип дома, а потом показал, что это работает.
Как же вам не стыдно, делать столько возвратных значений в функции на GO =)
Интересно (для меня) новыми красками в новых реалиях заиграл ваш комментарий. В суровой реальности, где иностранные компании под влиянием конгломерата и самого обыкновенного фашизма забывают обо всех принципах и нормах международного права...
Я просто не представляю, что бы я - Русский (с большой буквы) человек - делал бы сейчас, работая на европейскую (с маленькой) компанию.
Деньги пахнут - и именно это заставляет меня гордиться своим местом - разработчик в Российской компании, которая занимается Информационной Безопасностью.
А вот над этим куском совсем не работали, пришлось смотреть в источнике, чтобы понять, что имеется в виду: