>> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации.
>> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно
>> странно. Ты пробовал читать машинные коды? А после декомпиляции?
> Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из чего он был сгенерирован, гадать не решаюсь.
>> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть
>> механизмы ноды из коробки позволяют легко сделать то, что на C
>> ты будешь кодить месяцами.
> А где я говорил что то плохое про ноду??? Я про концептуальный
> стиль програмирования если вы не поняли, который допускает создавать мешанину исходного
> кода по типу польской конвекции, как в Б3-34 калькуляторе.
"конвенции". Впрочем, сорри, за грамматические придирки.
Стиль программирования -- это дело привычки. Это я тебе из опыта говорю -- мне приходилось одолевать ассемблер после C, и это было непросто. Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал голову. И несколько лет назад о rust. Если ты не умеешь мыслить о программировании в какой-то специфической концепции -- это не значит, что концепция плохая.
>> Проблема 100k асинхронных соединений в том, что довольно сложно сделать это эффективно,
> Настоящих ассинхронных соединений на 100к не может быть в принципе! Даже на
> 128 коровом проце.
> По одной простой причине, что невозможно физически обеспечить ассинхронность на устройстве
> у которого не достаточно ресурсов на тру ассинхронность, а значит будет
> опять виртуальность, которя реализуется програмно
Я не понимаю, о чём ты здесь. Почему невозможно? Мне кажется, что ты несёшь какую-то чушь, и меня на эту мысль наводит словосочетание "тру ассинхронность" (грамматика сохранена): нет никакой "тру асинхронности": бывает просто асинхронность. Можно, наверное, асинхронность поделить на типы, по выбранному критерию оптимизации -- среднее время обработки запроса, максимальное время обработки запроса, количество обработанных запросов в секунду... Но какой из этих критериев оптимизации наиболее "тру"?
>> Я так навскидку затрудняюсь порекомендовать образовательных
>> ресурсов на тему,
> Да я вроде как и не просил... и вообще не собирался впадать
> в подкапотную демагогию, тем более на этом обезличином ресурсе
Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным и развивающим, я предлагаю тебе посетить образовательные ресурсы.
>> Но если ты загуглишь
>> что-нибудь в стиле 100k connections, я думаю ты найдёшь ресурсов на
>> тему.
> Я почему то и не сомневался, что все закончиться к отправке в
> гугл, хотя даже это и не надо было :)
Ты прямой ссылки ждёшь? Чтобы я выбрал для тебя ресурс, который лучше всего заточен по твой индивидуальный стиль обучения?
Ну глянь например сюда: https://en.wikipedia.org/wiki/C10k_problem
Тут образовательного ничего нет, но зато интересные факты есть: java на linux с 12 ядрами может обрабатывать 10-12 миллионов одновременных соединений. И если твоя "тру асинхронность" так не может, то кому она нафиг нужна?
>> Если требовать от каждого, чтобы он понимал бы в деталях
>> все уровни абстракции, начиная с того, на котором он пишет код,
>> и вплоть до исполнительного устройства (будь то CPU или GPU или
>> ещё что), то эти каждые будут выходить на пенсию, не успев
>> закончить учёбу. Это даже если не учитывать того, что период полураспада
>> знаний -- лет десять, наверное. В смысле, через десять лет половина
>> знаний оказывается устаревшей, ибо найдены новые лучшие способы.
> И что в этом плохого - постоянно учиться? Мы ж с вами
> не померли ? Даже наоборот - интересно.
А я не говорил, что это плохо.
> Проблема только по моему в том, что электрик должен знать как банально
> влияет сечение провода на пропускаемый ток, а сантехник знать для чего
> делается воздушка... так же и програмеры, должны знать как оно там
> работает на самом деле, вы посмотрите на молодеж, они не програмируют,
> а просто линкуют готовые фрэймворки не задумываясь об эфективности вообще и
> не вникая в сущность. Вы посмотрите на сумашествие зависимостей в ноде,
> в пыхе...
Я тебе вот что скажу: ныть о неразумных молодых поколениях -- это признак конца специалиста, который начал процесс метаморфоза в старпёра. Пора задуматься о пенсии.
> Да где я был против асинков??? Наоборот, я считаю это было лучшим
> что случилось в ЖС.
> Весь смысл сказанного мной был в том, что люди очень сильно обьюзают
> технологию событийного програмирования и как результат, не читаемый, тяжело сопровождаемый
> код, отсюда масса ЖС фрэймворков, которые рождаются как грибы и также
> быстро погибают, не смотря на хорошие задумки.
Я не следил за темой достаточно внимательно в процессе её развития, но по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то не изобретения, а скорее доведения до уровня массового потребления -- идея-то не новая, в общем.
>> Я очень рекомендую тебе взять C и на нём написать что-то подобное.
> А я рекомендую - не рекомедавать, когда вас об этом не спрашивали
> :)
Порекомендуй что-нибудь ещё, я люблю когда мне рекомендуют.
> Вы о чем??? Я не собираюсь вам ничего доказывать и писать для
> этого веб сервак на 100к соединений. Для это есть прекрасный nginx.
Ну и зря. Мне ты в любом случае ничего не докажешь, потому что тебе просто нечего доказывать, а отказываясь от столь увлекательного проекта, ты лишаешь себя возможности понять что-либо. И чуть выше ты говоришь о ценности непрерывной учёбы. Да-да. Красивые слова, за которыми пустота. Я всё ж ещё раз порекомендую тебе сделать микро-nginx, причём в нескольких разных вариантах. По-крайней мере это избавит тебя от соблазна говорить про неведомую "тру асинхронность".
> Я использую инструменты по назначению, там где нужна высокая производительность, [...]
Бла-бла-бла. Инструменты под образовательный/развивающий проект выбираются исходя из других критериев. Я рекомендую C, потому как тот позволяет видеть, что происходит на уровне процессора, выделения памяти, общения с ядром и тп. Я бы порекомендовал rust, он лучше подходит, и более того он позволяет реализовать свой собственный рантайм под async/await -- то есть иметь и красивый синтаксис, и в то же время собственноручную реализацию, но rust вызывает аллергию на опеннете, так что я всё же рекомендую C.
