коллега Николай, а вы логи-то пишете? по логам нельзя понять, что там у вас встает колом?

может ждать отправки или получения данных

еполл - это вы очень глубоко отправились

транспорт вы настраиваете?

конечно она пцустая - у вас же приложение не делает ничего

это все зачем?

на одном рантайме 100.000 горутин занимаются всяким I/O, на другом рантайме 12 горутин занимаются обработкой time-critical заданий

А зачем писать критичное ко времени на языке 1) с GC 2) с плохо оптимизирующим компилятором?

откуда у горутин приоритеты

коллега, нет никакого рендеринга

это чисто пример, я не говорю что нам надо обязательно рендерить на Go))) просто collective concurrency это хорошо для массовой параллельности аля API-server. но для time-critical concurrency это ужасно.. если у нас 4 горутины играют роль DSP (signal processing) и пораждают дополнительные горутины для обработки асинхронных тасков, то растущее колво дополнительных горутин будет отрицательно влиять на точность работы первых 4, они будут красть у тех время. Т.е. на данный момент Go совершенно не применим для time-critical + massively parallel, что можно бы было изменить приоритетностью определённых горутин поместив их в некие "work groups"

А зачем писать критичное ко времени на языке 1) с GC 2) с плохо оптимизирующим компилятором?

а приоритеты для горутин - это смешно

я абсолютно согласен что лучше просто взять C++ / Rust и не париться! Но тем не менее размышляю над тем как оправдать титул "general purpose programming language", поскольку на Go гораздо легче писать чем на C++ / Rust С гошным GC в принципе можно жить поскольку он оптимизирован не на throughput а на latency, главное мусора не создавать и всё будет окей.

Удалось?)

вполне, на нём можно что угодно написать (насколько это разумно это уже другой вопрос, главное что можно) 3D rendering, GUIs, APIs, DSPs, drivers, an operating systems kernel (maybe?)

вполне, на нём можно что угодно написать (насколько это разумно это уже другой вопрос, главное что можно) 3D rendering, GUIs, APIs, DSPs, drivers, an operating systems kernel (maybe?)

Кто-то и на C умудряется все что угодно написать. Но нам то это зачем?

суть была в том, что при титуле "general purpose" - Go для некоторых задач применять просто незовможно, не решает задачу, поэтому скорее не general purpose

Так что не получается нормально писать на Го?

любая time-critical задача

а для каких задач НЕВОЗМОЖНО(если не системные)?

помещаете в рутину обьявляете переменные заранее ,никаких вызовов функций, не давайте пищи Гколлектору

Так можно отключить GC, если его задержки мешают

Так можно отключить GC, если его задержки мешают

дело не в gc, дело в отсутствии гарантий по времени

в продакшне отключить GC в языке который был designed for GC?))

верно, это не страшно если у вас 10k одновременных клиентов и один запрос можно затянуть на секунду и это терпимо..

Если у вас такая задача то видимо да

если задача, для которой критичны задержки gc - то го не нужен

ну да, к сожалению.. я за "the right tool for the right job", но порой это жуткий context switch, другие библиотеки, другие парадигмы, другие инструменты, сильно понижает продуктивность поэтому зачастую языки использую не по назначению, чисто ради сохранения продуктивности и воизбежание просадки

например, джаваскрипт на сервере

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

для очень маленьких проектов это лучше, чем тащить Go на бэкэнд, серьёзно, потому-что: продуктивность. но как только всё это начинает расти - можно спокойно выбрасывать Node.js сервер и писать backend на Go.

для очень маленьких проектов есть питон и какой-нибудь Flask/Bottle

так зачем тебе питон, если JavaScript тебе роднее да ещё и V8 зачастую быстрее питонского runtime'а

так зачем тебе питон, если JavaScript тебе роднее да ещё и V8 зачастую быстрее питонского runtime'а

А если не роднее

затем, что на питоне проект займет несколько строк, будет иметь нормальный орм и стабильные пакеты, и все это при минимуме сторонних зависимостей