>> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя
>> 10k таких мьютексов будет, что ты будешь делать?
> Я про концептуальность, прозрачность кода и удобство поддержки.
> это разве читаемый код: https://crontab.guru/index.js даже после деобфускации???Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации. Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно странно. Ты пробовал читать машинные коды? А после декомпиляции?
> Аналогичный вопрос по поводу 10к можно адресовать и ЖС кстати (хотя, каюсь,
> я даже пофантазировать не могу, что же это такое, на 10к
> потоков...)
Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть механизмы ноды из коробки позволяют легко сделать то, что на C ты будешь кодить месяцами.
Проблема 100k асинхронных соединений в том, что довольно сложно сделать это эффективно, когда каждый поток требует не так уж и много действий, но эти действия невозможно сделать "одним куском" без прерываний на ожидание доставки/отправки очередной порции данных. Я так навскидку затрудняюсь порекомендовать образовательных ресурсов на тему, но я вникал когда-то в тему через man select (был какой-то man, который был типа туториала на тему того, как надо), и затем ковыряния в потрохах libpth. Плюс возможно другие какие-то ресурсы о которых я не упомню. Но если ты загуглишь что-нибудь в стиле 100k connections, я думаю ты найдёшь ресурсов на тему.
> В конце дня любой язык закончится с jnz, jmp, а все эти
> абстракции придуманны только для удобства коллективного програмирования, с одной лишь
> целью - предотвратить пересечения имен и повысить скорость выдачи кода людьми
> которые понятия не имеют, как оно там под капотом все работает.
Да, пожалуй. Если требовать от каждого, чтобы он понимал бы в деталях все уровни абстракции, начиная с того, на котором он пишет код, и вплоть до исполнительного устройства (будь то CPU или GPU или ещё что), то эти каждые будут выходить на пенсию, не успев закончить учёбу. Это даже если не учитывать того, что период полураспада знаний -- лет десять, наверное. В смысле, через десять лет половина знаний оказывается устаревшей, ибо найдены новые лучшие способы.
> И чем больше абстракций, тем больше понтов и хайпа, а в
> итоге старый i386 с 4мб памяти работающий под досом, считает шестеренки
> в разы быстрей чем современный монстр
Нет, тут ты вваливаешься в необоснованные обобщения. Или, если тебе хочется описание точнее, то ты берёшь корреляцию между потребляемыми программами ресурсами и количеством абстракций, и делаешь из этой корреляции причинно-следственную связь.
Абстракции абстракциям рознь.
Скажем подход async/await реально даёт возможность красиво скрыть под капотом main-loop с select/epoll, обойтись без разбивания кода работы с соединением на отдельные коллбеки (иметь вместо этого последовательный код, выглядящий не сильно сложнее, чем аналогичный блокирующийся код), и по сравнению с подходом libpth (posix threads в юзерспейсе), обойтись без ручного менеджмента потоками (вместо этого ты программируешь в терминах отдельных задач, не парясь раскладывать эти задачи в кучки, которые потом склеивать "псевдоблокирующим" кодом в потоки, оно само так происходит _устраняя_ ненужную абстракцию юзерспейс потока).
Я очень рекомендую тебе взять C и на нём написать что-то подобное. Скажем http-сервачок, который сможет 100k соединений держать. Ты можешь при этом попробовать разные подходы -- epoll и main-loop руками, libpth, ... эмм... ну async/await не то, чтоб нельзя на C, но их бессмысленно реализовывать на C, с целью понять, хрен поймёшь из-за ущербств синтаксиса. Но на C++, я думаю, можно попробовать. Фишка в том, что если ты это сделаешь, ты поймёшь что все эти три подхода работают одинаково, разница просматривается лишь на уровне высокоуровневого кода. И да, на всё это дело тебе может и потребуется пара мьютексов для организации глобальных структур, да и то только в том случае, если ты попытаешься утилизировать больше одного ядра.
