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

абсолютно неверно. У Go и C очень мало общего, а синтаксис он в любом языке хоть чуток да от C наследует

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

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

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

asyncio достаточно производительный, чтобы продолжать использовать питон в том же вебе, особенно там, где много бизнес логики

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

таки, в названии asyncio заложена суть библиотеки, она не для вычислений :)

с Go же у нас большое преимущество в том, что горутины не event loop, заблокировав горутину мы блокируем лишь 1 системный поток вычислением, все остальные продолжают работу.

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

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

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

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

Зачем на ноде бэкенд писать?

он неограниченно расширяется?

плюс не забывай что Node.js воркеры это таки не потоки. Это воркеры. Разница в том, что они не делят меж собой память, что значительно ограничивает их возможности. Или я не прав про shared mem?

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

мне лично проще для ML завести 20 интрпретаторов петона, которые к одной и тойже базе конектяца и выполняют один и тот же скрипт. Чем манаться с С++/java или с маргинальными биндингами на Go

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

я собственно об этом и говорил. Это прекрасный скриптовой язык, медленный, прожорливый но экспрессивный, поэтому он не про systems/backend programming

у меня с webwire такая херня на винде происходит. Либо винда херня полная в плане TCP/IP, либо Go не очень оптимизирован на windows networking API (что вполне логично и можно бы было понять) https://github.com/qbeon/webwire-go/issues/17

я вот не проверял точно, но мне кажется, что память там можно расшарить через специальные объекты

я думаю, что происходит какая-то другая херня. а чт там на винде в качестве eventpoll? не select же?

Тем не менее, тонна бэкенда на пайтоне пишется. Возможно, всё не так уж и плохо :)

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

Я вообще как-то скептически к потокам в ноде настроен, учитывая что там и V8 раньше даже и не мог даже новый интерпретатор в другом потоке создавать и ему нужен был отдельный процесс.

asyncio достаточно производительный, чтобы продолжать использовать питон в том же вебе, особенно там, где много бизнес логики

товарищи, кто go-pg юзает? как в нём правильно WhereIn использовать со слайсом интов?

Nyet. asyncio - вообще большая ошибка

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

pg.In() использовать, WHERE id IN(?)" , pg.In([]int{1,2})

libuv написан на Си, плюсов в нем нет

А можно рассказать про расширяемость?

да вот хрен код: if err = db.DB.Model(&vlansArr).WhereIn(`id IN (?)`, pg.In(vlanIDs)).Select(); err != nil { ошибка: ОШИБКА #22P02 неверное значение для целого числа: "{}" лог pg: FROM vlans AS "vlan" WHERE (id IN ('{}')) переменная точно не пустая: vlanIDS: []int64{0, 0, 0, 20633, 20640, 20603}

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

https://godoc.org/github.com/go-pg/pg var books []Book err := db.Model(&books).WhereIn("id IN (?)", 1, 2).Select() if err != nil { panic(err) }

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

значит не юзай WhereIn, юзай плейсхолдер и то что я писал выше

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

воткни в него Goshed :)

ну то есть числа дробить надо аккуратно

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

а что вы такое считаете?