> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации.
> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно
> странно. Ты пробовал читать машинные коды? А после декомпиляции?Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль
> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть
> механизмы ноды из коробки позволяют легко сделать то, что на C
> ты будешь кодить месяцами.
А где я говорил что то плохое про ноду??? Я про концептуальный стиль програмирования если вы не поняли, который допускает создавать мешанину исходного кода по типу польской конвекции, как в Б3-34 калькуляторе.
> Проблема 100k асинхронных соединений в том, что довольно сложно сделать это эффективно,
Настоящих ассинхронных соединений на 100к не может быть в принципе! Даже на 128 коровом проце.
По одной простой причине, что невозможно физически обеспечить ассинхронность на устройстве у которого не достаточно ресурсов на тру ассинхронность, а значит будет опять виртуальность, которя реализуется програмно
> Я так навскидку затрудняюсь порекомендовать образовательных
> ресурсов на тему,
Да я вроде как и не просил... и вообще не собирался впадать в подкапотную демагогию, тем более на этом обезличином ресурсе
> Но если ты загуглишь
> что-нибудь в стиле 100k connections, я думаю ты найдёшь ресурсов на
> тему.
Я почему то и не сомневался, что все закончиться к отправке в гугл, хотя даже это и не надо было :)
> Если требовать от каждого, чтобы он понимал бы в деталях
> все уровни абстракции, начиная с того, на котором он пишет код,
> и вплоть до исполнительного устройства (будь то CPU или GPU или
> ещё что), то эти каждые будут выходить на пенсию, не успев
> закончить учёбу. Это даже если не учитывать того, что период полураспада
> знаний -- лет десять, наверное. В смысле, через десять лет половина
> знаний оказывается устаревшей, ибо найдены новые лучшие способы.
И что в этом плохого - постоянно учиться? Мы ж с вами не померли ? Даже наоборот - интересно.
Проблема только по моему в том, что электрик должен знать как банально влияет сечение провода на пропускаемый ток, а сантехник знать для чего делается воздушка... так же и програмеры, должны знать как оно там работает на самом деле, вы посмотрите на молодеж, они не програмируют, а просто линкуют готовые фрэймворки не задумываясь об эфективности вообще и не вникая в сущность. Вы посмотрите на сумашествие зависимостей в ноде, в пыхе...
> Скажем подход async/await реально даёт возможность красиво скрыть под капотом main-loop
> с select/epoll, обойтись без разбивания кода работы с соединением на отдельные
> коллбеки (иметь вместо этого последовательный код, выглядящий не сильно сложнее, чем
> аналогичный блокирующийся код), и по сравнению с подходом libpth (posix threads
> в юзерспейсе), обойтись без ручного менеджмента потоками (вместо этого ты программируешь
> в терминах отдельных задач, не парясь раскладывать эти задачи в кучки,
> которые потом склеивать "псевдоблокирующим" кодом в потоки, оно само так происходит
> _устраняя_ ненужную абстракцию юзерспейс потока).
Да где я был против асинков??? Наоборот, я считаю это было лучшим что случилось в ЖС.
Весь смысл сказанного мной был в том, что люди очень сильно обьюзают технологию событийного програмирования и как результат, не читаемый, тяжело сопровождаемый код, отсюда масса ЖС фрэймворков, которые рождаются как грибы и также быстро погибают, не смотря на хорошие задумки.
> Я очень рекомендую тебе взять C и на нём написать что-то подобное.
А я рекомендую - не рекомедавать, когда вас об этом не спрашивали :)
> Скажем http-сервачок, который сможет 100k соединений держать. Ты можешь при этом
> попробовать разные подходы -- epoll и main-loop руками, libpth, ... эмм...
> ну async/await не то, чтоб нельзя на C, но их бессмысленно
> реализовывать на C, с целью понять, хрен поймёшь из-за ущербств синтаксиса.
Бедный nginx... Теперь его перепишут на ноде...
> Но на C++, я думаю, можно попробовать. Фишка в том, что
Вы о чем???
> если ты это сделаешь, ты поймёшь что все эти три подхода
> работают одинаково, разница просматривается лишь на уровне высокоуровневого кода. И да,
> на всё это дело тебе может и потребуется пара мьютексов для
> организации глобальных структур, да и то только в том случае, если
> ты попытаешься утилизировать больше одного ядра.
Вы о чем??? Я не собираюсь вам ничего доказывать и писать для этого веб сервак на 100к соединений. Для это есть прекрасный nginx.
Я использую инструменты по назначению, там где нужна высокая производительность, то вы не побьете продуктивность продуктов написанных людими на соответсвующем языке и понимающих хардварь. Если нужно "we moving fast, we breaking things...", то и нода и пых и т.д. и т.п. самый подходящий инструмент.
Вы скорее всего приняли меня за фаната С/С++ коих здесь много, и ошиблись. Для меня языки, операционные системы, технологии - это просто инструменты, которые я применяю по назначению, а не по фанатизму
