Может быть GO стоит больше придерживаться "своих рамок" и сказать нашим "братьям" из функционального программирования, чтобы те ушли восвояси и перестали просить добавлять подобные вещи, которые делают GO гораздо более сложным языком.

я с этого чуть не помер

Пользуюсь вот этим:

https://scanapp.org/html5-qrcode-docs/

вот тут демо: https://blog.minhazav.dev/research/html5-qrcode

Если простыми словами и для обывателя, то да, вполне можно назвать QUIC транспортным уровнем

Физический <- Канальный <- Сетевой <- Транспортный <- ...

на транспортном уровне у нас для передачи данных используется преимущественно TCP или UDP и это граница ОС - на этом уровне у нас еще нет возможности пилить что-то свое, так что тут все вросло корнями. А вот выше этого уровня уже идут всякие современные QUIC и чего пожелаете, и все это поверх UDP можно намонстрякать.

И как у нее с `отказоустойчивость и масштабируемость` ?

Автор пишет про СУБД, а вы говорите "я SQLite использую"

Ну ок, я вообще все в файлы пишу, а автор про файлы ничего не сказал...

Извините за сарказм, но все (кроме вас) пользуются тем, о чем автор написал

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

Но так вот в тему. GO тоже умеет в CUDA

Статья о том, что есть в основном совсем немного общих случаев, когда нам нужна многопоточность.

Первый, самый основной, наверно, - это когда у вас есть несколько акторов, которые просто заставляют ваше приложение создавать новый поток выполнения. К примеру обработка HTTP запросов. Так вот эта на первый взгляд довольно простая тема, это не про эту статью.

Второй случай - это когда вам нужно в процессе какой то обработки взять да и сходить по сети в разные места или в одно, но много раз. Так вот этот случай хорошо параллелится, но тут обязательно нужно ограничение, просто бросить в чужой сервис 100 тысяч запросов - это жестоко и непрофессионально. Статья объясняет, что в таких случаях ограничивать кол-во потоков числом ядер процессора - это ошибка.

Третий случай - это локальные вычисления внутри одной машины. Добавил я эту тему сюда чисто потому, что вышло интересно. Вот тут нужно ограничивать кол-во потоков числом ядер, это факт. Попробуйте ка запустить 100 тысяч параллельных вычислений хэша. Ваш процессор потонет в переключениях контекста и вымываниях кеша. По крайней мере, мой ПК так и не смог справиться с той же самой задачей за разумный срок.

Так что ваше "если горутин меньше миллиона, то это все еще окей" - это сомнительное заявление.

Вы наверно использовали ссылочные типы (указателями вощем), а надо было построить дерево на слайсе.

Ловите вот пример реализации такого дерева на ГО https://github.com/iv-menshenin/tree

Бэнчмарков не делал и с C++ не сравнивал

а знаете, что интересно?

а то, что пока вы делаете cap(ch) - len(ch) - там уже все поменяется и тот канал, который вы определили, как свободный, на самом деле будет уже под завязку

такова конкурентность

А почему бы вам не сделать всего один канал и несколько читающих воркеров? зачем вам несколько каналов, я право не понимаю

какой то не гошный подход

Покажите, как определить в канале свободное место, пожалуйста

Самое главное, как вы определяете свободность канала?

Я как то раз сделал вот как: напрогал прототип дома, а потом показал, что это работает.

func (e *EthereumNetwork) GenerateKeyPair() (privateKey string, publicKey string, address string, err error) {

Я просто не представляю, что бы я - Русский (с большой буквы) человек - делал бы сейчас, работая на европейскую (с маленькой) компанию.

Деньги пахнут - и именно это заставляет меня гордиться своим местом - разработчик в Российской компании, которая занимается Информационной Безопасностью.

Если мы позволяем компилятору вывести синтаксическое дерево (используя syntax.Fdump) после того как мы распарсили и запустились с ним: