Но в моем исправленном тезисе вопрос был про удобство, а как я понимаю, эти костыли в целом влияют на производительность.
Я уже устал, изначальный разговор не было про только удобства, вы сами подсунули этот тезис.
Офф-сайд: некоторые опытные люди, например, автор fasthttp предлагают в go так же запускать по процессу на процессор (в README написано, что на ядро, но в telegram чатике go вызвали вроде как core-разработчика и он пояснил, что это старая информация и имеет смысл только в том случае, если у вас несколько процессоров, прирост почти 15-20%)
Вы сами хоть читаете ссылки, что постите?
Use Go 1.6 as it provides some considerable performance improvements.
Мы можем конечно повторить разговор — вы покажете, как сделано concurrency в питоне (с IPC и процессах), я скажу что это костыли, а вы, что «мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.»
Даже тут я говорю про каналы и горутины. Вы свой комментарий то прочитайте.
Если вы говорите, что вместо каналов в реальности будут использовать внешнюю очередь — то вы не понимаете, что такое многопоточность.
SirEdvin типичный троль, его цель тут просто набрасывать. При этом человек рассуждает на счет concurrency в Go, даже не понимаю что-то такое многопоточность, говоря, что «в реальности вместо каналов в Go будет использоваться внешняя очередь типа NATS».
Так как подавляющее большинство функций может завершиться ошибкой, то получается, что перед всеми вызовами будут писать check. Какой смысл в такой "явности" ума не приложу. Тем более что всё равно не понятно какие именно ошибки может кинуть функция и все ли из них были обработаны.
Ну суть как раз в явности — видно какая функция возвращает ошибку. Если нету хедлера выше, тогда дефолтный используется (просто вернуть ошибку). Все явно — где и как ошибка обработана.
Ясное дело, check нужно делать только там, где есть ошибка (думаю, иначе ошибка компиляции).
ну так как вы можете это сравнивать? Так же как сравниваете горутины и процессы питона.
Вы сравниваете многопоточное приложения с практически распределенными системами. Это разные уровни.
Точно так же сервисы на Go будет использовать внешнею очередь для коммуникации между сервисами.
И это означает, что несколько запросов будут обрабатываться параллельно, я не прав?
Вы не правы, если у вас один тред (как вы сами сказали), выполняться будут конкурентно, не параллельно, просто тред не будет ждать i/o и в это время обрабатывать другой запрос.
Почитайте про многопоточность и конкурентность и не сравнивайте балансировку нагрузки с этим, и каналы в Go и очередями.
Возможно, я не прав, но для меня шедулер, который вы описали очень полезен только в случае, если задача сразу и cpu-bound, и io-bound и по какой-то причине вы ее не разделили. Это круто, но в моем случае простое деление задач на cpu-bound части (где хватает синхронных воркеров с асинхронным мастером) и io-bound (просто асинхронные воркеры) в целом покрывает большое количество кейс. В остальных нужно страдать, давить ресурсами ну или использовать черную магию/перенос задачи на базу данных/rust/c++
Нет, как раз это очень важно для io-bound задач.
Вот есть у вас веб сервер и 10 тредов, каждый реквест обрабатывается одним тред, при этом это io-bound задача — то есть будет момент когда тред будет полностью заблокирован на IO. В Go же не будет такого момента, когда тред будет заблокирован — goroutine будет заблокирована, но треды нет — они будут обрабатывать другие горутины (горутина — один http запрос, читай другие запросы).
Допустим длительность обработки одного запроса одинаковая c Go и c xxxx (python, java, etc). В таком случае Go обработает больше запросов за один и тот же промежуток времени.
Я скажу проще — это не очень полезная и опасная фича. Очень наивно предполагать, что в общем случае две разные версии пакета не будут конфликтовать между собой. Какие-то простые либы вполне возможно, но держать в рантайме два пула коннекшенов к базе данных?
Я понимаю, какую проблему решает это решение, но на мой взгляд решение привносит еще более страшную проблему.
А что может быть страшнее, чем сломанные зависимости? Опять же, это очень специфический кейс, но даже если так — с go mod все будет работать.
Что это за библиотека, которая автоматом создает пул коннектов при импорте? Выбросите ее.
Я хотел вам там написать, что в моем мире синхронизация между потоками нужна для исчезающего количества задач, потому что обычно начинают заниматься более глобальным масштабированием, а утилизация 100% ядер обычно означает, что у вас что-то не так, но мне было лень.
Если у вас такой мир, забудьте про Go и живите спокойно, хватит приходит в каждый пост про Go, он не для вас.
Хотя про утилизацию ресурсов вы так и не поняли.
Вы опять не разобрались в причинах, почему так сделали.
У вас есть зависимость libA-2.0 и libB-1.0, но у libB есть зависимость — libA-1.0. libA-1.0 и 2.0 не совместимы. Допустим должна быть всегда только одна версия либы (libA-2.0) — тогда сломается зависимость libB-1.0. С go mod все будет работать.
И вот уже в которой раз Вы приходите в пост про Go и опять только претензии, и опять не понимаете суть.
Кстати, Вы уже разобрались с многопоточностью, goroutine и каналами?
Ниже там и про exceptions, assertions, etc.
А вам более удобно пользоваться тачпадом или мышкой?
Я уже устал, изначальный разговор не было про только удобства, вы сами подсунули этот тезис.
Вы сами хоть читаете ссылки, что постите?
Мы говорили про concurrency в Go. Вы сказали, что в питоне не хуже, потом привели пример с IPC и процессами.
Если вы говорите, что вместо каналов в реальности будут использовать внешнюю очередь — то вы не понимаете, что такое многопоточность.
А вот ваш комментарий
Ну суть как раз в явности — видно какая функция возвращает ошибку. Если нету хедлера выше, тогда дефолтный используется (просто вернуть ошибку). Все явно — где и как ошибка обработана.
Ясное дело, check нужно делать только там, где есть ошибка (думаю, иначе ошибка компиляции).
Вы сравниваете многопоточное приложения с практически распределенными системами. Это разные уровни.
Точно так же сервисы на Go будет использовать внешнею очередь для коммуникации между сервисами.
Каналы использую для коммуникации (в основном) и управления (старт-стоп).
Вы разницу понимаете между каналами в Го внешней очередью?
Вы не правы, если у вас один тред (как вы сами сказали), выполняться будут конкурентно, не параллельно, просто тред не будет ждать i/o и в это время обрабатывать другой запрос.
Почитайте про многопоточность и конкурентность и не сравнивайте балансировку нагрузки с этим, и каналы в Go и очередями.
Один поток будет обрабатывать одновременно только один запрос.
Почитайте все таки про многопоточное и конкурентное программирование. Особенно в Go — горутины, каналы и так далее.
Нет, как раз это очень важно для io-bound задач.
Вот есть у вас веб сервер и 10 тредов, каждый реквест обрабатывается одним тред, при этом это io-bound задача — то есть будет момент когда тред будет полностью заблокирован на IO. В Go же не будет такого момента, когда тред будет заблокирован — goroutine будет заблокирована, но треды нет — они будут обрабатывать другие горутины (горутина — один http запрос, читай другие запросы).
Допустим длительность обработки одного запроса одинаковая c Go и c xxxx (python, java, etc). В таком случае Go обработает больше запросов за один и тот же промежуток времени.
А что может быть страшнее, чем сломанные зависимости? Опять же, это очень специфический кейс, но даже если так — с go mod все будет работать.
Что это за библиотека, которая автоматом создает пул коннектов при импорте? Выбросите ее.
Если у вас такой мир, забудьте про Go и живите спокойно, хватит приходит в каждый пост про Go, он не для вас.
Хотя про утилизацию ресурсов вы так и не поняли.
У вас есть зависимость libA-2.0 и libB-1.0, но у libB есть зависимость — libA-1.0. libA-1.0 и 2.0 не совместимы. Допустим должна быть всегда только одна версия либы (libA-2.0) — тогда сломается зависимость libB-1.0. С go mod все будет работать.
И вот уже в которой раз Вы приходите в пост про Go и опять только претензии, и опять не понимаете суть.
Кстати, Вы уже разобрались с многопоточностью, goroutine и каналами?