Из верстальщика в backend.Слишком много вопросов.

Мы ещё в школе пытались переименовывать .mdb в .com, сойдёт? ;) Зачем вообще глупостями такими заниматься, всё равно на никсах вообще похрен, какое у файла имя — программам похер, с каким дескриптором работать, хоть с виртуальным…

можно написать всё, что ты можешь написать на SQL

Смелое заявление. СУБД-специфичные штуки тоже?

Мы

Билли, Томми, Адалана?

Да, для этого отдельныме модули есть.

Зачем вы из убунты делаете nix это я понимаю хотите нишу занять за место настоящих создателей те же pkg это data.xz если deb открыть архиватором , мне кажется не надо заниматься лишними тело движениями

И работают вечно, ага?

Практически да, а что? Соотношение времени работы к времени запуска стремится к бесконечности.

МЕРТВОПРОГ v0.1 (комментарий)

Какая ещё бубунта, какой nix, Вы о чём вообще? GNU/Linux — единая ОС, а дистрибутивы — это васянские ZverCD-сборочки.

Зависит от задачи, однако.

А как если 2 процесса код юзают?

gnome-screenruler creates a helper method Kernel.loop (with 2 arguments), overriding system-wide Kernel.loop (with 0 arguments), and that system-wide method is used when loading gems - which results in this error.

Отличная идея манкипатчить Kernel (типа глобальный неймспейс). Что может пойти не так? Если чо переименуем loop в zaloop.

На ней можно написать всё, что ты можешь написать на SQL.

Но оно же сложнее любых процедурных диалектов SQL. И никто не понимает этот ужос кроме специально обученных питонщиков. А для круда с тремя таблицами как-то избыточно.

Да там не столько учиться нужно, сколько смириться.

Я говорю, что однопоточная «асинхронщина» (в бэкенде) это дичь. Но, учитывая ЦА ноды, мультитрединг им лучше не показывать

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

Это по-прежнему однопоточная хрень, на которой пытаются делать сложные вещи.

Зачем тебе многопоточная хрень? Чтобы делать что?

Единственное оправдание отсутствию мультитрединга — когда среднее количество одновременных запросов не превышает количество ядер

Это оправдано всегда, когда вся работа потока сравнима с работой по переключению его контекста.

Ну вот как ни странно, Мы понимаем с первого раза многих нервотиков

Не мы, а вы.

Может, дело всё же в понималке?

Ну ты уже почти понял, да.

Дублирование… Виндузятникам и ведроидщикам это привычное дело.

Будто в каком-нибудь JS конфликтов с глобальным неймспейсом не бывает, ага. Практика писать void 0 вместо undefined у особенно параноидальных девелоперов не просто так пошла. А в сишечке и вовсе неймспейсов нету, хехе.

Это чо за хеллоуворлды такие?

А вот здесь ни фига не поняли. Браво!

Не знаю как там принято в js, а в данном случае ничего не мешало буратинам сделать свой Sruler.loop. В итоге они к этому и пришли, но в стиле сишки: Kernel.sruler_loop. А разработчики рубей вообще не при чем (ну кроме того, что они дали приматам опасную бритву).

А надо как в жабке, чтобы вообще понятия глобального скоупа не было?

Да хотя бы рассылалка уведомлений или любая другая херня, которая работает с вебсокетом, например. Соединений дохерища, а работы мало.

рассылалка уведомлений

Ну ясно — хэллоуворлд ;) А впрочем, в мире Ъ-микросервисов всё хэллоуворлды…

Покажи мне нативное выполнение тайпскрипта без бабеля.

Deno 1.0

ОФИГЕННО! Спасибище!

В джанге при этом даже как таковых планов нет ORM асинхронным делать.

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

Именно так.

Значимая часть обработки запроса — это время работы БД. Пока БД делает свою часть работы, Web API может не делать ничего, а может начать обрабатывать другие запросы.

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

Не пойму твою мысль. Чем по-твоему независимые асинхронные воркеры хуже тредпула?

Так-то они заведомо лучше.

Каким образом там выполнение «нативное», когда под капотом тот же самый V8?

Ты уверен, что тебя не обманули?

Значимая часть обработки запроса — это время работы БД. Пока БД делает свою часть работы, Web API может не делать ничего, а может начать обрабатывать другие запросы.

А как обрабатываются в асинхронных ОРМ транзакции: создание, завершение, откат транзакции? Логически транзакция это сихронная вещь.

И где ты видишь противоречие? Во-первых, в ручную. Во-вторых, код у тебя всё равно последовательный, хоть и с переключениями, а под транзакцию у тебя будет монопольно захвачено соединение из пула.

Тема провокационная. Хейтеры мало понимают в том, что хейтят, слушать ничего не хотят. Типичные лор срачи)

Ну очевидно же, что оверхедом на независимые процессы и взаимодействие между ними.

Ненужно никакое взаимодействие, воркеры будут шарить максимум сессии. Но они это в любом случае будут делать, ибо нужно дублирование.

оверхедом на независимые процессы

Зато скейлить удобно и приложение проще получается. А от асинхрона всё равно никуда не уйдёшь, если хочешь нормальную производительность, ядра не должны простаивать на блокировках. Насколько мне известно, юзабельного многопоточного асихрона кроме Go так никуда и не завезли.

Ненужно никакое взаимодействие

В хеллоувроте не нужно, потом понадобится ;)

А от асинхрона всё равно никуда не уйдёшь

Но асинхрон-то многопоточности/многопроцессности никак не касается. Его и в одном потоке делать можно, эвентлупом. Собственно, JS без новомодных костылей только так и работает.

ядра не должны простаивать на блокировках

А почему они будут простаивать, если тредов намного больше, чем ядер?

юзабельного многопоточного асихрона кроме Go так никуда и не завезли

Ну так надо это исправлять. Или мигрировать на Go ;) Многие концепты сначала были лишь в одном-двух языках, но потом расползлись по мейнстриму.

потом понадобится

Инстансы вообще ничего друг о друге знать не должны, иначе с архитектурой что-то не так.

тредов намного больше, чем ядер

Хех, в дворники, оптимизатор хренов. Процессы у него жрут…

ничего друг о друге знать не должны

Идеальный мирок функциональщиков, ага. Реальность чуть другая ;)

жрут

При чём тут это? Речь о простое ядер.

Не будут ядра простаивать при асинхроне вообще, если нагрузка будет соответствующая. А своей херотучей потоков ты только и будешь, что кеш вымывать. В итоге у тебя джава питону в производительности сольёт в одни ворота.

Не будут ядра простаивать при асинхроне вообще, если нагрузка будет соответствующая

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

кеш вымывать

С чего бы, если у них память в основном общая? Ведь если общей памяти мало, то и профита особого перед независимыми процессами нет.

Будут, если асинхрон однопоточный

Я охреневаяю с твоей памяти, товарищ золотая рыбка. Речь была про запуск воркеров, разумеется по одному на ядро.

С чего бы, если у них память в основном общая?

И много там общего будет? Каждый поток обрабатывает запрос, у которого есть тело, он за чем-то сходит в бд, сверху ещё дофига памяти выделится на тонну абстракций. А потоков ты хочешь запускать сильно больше чем ядер. Вымывать будет на ура.

Просто нужно 100500 ядер. Асинхрон это затычка для бедных. Изначально вообще никаких воркеров там не предполагалось, всю эту срань придумали для одноядерного проца дабы не подвисать на IO. А хипсторы сделали из этого религию. Асинхрон маздай!

Просто нужно 100500 ядер.

Да. На каждый запрос по микроядру.

То есть я правильно понял, что одним соединением может пользоваться только один процесс?

Ты имеешь ввиду корутину?

Конечно же ты можешь выстрелить себе в ногу при желании. Но если специально не делать обратного, то в плане транзакций всё будет ровно так как было бы при синхронном исполнении.

Речь была про запуск воркеров, разумеется по одному на ядро.

Асинхронность-то при чём?

он за чем-то сходит в бд

Ну вот хотя бы обращения к БД стоит кэшировать. Особенно если БД на другом хосте. Впрочем, кэширование — это в общем случае тоже задача БД, ну или ОС :3

сверху ещё дофига памяти выделится на тонну абстракций

По такой логике стихийные мусорки разрастаются. Вон лежит бумажка — кину-ка рядом ещё, лень к урне идти. О, две бумажки — ну от третьей особо не прибавится. От четвёртой и подавно. А от тысячной…

Вымывать будет на ура

Если воркеры дохрена чего делают, и процессорного кэша не хватает, то вымывать будет по-любому — хоть потоками, хоть процессами. А если не делают, то треды лучше.

Даёшь кластер из Z80!

Асинхронность-то при чём?

Так они будут асинхронно обрабатывать по нескольку одновременных запросов каждый.

Если воркеры дохрена чего делают, и процессорного кэша не хватает, то вымывать будет по-любому — хоть потоками, хоть процессами

По процессу на ядро. Чего там будет вымывать? В случае с «сильно большим» чем количество ядер количеством потоков у тебя одним стеком всё вымывать будет, уж не говоря про то, что я выше сказал, да ещё и потоки будут мигрировать.