дело в том, что по сравнению с event loop'ом который блокируется вычислением полностью - горутина блокирует лишь один из системных потоков, не блокируя при этом весь процесс. Однако с правильным подходом к написанию можно обойти и эту проблему просто мануально переключая горутины в алгоритме

Ну так то вычисления на той же node js - это полюбому плохая идея

Это на основе чего был сделан такой вывод?

это очень, очень редкая задача

именно у постгреса есть более эффективная конструкция, чем where id in (1,b,c,d,e...)

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

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

как раз на них и дробят, например на python + pandas + numpy + scipy

да, но только питон выступает в роли обвязки, сами числодробилки фактически на C/C++ написаны, либо вообще на GPU уходят

Да, но ты же при этом не пишешь сишный код :)

Это на основе чего был сделан такой вывод?

и если нужно сделать что-то совсем кастомное, что не предусмотрено питоновскими либами, то тут уже питон будет больше мешать, чем помогать

динамический язык в число-дробилках будет практически всегда медленее по причине своей динамики о чём говорят многочисленные бенчмарки включая всем известный https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html. это как в 3D графике, либо быстрая статика, либо дорогая динамика (think of lighting calculation). event loop это хорошо для I/O, но вычисления блокирующие весь event loop это вообще не гут. можно конечно разбить процесс на несколько процессов или воркеров внутри процесса, но это порадит новые проблемы такие как shared state, который придётся реализовывать через какую-то БД, либо IPC что гораздо сложнее и затратнее по производительности. У каждого языка/платформы есть свои сильные и слабые стороны. JavaScript подходит далеко не везде и бэкэнд API для продакшена на нём лучше не писать если есть выбор.

Ну нода вообще была походу вытесненна Go в довольно узкую нишу (Server Side Rendering и сборка фронта).

динамический язык в число-дробилках будет практически всегда медленее по причине своей динамики о чём говорят многочисленные бенчмарки включая всем известный https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html. это как в 3D графике, либо быстрая статика, либо дорогая динамика (think of lighting calculation). event loop это хорошо для I/O, но вычисления блокирующие весь event loop это вообще не гут. можно конечно разбить процесс на несколько процессов или воркеров внутри процесса, но это порадит новые проблемы такие как shared state, который придётся реализовывать через какую-то БД, либо IPC что гораздо сложнее и затратнее по производительности. У каждого языка/платформы есть свои сильные и слабые стороны. JavaScript подходит далеко не везде и бэкэнд API для продакшена на нём лучше не писать если есть выбор.

в системных потоках писать сложнее чем на горутинах, в этом и суть горутин. Никто не спорит что можно написать намного более оптимизированный поточный код аля Nginx на C или даже на worker'ах в JS, но сколько у тебя это займёт по времени и сколько съест нервишек? Go в этом плане почти идеален, он позволит тебе быстро написать асинхронный код в синхронном стиле, выполняя его не-блокирующе и используя все ресурсы системы, включая число-дробилки.

V8/luajit vs go?

Не сложнее, он просто менее эффективен.

Что не сложнее? concurrency на потоках не сложнее горутин?

Синхронный многопоточный код не сложнее асинхронного.

хм?

сложнее, я там был, код лепил, по потокам текло в буфер не попадало. в асинхронном коде тебе нужно заботиться о том, чтобы не заблокировать event loop, там блокировать ни в коем случае нельзя! async/await значительно облегчает написание асинх кода, но тем не менее это не Go, где писать блокирующий код - норма.

Есть примеры когда v8/luajit быстрее go.

Есть примеры когда v8/luajit быстрее go.

сложнее, я там был, код лепил, по потокам текло в буфер не попадало. в асинхронном коде тебе нужно заботиться о том, чтобы не заблокировать event loop, там блокировать ни в коем случае нельзя! async/await значительно облегчает написание асинх кода, но тем не менее это не Go, где писать блокирующий код - норма.

Это сложности асинхронного кода.

не сложнее

не сложнее

и причина тому меньший порог входа нежели Java, C++ и тому подобным а Go как-раз таки предоставляет для бэка совершенно новую альтернативу - с одной стороны достаточно быстрый, с другой стороны достаточно простой. Поэтому собственно PHP, Python и JS на бэкэнде теряют долю

а так всё тоже самое

абсолютно не тоже самое. я всё уже выше описал

> сложный язык Я понимаю, когда этим словосочетанием обзывают языки Java/C/C++. Но в других языках то откуда сложность?

а какие собственно есть примеры?

а мы про синхронный многопоточный говорим

на такой размытый вопрос могу лишь размыто ответить: у каждого языка есть свои сложности.

Математика. Тот же pypy умеет автовекторизацию в sse, а luajit еже более продвинут в этом плане

я говорю про синхронный не-блокирующий код в стиле Gо, а не про синхронный в стиле C/C++, это, товарищ, вещи абсолютно разные

Синхронный многопоточный код не сложнее асинхронного. Это в принципе справедливо даже если под асинхронным понимать код Go.

Go код не асинхронен, код синхронен, а вот его выполнение - не обязательно. В этом то и прелесть написания Go кода.

Синхронный многопоточный код не сложнее асинхронного. Это в принципе справедливо даже если под асинхронным понимать код Go.

да и вообще утверждение о том что синх. конкр. код настолько-же "прост" как async в корне неверно если учитывать shared state. mutable shared state это мать всех сложных багов и в многопоточном программирование она доминирует. в async коде нет конкурентности, там в принципе нет такого понятия как concurrency primitives, locks, data races (правда race conditions могут быть)

подскажите?) ANY?

я-же собственно именно об этом и говорил, что питон подходит для склеивания высокопроизводительных модулей. Где heavy-lifting делают C++ модули а питон лишь организуют между ними связь.

я писал многопоточный C/C++: - mutable shared state. - thread'ы дорогие, с ними надо аккуратно. + очень гибкая модель и очень производительная, в умелых руках. я писал асинхронный JS: + event loop безопаснее в плане конкурентности, никаких data race'ов, мутексов и т.д. + I/O не блокирует - блокировать нельзя (!) - асинх конструкции кода без async/await это ад - логика однопоточна по умолчанию и сейчас я пишу на Go: - mutable shared state, однако каналы порой спасают + блокировать можно, никакой асинхронщины в коде + неблокирующее многопоточное исполнение по умолчанию + горутины очень дешёвые, любое конкр. задание можно запустить в своём "потоке" и для web'а (и возможно даже application development'а) гошная модель конкурентности подходит лучше всего. Она достаточно мощная и при этом более простая.

коллеги, а о чем вы трете?

поясняю людям сильные и слабые стороны Go)

ты наш герой?

я писал многопоточный C/C++: - mutable shared state. - thread'ы дорогие, с ними надо аккуратно. + очень гибкая модель и очень производительная, в умелых руках. я писал асинхронный JS: + event loop безопаснее в плане конкурентности, никаких data race'ов, мутексов и т.д. + I/O не блокирует - блокировать нельзя (!) - асинх конструкции кода без async/await это ад - логика однопоточна по умолчанию и сейчас я пишу на Go: - mutable shared state, однако каналы порой спасают + блокировать можно, никакой асинхронщины в коде + неблокирующее многопоточное исполнение по умолчанию + горутины очень дешёвые, любое конкр. задание можно запустить в своём "потоке" и для web'а (и возможно даже application development'а) гошная модель конкурентности подходит лучше всего. Она достаточно мощная и при этом более простая.

коллеги, а о чем вы трете?

В хаскеле получше таки модель.

быстрее в чем?

хорошо иметь мнение, но ещё лучше иметь это мнение обосновать)

mutable shared state и в го можно спокойно организовать асинхронный JS однопоточен, но это скорее исключение из правил, чем правило, ибо есть языки, которые и в async/await могут и в потоки (Python, C#, C++20) Так что на самом деле основная киллерфича Go - это лёгкие горутины и отсутствие необходимости явно работать с тред пуллом.

В многопоточном приложении главное свести взаимодействие между потоками к минимуму, если это сделано, то все равно, на чем построено взаимодействие между ними, на каналах, на мьютексах или на IPC.

Всё то же самое, но STM, вместо мьютексов и каналов.

а я разве утверждал что в Go shared state невозможен? вы читали сообщение?))) потоки в event loop'е не имеют возможности делить память, я уже повторяюсь.

Такой вопрос, какой идешкой пользуетесь?