forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Выпуск серверной JavaScript-платформы Node.js 15.0, opennews (ok), 23-Окт-20, (0) [смотреть все]

А почему про Deno так не клепаются новости на каждый новый релиз , zo0M (ok), 10:59 , 23-Окт-20, (1) –3 //

Потому что никому оно не нужно, vitalif (ok), 11:48 , 23-Окт-20, (11) +2 //

местных грамотеев как послушать, так вообще интернеты эти ваши непонятно зачем с, zo0M (ok), 11:50 , 23-Окт-20, (12) +18 //

Немного расширю комментарий прошлого оратора Пока в Deno не будет совместимости, НяшМяш (ok), 14:00 , 23-Окт-20, (28) +4

Вот не нужно это тут сравнивать, GO нормальный - императивный язык а не это фу , Аноним (30), 14:48 , 23-Окт-20, (30) –6

Go похож на внебрачную дочь C и непонятно чего по синтаксису Вот например, заче, НяшМяш (ok), 16:59 , 23-Окт-20, (56) +7

А как без указателей делать указатель на указатель на, например, структуру, мм , АнонимГоним (?), 18:00 , 23-Окт-20, (63)
потому что в Go копирование по значению в не к ночи помянутой Java объекты соз, анонимбр (?), 19:47 , 23-Окт-20, (73) –4
Согласен убрать указатели и заменить на ссылки, а nul реализовать через Optional, Аноним (82), 20:10 , 23-Окт-20, (82) +1
указателей нет, но ссылочные типы ведут себя практически так же постоянно надо , Jh (?), 05:27 , 24-Окт-20, (111)

Из преимуществ там только статическая типизация и компиляция в один бинарник Др, proninyaroslav (ok), 17:05 , 23-Окт-20, (59) +2

Ну, например, Rest API и прочие JSON в стандартной библиотеке , Анын (ok), 17:15 , 23-Окт-20, (60) –2

Ну это не один такой язык у котором в STD есть работа с json Да и установить та, proninyaroslav (ok), 17:34 , 23-Окт-20, (61) +3

статическая типизация помогает не писать тест на каждый чих хотя можно использо, анонимбр (?), 19:48 , 23-Окт-20, (74)
в Go есть такая шикарная особенность как goroutines, анонимбр (?), 19:49 , 23-Окт-20, (75) +2

Потому что ты их не пишешь Подсказка пиши их туда https www opennet ru announ, Аноним (34), 15:14 , 23-Окт-20, (34) +1

Что за 171 фича 187 такая , m.makhno (ok), 11:01 , 23-Окт-20, (3) –2 //

Ловит все необработанные исключения Что не понятно , Good enough (?), 12:10 , 23-Окт-20, (15) //

Возможно, я не так понял, но получается, что это ВСЕГДА неперехватываемое исключ, m.makhno (ok), 12:30 , 23-Окт-20, (17) //

Если мы делаем fsp writeFile qwe txt , aaaaaa then И не написали catch , Аноним (24), 13:25 , 23-Окт-20, (24) +1

PIZS AD, И как это жило 14 версий-то О-о-о, a (??), 18:57 , 30-Окт-20, (136)

Этот обработчик ловит необработанные исключения - например сделал throw вне блок, НяшМяш (ok), 13:53 , 23-Окт-20, (27) +2

Как это до сих пор не переименовали , Неиллюзорная Машина Локалхоста (?), 11:06 , 23-Окт-20, (4) +3 //

В BlackController , Дерьмократ (?), 19:59 , 23-Окт-20, (78)
А зачем переименовывать pro-choiceров в США не травят , Аноним (102), 23:21 , 23-Окт-20, (102) //

Уже забыл, как Столмана за abortion joke травили , GNU Аноним (?), 08:33 , 24-Окт-20, (113)

Это же кошмар , Страшно (?), 11:13 , 23-Окт-20, (5) –1 //

к асинхронному исполнению еще привыкнуть можно, но у ноды есть такие вот риски1 , Cradle (?), 11:35 , 23-Окт-20, (9) //

хз, по моим наблюдениям память хорошо подбирает, по крайней мере по сравнению с , vitalif (ok), 12:01 , 23-Окт-20, (14) +2
да, память кушать любит но не сильно больше, чем руби какой-нибудь, Аноним (21), 12:33 , 23-Окт-20, (21)
Вот это непонятно В каких случаях замыкание получается легче ожидаемого , Q2W (?), 13:33 , 23-Окт-20, (26) +2 //

если в асинхронном обработчике использовать переменную из контекста вызывающей ф, Cradle (?), 15:07 , 23-Окт-20, (31) –2

пардон, из контекста создающей функции конечно, вызываться-то будет конечно в др, Cradle (?), 15:09 , 23-Окт-20, (32) +1

Кошмар Сразу видно человека, который слабо разбирается и не видит многих классн, Аноним (13), 11:50 , 23-Окт-20, (13) +2
А как надо, чтобы не страшно было Блокировать поток, в ожидании выполнения запр, Ordu (ok), 12:34 , 23-Окт-20, (22) //

IMHO, cоздать явно поток, инициализировать мютекс,семафор , запустить и идти д, OpenEcho (?), 18:40 , 23-Окт-20, (65) //

Зачем тебе здесь мьютекс Мьютекс -- это медленно А если у тебя 10k таких мьюте, Ordu (ok), 19:10 , 23-Окт-20, (69)

Я про концептуальность, прозрачность кода и удобство поддержки это разве читаемы, OpenEcho (?), 20:24 , 23-Окт-20, (88) –1

Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфуска, Ordu (ok), 21:43 , 23-Окт-20, (100) +3

Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стильА , OpenEcho (?), 19:07 , 25-Окт-20, (127)

А я про обфускацию Точнее про машинно-сгенерированный код Я не знаю из чего он, Ordu (ok), 01:35 , 26-Окт-20, (129)

Гхм Вы правда знаете машины которые способны сгенировать довольно сложный лог, OpenEcho (?), 01:30 , 27-Окт-20, (130)

Вы вообще не понимаете то, о чём пишете И даже не отличаете, и не понимаете чем , Аноним (131), 02:15 , 27-Окт-20, (131)
Я не знаю как ты пришёл к выводу о том, как был сгенерирован код, поэтому я прод, Ordu (ok), 16:13 , 27-Окт-20, (134)

ждем пример асинхронности для однопоточной программы И рассказ в чем его преиму, a (??), 19:11 , 30-Окт-20, (137)

man 7 epollВ том, что обрабатывая соединения синхронно, ты будешь обрабатывать и, Ordu (ok), 20:10 , 30-Окт-20, (140)

Н-да, жалко потеряного времени Нарцицизм и демагогия самоучки из подвала, пытаю, OpenEcho (?), 17:10 , 01-Ноя-20, (142)

Реальные люди, с которыми я общаюсь, в отличие от тебя не имеют никаких проблем , Ordu (ok), 20:34 , 01-Ноя-20, (143)

Вы умрёте создавать 4 потока с мьютексами и следить за всеми из вашего же пример, Аноним (94), 20:38 , 23-Окт-20, (94)

Ну тогда я с вами с того света говорю если от 4х потоков должен был померетьЯ, OpenEcho (?), 17:34 , 25-Окт-20, (126) +1

Можно писать каллбеки без каллбечного ада и есть промизы Например code function , мяя (?), 21:31 , 23-Окт-20, (98) –1

Да можно конечно, но я про массовый хайп, а не про так надо бы, OpenEcho (?), 17:25 , 25-Окт-20, (125)

let result await db query select обработка результата , Аноним (94), 20:19 , 23-Окт-20, (86) +1

Потому что никто так не пишет Все пишут уже с использованием асинхронного синтак, Аноним (82), 20:13 , 23-Окт-20, (84) +1 //

эвейты крайне неудобны в сравнении с Rx из мира любителей колбэков, Антон (??), 20:42 , 23-Окт-20, (96) +1

Это не кошмар, это новый макакерский манямирок , Онаним (?), 20:35 , 23-Окт-20, (92) –1

Уже не развивает, гугл всех победил, Виталик (??), 11:16 , 23-Окт-20, (6) +4 //

и слава госпаду богу не нужен микрасофт с их get the facts и eee, Уася (?), 16:13 , 23-Окт-20, (50) +1 //

Слава гуголу, что всех нагнул , Аноним (115), 10:13 , 24-Окт-20, (115) +1

Вообще-то это неделю назад было , Аноним (7), 11:30 , 23-Окт-20, (7) //

Выпуск серверной JavaScript-платформы Node.js 15.0, Аноним (19), 12:31 , 23-Окт-20, (19)

А слабо вам написать целый браузер на Bash А я написалТак что вам ЖС не нужен, Аноним (8), 11:33 , 23-Окт-20, (8) –2 //

ссылку, сестра, Аноним (21), 12:31 , 23-Окт-20, (20) +2 //

echo Целый браузер , Blind Vic (ok), 13:13 , 23-Окт-20, (23) +27

Пытаюсь вспомнить что-нибудь хорошее про ноду, но пока не вспомнил, просто напиш, YetAnotherOnanym (ok), 12:15 , 23-Окт-20, (16) –3
отличный фреймворк а уж с параллельными вычислениями там просто сказка о колобк, Аноним (21), 12:30 , 23-Окт-20, (18)
Скажите, зачем оно вообще нужно Для поднятия ЧСВ бывших фронтэндеров, которых р, Javaist (?), 14:43 , 23-Окт-20, (29) +5 //

Сам не пойму Чел Когда кто то ответит ударьте , еее (?), 15:10 , 23-Окт-20, (33)
а что вы можете сказать про php ruby python Ведь не явой единной, или , Cradle (?), 15:14 , 23-Окт-20, (35) //

пхп стоит сравнивать с пёрл, яву с дотнетом, и только с жс никто не конкурирует, Аноним (38), 15:23 , 23-Окт-20, (38) //

ну почему же, нода реально теснит php и python на бэкэнде, ruby там вроде как ни, Cradle (?), 15:44 , 23-Окт-20, (41) +3

Так php с python это такие обёртки для си по факту и всё интерпетируемое будет , Аноним (38), 15:58 , 23-Окт-20, (44) +1
Теснит, угу Аж реально https w3techs com technologies details pl-phphttps , Онаним (?), 20:40 , 23-Окт-20, (95)

Кто в этот бред поверит PHP используется для лошья и legacy Его только WordPres, Аноним (131), 01:24 , 24-Окт-20, (103)

Этот бред знает любой, кто хотя бы мало-мальски плавает в отрасли Хипстеры в с, Онаним (?), 09:23 , 24-Окт-20, (114) +1

Уже не теснит Хайп по ноде уже прошел И новых проектов на ней стартует все мен, анонизмус (?), 21:01 , 25-Окт-20, (128) +2

Как человек, папу лет писавший на backend на Java, а потом на Scala пару лет Есл, Аноним (131), 15:20 , 23-Окт-20, (37) //

IMHO если выбирать javascript для реально больших проектов то всетаки рискуете н, Cradle (?), 15:35 , 23-Окт-20, (40) //

Например, какие Просто сейчас backend уже совсем не тот, что был раньше Сейчас э, Аноним (131), 15:49 , 23-Окт-20, (42)

Ну о том и речь, если тонкий клиент к aws то идеально, а если самим свое облако , Cradle (?), 16:25 , 23-Окт-20, (52)

Да, безусловно Свой cloud provider на JavaScript писать не стоит Наверное там , Аноним (131), 16:47 , 23-Окт-20, (54)

такая чушь где в этой схеме полезная нагрузка которая не сводится к одним запро, анонимбр (?), 19:57 , 23-Окт-20, (77)

Client-side render , Аноним (19), 20:08 , 23-Окт-20, (81)
Поучи наконец современный web Ты застрял в 90х, Аноним (131), 01:26 , 24-Окт-20, (104)

Лет 10 назад было модно делать браузерные ммо, так фронт с бэком пилили на жс О, Аноним (38), 15:50 , 23-Окт-20, (43) +1

Только 10 лет прошло 10 лет назад это был совсем другой язык Не было ни модулей, Аноним (131), 15:59 , 23-Окт-20, (46) +1

Ну, си за 40 лет не очень поменялся Особенно не очень за последние 20 Всё так , Аноним (38), 16:02 , 23-Окт-20, (47) +2

Ахахах, я всё понял Всё также хорош ахахах Тут бесполезно серьезно что-то обс, Аноним (131), 16:16 , 23-Окт-20, (51) +1

Ты не допёр, что это был сарказм, даже при наличии смайлика для особо одарённых , Аноним (38), 16:44 , 23-Окт-20, (53)

Ну 10 лет назад был переход между Python 2 и Python 3 Я не могу назвать это не, Аноним (131), 17:00 , 23-Окт-20, (57)

Если взять питон, то ничего заметного там не случилось в 3 Разве что добавили а, Аноним (38), 17:40 , 23-Окт-20, (62) –1

Абсолютно весь старый код внезапно работать перестал, и далеко не всегда почини, пох. (?), 18:58 , 23-Окт-20, (67) –1

Прохладная история, один и тот же код прекрасно работал в 2 и 3 одновременно По, Аноним (38), 20:37 , 23-Окт-20, (93) –1

ну конечно, не очень Возьми, скажем, исходники apache1 3, последнего, ему ни раз, пох. (?), 18:22 , 23-Окт-20, (64) –2

Лайтовый сугубо опциональный сахар Что сказать то хотел , Аноним (38), 18:48 , 23-Окт-20, (66) –1

Извиняюсь, но ваши слова звучат не убедительно , банан (?), 19:01 , 23-Окт-20, (68) +1 //

Ну, а мой путь таков C - PHP - Perl - Node JS И реально своременный JS самый, Аноним (19), 20:12 , 23-Окт-20, (83)

Здесь только про плохое говорить принято, а то заминусят Обратил внимание, что , Аноним (99), 21:42 , 23-Окт-20, (99)

Да, очень странный сайт Хотя новости самые интересные и подробные Здесь надо кр, Аноним (131), 01:33 , 24-Окт-20, (105) +2

вот поэтому я и ушел с джабы и больше не вернусь, анонимбр (?), 19:55 , 23-Окт-20, (76)
Если бы я, как архитектор, выбирал между Java Scala Python PHP и JavaScri, нуприветдима (?), 03:03 , 24-Окт-20, (107) +1 //

Я писал backend на Java и Scala для мировых компаний, таких как Parallels Inc и, Аноним (131), 04:59 , 24-Окт-20, (108) –1

Я написал несколько сотен тысяч строчек кода на JavaScript TypeScript и ни раз, Аноним (131), 05:13 , 24-Окт-20, (109)

А вы код свой запускали , банан (?), 13:13 , 24-Окт-20, (118) +1

Мне нравятся ваши потуги доказать, что js - нормальный язык Вы очень стараетесь, банан (?), 13:27 , 24-Окт-20, (119)
gt оверквотинг удален Ты либо тролль, либо лжец Не обижайся, просто 99 людей, нуприветдима (?), 17:50 , 24-Окт-20, (123) +1

Не стоит забывать что JavaScript невероятно быстрый язык для интерпретируемого О, Аноним (131), 15:35 , 23-Окт-20, (39) –1 //

Не стоит забывать, что это заслуга очень жручих и не всегда оптимальных jit с ao, Аноним (38), 15:59 , 23-Окт-20, (45) –1 //

Да Но есть и не жрущие альтернативы В React Native JavaScript компилится в байт, Аноним (131), 16:09 , 23-Окт-20, (49) +2

такая чушь сами же про C, C , Rust упомянули Google также много вложил в Go , анонимбр (?), 19:59 , 23-Окт-20, (79) //

А C имеет Garbage Collection У Go примитивный GC, не идёт ни в какое сравнение, Аноним (131), 01:41 , 24-Окт-20, (106)

Эта, та статья за 2012 год А поновее не нашлось , a (??), 19:17 , 30-Окт-20, (138)

Вы как будто с кастрюлей на голове Ваш девиз - JS быстрый, всё остальное медлен, банан (?), 14:15 , 24-Окт-20, (120) //

Ну вот и все аргументы типичного анонима с opennet Сравнивают те, кто исследуют , Аноним (131), 14:42 , 24-Окт-20, (121)

Здравствуй, программист со стаковерфлоу , банан (?), 18:00 , 24-Окт-20, (124)
What kind of Garbage Collection does Go use mark-and-sweep Asked 9 ye, a (??), 19:19 , 30-Окт-20, (139)

более менее серьёзное EtherCalc, Etherpad, OnlyOffice, Diagram Maker google-, OpenEcho (?), 19:30 , 23-Окт-20, (71) –1
Вполне неплохо Другое дело, что, процентов 95 171 бэкендов 187 в принципе , Lex (??), 10:49 , 24-Окт-20, (116) +3

1 db query select , function result обработка результата легко превра, Уася (?), 16:03 , 23-Окт-20, (48) //

Я знаю точно, асинхронное синхронно Это ж надо до такой степени доизголяться , Онаним (?), 20:56 , 23-Окт-20, (97) +1 //

До чего доизголяться , Аноним (94), 08:26 , 24-Окт-20, (112)

promisify, rex (??), 19:24 , 31-Окт-20, (141)

Так и протащили обрезанный AbortController вместо нормальных CancellationToken, Дерьмократ (?), 19:42 , 23-Окт-20, (72)
Так так так, что тут у нас, релиз тормозного говна , Аноним (101), 21:46 , 23-Окт-20, (101) –1 //

У нас говнокомментарий По коням , Аноним (131), 05:14 , 24-Окт-20, (110) +1
Не, питон и рубин пока не релизятся, Lex (??), 10:50 , 24-Окт-20, (117) +1

На самом деле libuv является надстройкой wrapper над системными вызовами epoll, Аноним (132), 10:10 , 27-Окт-20, (132) //

Возможно, имелось ввиду, что библиотека libuv выполняет те же задачи, что и libe, Аноним (132), 10:11 , 27-Окт-20, (133)

Прочитал заголовок, как Выпуск скверной JavaScript-платформы Node js 15 0 , и, Ilya Indigo (ok), 19:50 , 29-Окт-20, (135) +1

Сообщения [Сортировка по времени | RSS]

65. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от OpenEcho (?), 23-Окт-20, 18:40

>А как надо, чтобы не страшно было?
IMHO, cоздать явно поток, инициализировать мютекс,семафор..., запустить и идти делать свои дела дальше, переодически проверяя мютекс...
Оно как то укладывается лучше в башку, по сравнению с ЖС концепцией:
function(function(function(function{pook})))
Хотя, програмист он как шофер, если умеет ездить, то будет водить любую тачку,
другое дело, что крутить руль у КРАЗа посложней чем у бэхи

Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Ordu (ok), 23-Окт-20, 19:10

> IMHO, cоздать явно поток, инициализировать мютекс,семафор..., запустить и идти делать свои дела дальше, переодически проверяя мютекс...
Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя 10k таких мьютексов будет, что ты будешь делать?

Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск серверной JavaScript-платформы Node.js 15.0" –1 +/–

Сообщение от OpenEcho (?), 23-Окт-20, 20:24

> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя
> 10k таких мьютексов будет, что ты будешь делать?
Я про концептуальность, прозрачность кода и удобство поддержки.
это разве читаемый код: https://crontab.guru/index.js даже после деобфускации???
Аналогичный вопрос по поводу 10к можно адресовать и ЖС кстати (хотя, каюсь, я даже пофантазировать не могу, что же это такое, на 10к потоков...)
В конце дня любой язык закончится с jnz, jmp, а все эти абстракции придуманны только для удобства коллективного програмирования, с одной лишь целью - предотвратить пересечения имен и повысить скорость выдачи кода людьми которые понятия не имеют, как оно там под капотом все работает. И чем больше абстракций, тем больше понтов и хайпа, а в итоге старый i386 с 4мб памяти работающий под досом, считает шестеренки в разы быстрей чем современный монстр

Ответить | Правка | Наверх | Cообщить модератору

100. "Выпуск серверной JavaScript-платформы Node.js 15.0" +3 +/–

Сообщение от Ordu (ok), 23-Окт-20, 21:43

>> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя
>> 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++, я думаю, можно попробовать. Фишка в том, что если ты это сделаешь, ты поймёшь что все эти три подхода работают одинаково, разница просматривается лишь на уровне высокоуровневого кода. И да, на всё это дело тебе может и потребуется пара мьютексов для организации глобальных структур, да и то только в том случае, если ты попытаешься утилизировать больше одного ядра.

Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от OpenEcho (?), 25-Окт-20, 19:07

> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации.
> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно
> странно. Ты пробовал читать машинные коды? А после декомпиляции?
Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль
> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть
> механизмы ноды из коробки позволяют легко сделать то, что на 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...", то и нода и пых и т.д. и т.п. самый подходящий инструмент.
Вы скорее всего приняли меня за фаната С/С++ коих здесь много, и ошиблись. Для меня языки, операционные системы, технологии - это просто инструменты, которые я применяю по назначению, а не по фанатизму

Ответить | Правка | Наверх | Cообщить модератору

129. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Ordu (ok), 26-Окт-20, 01:35

>> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации.
>> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно
>> странно. Ты пробовал читать машинные коды? А после декомпиляции?
> Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль
А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из чего он был сгенерирован, гадать не решаюсь.
>> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть
>> механизмы ноды из коробки позволяют легко сделать то, что на 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.

Ответить | Правка | Наверх | Cообщить модератору

130. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от OpenEcho (?), 27-Окт-20, 01:30

> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из
> чего он был сгенерирован, гадать не решаюсь.
Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор). копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь насчет умности машин, способных генернуть подобный код.
> Стиль программирования -- это дело привычки. Это я тебе из опыта говорю
> -- мне приходилось одолевать ассемблер после C, и это было непросто.
> Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал
> голову. И несколько лет назад о rust.
Мне теперь тоже достать баклажан и помериться у кого больше ?
Ну так я начинал с более худшего, с опкодов (т.к друго еще просто не было), сидишь так и ищешь по строкам и столбцам нужный опкод из таблиц... Все еще живой, не помер... :)
> Если ты не умеешь
> мыслить о программировании в какой-то специфической концепции -- это не значит,
> что концепция плохая.
"На вкус и цвет товарища нет" :) Да нормальная концепция, просто сильно обьюзается в коде. На С-ях тоже можно не кисло так обфусцировать код, но этим страдают только дети, а в ЖС это просто какой-то популярный стиль, - написать так, чтоб потом хрен кто что понял...

> Я не понимаю, о чём ты здесь. Почему невозможно? Мне кажется, что
> ты несёшь какую-то чушь, и меня на эту мысль наводит словосочетание
> "тру ассинхронность" (грамматика сохранена): нет никакой "тру асинхронности": бывает
> просто асинхронность. Можно, наверное, асинхронность поделить на типы, по выбранному критерию
> оптимизации -- среднее время обработки запроса, максимальное время обработки запроса,
> количество обработанных запросов в секунду... Но какой из этих критериев оптимизации
> наиболее "тру"?
Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8 писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень быструю беготню тех 3-х пацанов. И как вы понимаете, даже если пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность замедлится независимо от ноды, рaста или ассемблера, т.к. если только три пацана.

> Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным
> и развивающим, я предлагаю тебе посетить образовательные ресурсы.
Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто определить уровень собеседника... и послать его... (ну да, правильно, теперь это назавыется на "образовательные ресурсы")

> Ну глянь например сюда: https://en.wikipedia.org/wiki/C10k_problem
> Тут образовательного ничего нет, но зато интересные факты есть: java на linux
> с 12 ядрами может обрабатывать 10-12 миллионов одновременных соединений. И если
> твоя "тру асинхронность" так не может, то кому она нафиг нужна?
Смотреть выше

> Я тебе вот что скажу: ныть о неразумных молодых поколениях -- это
> признак конца специалиста, который начал процесс метаморфоза в старпёра. Пора задуматься
> о пенсии.
А, ну да, страна советов... помним, помним :)
> Я не следил за темой достаточно внимательно в процессе её развития, но
> по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из
> основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то
> не изобретения, а скорее доведения до уровня массового потребления -- идея-то
> не новая, в общем.
Угу, долго что то только к этому шли

> Порекомендуй что-нибудь ещё, я люблю когда мне рекомендуют.
Ок, - lets work :)

Ответить | Правка | Наверх | Cообщить модератору

131. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Аноним (131), 27-Окт-20, 02:15

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

Ответить | Правка | Наверх | Cообщить модератору

134. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Ordu (ok), 27-Окт-20, 16:13

>> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из
>> чего он был сгенерирован, гадать не решаюсь.
> Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический
> код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор).
> копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь
> насчет умности машин, способных генернуть подобный код.
Я не знаю как ты пришёл к выводу о том, как был сгенерирован код, поэтому я продолжу придерживаться своего мнения: код был получен в результате компиляции. Минимизация -- это тоже разновидность компиляции, но я не уверен в том, что ею всё и ограничилось.
>> Стиль программирования -- это дело привычки. Это я тебе из опыта говорю
>> -- мне приходилось одолевать ассемблер после C, и это было непросто.
>> Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал
>> голову. И несколько лет назад о rust.
> Мне теперь тоже достать баклажан и помериться у кого больше ?
> Ну так я начинал с более худшего, с опкодов (т.к друго еще
> просто не было), сидишь так и ищешь по строкам и столбцам
> нужный опкод из таблиц... Все еще живой, не помер... :)
То есть я объясняю тебе то, что ты и без меня знаешь? Что ж ты тогда ноешь о стиле программирования, если и так знаешь?
>> Если ты не умеешь
>> мыслить о программировании в какой-то специфической концепции -- это не значит,
>> что концепция плохая.
> "На вкус и цвет товарища нет" :)
Это дилетантские глупости. В реальности ты используешь тот стиль, который лучше ложится на задачу, а вопрос твоих личных предпочтений никого не волнует.
> Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо
> чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все
> вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8
> писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой
> язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень
> быструю беготню тех 3-х пацанов.
Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах. Мы тут с тобой говорим "асинхронность", сокращая термины и как бы подразумевая что все понимают о чём речь, но раз ты не понимаешь, я поясню. Речь идёт об асинхронных коммуникациях. Асинхронность -- это не свойство программы, это свойство тех внешних интерфейсов, с которыми она работает. Когда у тебя даже два сокета, то каждый из них ведёт себя вне всякой связи с другим, и это называется асинхронностью, точнее сокеты называют асинхронными: они не синхронизированы между собой. Когда у тебя есть мышь и клавиатура, которые могут любым образом перетасовывать свои ивенты, типа KeyDown, MouseMove, Button1Down, KeyUp, Button2Down... то это тоже асинхронность, клавиатура и мышь не синхронизированы между собой. Вот KeyDown и KeyUp ивенты синхронизированы, второй всегда следует за первым, а KeyDown и MouseMove не синхронизированы, они асинхронны. Слово "асинхронность" применяют и к описанию программы, чтобы отразить свойство программы справляться с асинхронным вводом/выводом и не синхронизировать принудительно работу разных каналов ввода/вывода из-за своих внутренних ограничений архитектуры. Например, если ты напишешь цикл типа
while let conn = accept(socket) {
    let request = conn.read_request();
    let response = request.eval();
    conn.write_response(response);
    conn.close();
}
То тогда это синхронный код: ты будешь обрабатывать соединения в порядке поступления, и если одно из соединений зависнет почему-то, то остальные послушно будут ждать. Таким образом этот код будет синхронизировать соединения.
> И как вы понимаете, даже если
> пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность
> замедлится независимо от ноды, рaста или ассемблера, т.к. если только три
> пацана.
Там вопрос в том, когда сервер прекратит справляться с нагрузкой, то есть когда количество соединений начнёт расти, потому что у сервера не хватает ресурсов на обработку их. По мере роста количества входящих соединений в секунду происходит некоторое замедление (которое может быть несущественным: основное время на обработку может определятеся сетевыми задержками), но в какой-то момент сервер включает отказ в обслуживании. Твоя "тру-асинхронность" сможет работать с десятками, может с сотнями соединений. Если у тебя ядра будут исчисляться сотнями, то может тысячи или десятки тысяч соединений сможет обслуживать -- с уродскими задержками, но сможет. Эти ядра будут простаивать 90% времени (или 99%), в ожидании ввода/вывода, но больше твоя тру-асинхронность выжать не сможет. Если ты включишь преемптивную многозадачность в ядре, и подберёшь scheduler в ядре попроще, который за O(1) сможет переключать задачи, то на сотне ядер может ты до сотни тысяч соединений дотянешься.
Твоя тру-асинхронность нафиг никому не сдалась, даже если ты доплачивать будешь за её использование, потому что она не в состоянии утилизировать наличные возможности возможности, она приводит к тому, что существенную часть времени ядра крутят пустой цикл в ожидании ввода/вывода, или на то, чтобы пересчитывать приоритеты, переключать контексты и выполнять переходы между ring0/ring3. Вместо того, чтобы работать с данными, программа тратит процессорные такты на какую-то хрень.
>> Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным
>> и развивающим, я предлагаю тебе посетить образовательные ресурсы.
> Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто
> определить уровень собеседника...
Да у тебя на лбу написано. Если ты этого не понимаешь, то это ещё одна приписка на лбу, которая говорит что предыдущее я понял неверно и завысил твой уровень.
>> Я не следил за темой достаточно внимательно в процессе её развития, но
>> по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из
>> основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то
>> не изобретения, а скорее доведения до уровня массового потребления -- идея-то
>> не новая, в общем.
> Угу, долго что то только к этому шли
А ты думаешь такую вещь так просто изобрести? Типа сел, подумал вечерок, придумал, и через недельку выкатил синтаксис async/await и рантайм к нему, позволяющий тянуть миллион соединений?
На это надо много проб и ошибок. Мне неоднократно приходилось читать статьи вида "я тут на досуге взял lighttpd, и попробовал его перепилить вот так, и вот смотрите какие результаты..." Алан Кокс, помнится, чуть ли не в ядро запиливал какую-то фишку, чтобы потом на lighttpd показать, как она отразится на характеристиках работы.  Но тут ведь речь ещё о свойствах языка, то есть мало придумать как это сделать на уровне машинных кодов, надо ещё придумать как это записывать в языке, запилить в какой-нибудь язык подходящий синтаксис, в этом синтаксисе запилить http-сервер и померять результаты. И если получилось неочень, то выкинуть всё придумать что-нибудь ещё и повторить эпопею.
Но мало ведь того, хотелось бы иметь подход, который будет работать и с написанием гуёв -- где источников асинхронности не так много, но зато гораздо разнообразнее надо реагировать на это из-за чего код становится сложнее на пару порядков, чем любой http-сервер. Такие вещи крайне сложно запилить, если бы их было просто запилить, то их запилили бы ещё в середине XX века, до изобретения всех этих ваших C.
Если я сейчас легко могу объяснить что такое async/await, как это работает, чем там занят рантайм, как на это хорошо ложатся задачи асинхронного ввода/вывода, то это не потому что async/await придумать просто, а потому что его уже придумали за меня, и я дал себе труд посмотреть на него, и заглянуть под капот. И то, я отмечу, что если взять всё то время, которое я потратил на изучение работы с асинхронным вводом/выводом, то там получится не неделя и даже не две, там выйдет больше.

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

137. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от a (??), 30-Окт-20, 19:11

>> Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах.
ждем пример асинхронности для однопоточной программы. И рассказ в чем его преимущества.

Ответить | Правка | Наверх | Cообщить модератору

140. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Ordu (ok), 30-Окт-20, 20:10

>>> Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах.
> ждем пример асинхронности для однопоточной программы.
man 7 epoll
> И рассказ в чем его преимущества.
В том, что обрабатывая соединения синхронно, ты будешь обрабатывать их синхронно. Например, если одно из соединений окажется особо тормозным и ты два часа будешь почти ничего не делать, дожидаясь сначала пока клиент зашлёт тебе запрос, а потом дожидаясь когда он примет твой ответ, то все остальные клиенты будут вынуждены смирно ждать, пока ты закончишь с этим клиентом.

Ответить | Правка | Наверх | Cообщить модератору

142. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от OpenEcho (?), 01-Ноя-20, 17:10

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

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

143. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Ordu (ok), 01-Ноя-20, 20:34

> Ты говорил любишь советы, - мой совет слезай
> как можно скорее с интернет иглы и иди к реальным людям,
> там все совсем по другому, не как в этом уютном для
> лентяев местечке.
Реальные люди, с которыми я общаюсь, в отличие от тебя не имеют никаких проблем понять слово "асинхронность". И все идеи о том, что какой-то практически неудачные решения проблемы могут быть более правильными, чем практически удачные, я им тоже отшиб, поэтому столь дебильных обсуждений не возникает.

Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от Аноним (94), 23-Окт-20, 20:38

Вы умрёте создавать 4 потока с мьютексами и следить за всеми из вашего же примера.
В js просто создадут async функцию и будут программировать в императивном стиле если надо несколько асинхронных операций выполнить
Или объединят промисы

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

126. "Выпуск серверной JavaScript-платформы Node.js 15.0" +1 +/–

Сообщение от OpenEcho (?), 25-Окт-20, 17:34

Ну тогда я с вами с того света говорю... если от 4х потоков должен был помереть
Я не против ноды, просто акцентирую, что программеров все больше отдаляют от хардварной реальности накидывая абстрактные вещи. Как не крути, но под капотом в конце дня - это просто обыкновенный цикл с условиями

Ответить | Правка | Наверх | Cообщить модератору

98. "Выпуск серверной JavaScript-платформы Node.js 15.0" –1 +/–

Сообщение от мяя (?), 23-Окт-20, 21:31

> function(function(function(function{pook})))
Можно писать каллбеки без каллбечного ада и есть промизы.
Например

function asyncFunc(callback) {
  https.get("url", (result) => {
    result.on("data", (data) => {
      callback(data);
    }
  }.on("error", (error) => {
    console.error(error);
  });
}
function anotherFunc() {
  // blabla
  let consoleLog = 1;
  asyncFunc((result) => {
    if (consoleLog) {
      console.log(result);
    }
  });
}

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

125. "Выпуск серверной JavaScript-платформы Node.js 15.0" +/–

Сообщение от OpenEcho (?), 25-Окт-20, 17:25

Да можно конечно, но я про массовый хайп, а не про так надо бы

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	65. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от OpenEcho (?), 23-Окт-20, 18:40
	>А как надо, чтобы не страшно было? IMHO, cоздать явно поток, инициализировать мютекс,семафор..., запустить и идти делать свои дела дальше, переодически проверяя мютекс... Оно как то укладывается лучше в башку, по сравнению с ЖС концепцией: function(function(function(function{pook}))) Хотя, програмист он как шофер, если умеет ездить, то будет водить любую тачку, другое дело, что крутить руль у КРАЗа посложней чем у бэхи
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Ordu (ok), 23-Окт-20, 19:10
	> IMHO, cоздать явно поток, инициализировать мютекс,семафор..., запустить и идти делать свои дела дальше, переодически проверяя мютекс... Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя 10k таких мьютексов будет, что ты будешь делать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	88. "Выпуск серверной JavaScript-платформы Node.js 15.0"	–1 +/–
	Сообщение от OpenEcho (?), 23-Окт-20, 20:24
	> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя > 10k таких мьютексов будет, что ты будешь делать? Я про концептуальность, прозрачность кода и удобство поддержки. это разве читаемый код: https://crontab.guru/index.js даже после деобфускации??? Аналогичный вопрос по поводу 10к можно адресовать и ЖС кстати (хотя, каюсь, я даже пофантазировать не могу, что же это такое, на 10к потоков...) В конце дня любой язык закончится с jnz, jmp, а все эти абстракции придуманны только для удобства коллективного програмирования, с одной лишь целью - предотвратить пересечения имен и повысить скорость выдачи кода людьми которые понятия не имеют, как оно там под капотом все работает. И чем больше абстракций, тем больше понтов и хайпа, а в итоге старый i386 с 4мб памяти работающий под досом, считает шестеренки в разы быстрей чем современный монстр
	Ответить \| Правка \| Наверх \| Cообщить модератору


	100. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+3 +/–
	Сообщение от Ordu (ok), 23-Окт-20, 21:43
	>> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя >> 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++, я думаю, можно попробовать. Фишка в том, что если ты это сделаешь, ты поймёшь что все эти три подхода работают одинаково, разница просматривается лишь на уровне высокоуровневого кода. И да, на всё это дело тебе может и потребуется пара мьютексов для организации глобальных структур, да и то только в том случае, если ты попытаешься утилизировать больше одного ядра.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	127. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от OpenEcho (?), 25-Окт-20, 19:07
	> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации. > Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно > странно. Ты пробовал читать машинные коды? А после декомпиляции? Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль > Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть > механизмы ноды из коробки позволяют легко сделать то, что на 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...", то и нода и пых и т.д. и т.п. самый подходящий инструмент. Вы скорее всего приняли меня за фаната С/С++ коих здесь много, и ошиблись. Для меня языки, операционные системы, технологии - это просто инструменты, которые я применяю по назначению, а не по фанатизму
	Ответить \| Правка \| Наверх \| Cообщить модератору


	129. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Ordu (ok), 26-Окт-20, 01:35
	>> Мне кажется, надо спрашивать о читабельности не после деобфускации, а до обфускации. >> Этот код явно был сгенерирован алгоритмом, требовать от него читаемости довольно >> странно. Ты пробовал читать машинные коды? А после декомпиляции? > Я не про обфускацию, прогоните через любой деобфускатор и увидите модный стиль А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из чего он был сгенерирован, гадать не решаюсь. >> Всякие там ноды легко держат десятки и сотни тысяч соединений. То есть >> механизмы ноды из коробки позволяют легко сделать то, что на 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.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от OpenEcho (?), 27-Окт-20, 01:30
	> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из > чего он был сгенерирован, гадать не решаюсь. Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор). копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь насчет умности машин, способных генернуть подобный код. > Стиль программирования -- это дело привычки. Это я тебе из опыта говорю > -- мне приходилось одолевать ассемблер после C, и это было непросто. > Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал > голову. И несколько лет назад о rust. Мне теперь тоже достать баклажан и помериться у кого больше ? Ну так я начинал с более худшего, с опкодов (т.к друго еще просто не было), сидишь так и ищешь по строкам и столбцам нужный опкод из таблиц... Все еще живой, не помер... :) > Если ты не умеешь > мыслить о программировании в какой-то специфической концепции -- это не значит, > что концепция плохая. "На вкус и цвет товарища нет" :) Да нормальная концепция, просто сильно обьюзается в коде. На С-ях тоже можно не кисло так обфусцировать код, но этим страдают только дети, а в ЖС это просто какой-то популярный стиль, - написать так, чтоб потом хрен кто что понял... > Я не понимаю, о чём ты здесь. Почему невозможно? Мне кажется, что > ты несёшь какую-то чушь, и меня на эту мысль наводит словосочетание > "тру ассинхронность" (грамматика сохранена): нет никакой "тру асинхронности": бывает > просто асинхронность. Можно, наверное, асинхронность поделить на типы, по выбранному критерию > оптимизации -- среднее время обработки запроса, максимальное время обработки запроса, > количество обработанных запросов в секунду... Но какой из этих критериев оптимизации > наиболее "тру"? Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8 писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень быструю беготню тех 3-х пацанов. И как вы понимаете, даже если пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность замедлится независимо от ноды, рaста или ассемблера, т.к. если только три пацана. > Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным > и развивающим, я предлагаю тебе посетить образовательные ресурсы. Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто определить уровень собеседника... и послать его... (ну да, правильно, теперь это назавыется на "образовательные ресурсы") > Ну глянь например сюда: https://en.wikipedia.org/wiki/C10k_problem > Тут образовательного ничего нет, но зато интересные факты есть: java на linux > с 12 ядрами может обрабатывать 10-12 миллионов одновременных соединений. И если > твоя "тру асинхронность" так не может, то кому она нафиг нужна? Смотреть выше > Я тебе вот что скажу: ныть о неразумных молодых поколениях -- это > признак конца специалиста, который начал процесс метаморфоза в старпёра. Пора задуматься > о пенсии. А, ну да, страна советов... помним, помним :) > Я не следил за темой достаточно внимательно в процессе её развития, но > по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из > основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то > не изобретения, а скорее доведения до уровня массового потребления -- идея-то > не новая, в общем. Угу, долго что то только к этому шли > Порекомендуй что-нибудь ещё, я люблю когда мне рекомендуют. Ок, - lets work :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	131. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Аноним (131), 27-Окт-20, 02:15
	Вы вообще не понимаете то, о чём пишете. И даже не отличаете, и не понимаете чем отличается, асинхронность от параллелизма. Мальчики бегут параллельно - это параллелизм. Многопоточность в Linux, например, это и есть аналог асинхронности. И польза в нём огромная, даже без параллелизма (когда есть только один одноядерный процессор), потому что в большинстве случаев процессы чего-то ждут (и не выполняют полезную работу)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	134. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Ordu (ok), 27-Окт-20, 16:13
	>> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из >> чего он был сгенерирован, гадать не решаюсь. > Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический > код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор). > копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь > насчет умности машин, способных генернуть подобный код. Я не знаю как ты пришёл к выводу о том, как был сгенерирован код, поэтому я продолжу придерживаться своего мнения: код был получен в результате компиляции. Минимизация -- это тоже разновидность компиляции, но я не уверен в том, что ею всё и ограничилось. >> Стиль программирования -- это дело привычки. Это я тебе из опыта говорю >> -- мне приходилось одолевать ассемблер после C, и это было непросто. >> Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал >> голову. И несколько лет назад о rust. > Мне теперь тоже достать баклажан и помериться у кого больше ? > Ну так я начинал с более худшего, с опкодов (т.к друго еще > просто не было), сидишь так и ищешь по строкам и столбцам > нужный опкод из таблиц... Все еще живой, не помер... :) То есть я объясняю тебе то, что ты и без меня знаешь? Что ж ты тогда ноешь о стиле программирования, если и так знаешь? >> Если ты не умеешь >> мыслить о программировании в какой-то специфической концепции -- это не значит, >> что концепция плохая. > "На вкус и цвет товарища нет" :) Это дилетантские глупости. В реальности ты используешь тот стиль, который лучше ложится на задачу, а вопрос твоих личных предпочтений никого не волнует. > Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо > чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все > вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8 > писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой > язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень > быструю беготню тех 3-х пацанов. Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах. Мы тут с тобой говорим "асинхронность", сокращая термины и как бы подразумевая что все понимают о чём речь, но раз ты не понимаешь, я поясню. Речь идёт об асинхронных коммуникациях. Асинхронность -- это не свойство программы, это свойство тех внешних интерфейсов, с которыми она работает. Когда у тебя даже два сокета, то каждый из них ведёт себя вне всякой связи с другим, и это называется асинхронностью, точнее сокеты называют асинхронными: они не синхронизированы между собой. Когда у тебя есть мышь и клавиатура, которые могут любым образом перетасовывать свои ивенты, типа KeyDown, MouseMove, Button1Down, KeyUp, Button2Down... то это тоже асинхронность, клавиатура и мышь не синхронизированы между собой. Вот KeyDown и KeyUp ивенты синхронизированы, второй всегда следует за первым, а KeyDown и MouseMove не синхронизированы, они асинхронны. Слово "асинхронность" применяют и к описанию программы, чтобы отразить свойство программы справляться с асинхронным вводом/выводом и не синхронизировать принудительно работу разных каналов ввода/вывода из-за своих внутренних ограничений архитектуры. Например, если ты напишешь цикл типа while let conn = accept(socket) { let request = conn.read_request(); let response = request.eval(); conn.write_response(response); conn.close(); } То тогда это синхронный код: ты будешь обрабатывать соединения в порядке поступления, и если одно из соединений зависнет почему-то, то остальные послушно будут ждать. Таким образом этот код будет синхронизировать соединения. > И как вы понимаете, даже если > пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность > замедлится независимо от ноды, рaста или ассемблера, т.к. если только три > пацана. Там вопрос в том, когда сервер прекратит справляться с нагрузкой, то есть когда количество соединений начнёт расти, потому что у сервера не хватает ресурсов на обработку их. По мере роста количества входящих соединений в секунду происходит некоторое замедление (которое может быть несущественным: основное время на обработку может определятеся сетевыми задержками), но в какой-то момент сервер включает отказ в обслуживании. Твоя "тру-асинхронность" сможет работать с десятками, может с сотнями соединений. Если у тебя ядра будут исчисляться сотнями, то может тысячи или десятки тысяч соединений сможет обслуживать -- с уродскими задержками, но сможет. Эти ядра будут простаивать 90% времени (или 99%), в ожидании ввода/вывода, но больше твоя тру-асинхронность выжать не сможет. Если ты включишь преемптивную многозадачность в ядре, и подберёшь scheduler в ядре попроще, который за O(1) сможет переключать задачи, то на сотне ядер может ты до сотни тысяч соединений дотянешься. Твоя тру-асинхронность нафиг никому не сдалась, даже если ты доплачивать будешь за её использование, потому что она не в состоянии утилизировать наличные возможности возможности, она приводит к тому, что существенную часть времени ядра крутят пустой цикл в ожидании ввода/вывода, или на то, чтобы пересчитывать приоритеты, переключать контексты и выполнять переходы между ring0/ring3. Вместо того, чтобы работать с данными, программа тратит процессорные такты на какую-то хрень. >> Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным >> и развивающим, я предлагаю тебе посетить образовательные ресурсы. > Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто > определить уровень собеседника... Да у тебя на лбу написано. Если ты этого не понимаешь, то это ещё одна приписка на лбу, которая говорит что предыдущее я понял неверно и завысил твой уровень. >> Я не следил за темой достаточно внимательно в процессе её развития, но >> по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из >> основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то >> не изобретения, а скорее доведения до уровня массового потребления -- идея-то >> не новая, в общем. > Угу, долго что то только к этому шли А ты думаешь такую вещь так просто изобрести? Типа сел, подумал вечерок, придумал, и через недельку выкатил синтаксис async/await и рантайм к нему, позволяющий тянуть миллион соединений? На это надо много проб и ошибок. Мне неоднократно приходилось читать статьи вида "я тут на досуге взял lighttpd, и попробовал его перепилить вот так, и вот смотрите какие результаты..." Алан Кокс, помнится, чуть ли не в ядро запиливал какую-то фишку, чтобы потом на lighttpd показать, как она отразится на характеристиках работы. Но тут ведь речь ещё о свойствах языка, то есть мало придумать как это сделать на уровне машинных кодов, надо ещё придумать как это записывать в языке, запилить в какой-нибудь язык подходящий синтаксис, в этом синтаксисе запилить http-сервер и померять результаты. И если получилось неочень, то выкинуть всё придумать что-нибудь ещё и повторить эпопею. Но мало ведь того, хотелось бы иметь подход, который будет работать и с написанием гуёв -- где источников асинхронности не так много, но зато гораздо разнообразнее надо реагировать на это из-за чего код становится сложнее на пару порядков, чем любой http-сервер. Такие вещи крайне сложно запилить, если бы их было просто запилить, то их запилили бы ещё в середине XX века, до изобретения всех этих ваших C. Если я сейчас легко могу объяснить что такое async/await, как это работает, чем там занят рантайм, как на это хорошо ложатся задачи асинхронного ввода/вывода, то это не потому что async/await придумать просто, а потому что его уже придумали за меня, и я дал себе труд посмотреть на него, и заглянуть под капот. И то, я отмечу, что если взять всё то время, которое я потратил на изучение работы с асинхронным вводом/выводом, то там получится не неделя и даже не две, там выйдет больше.
	Ответить \| Правка \| К родителю #130 \| Наверх \| Cообщить модератору


	137. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от a (??), 30-Окт-20, 19:11
	>> Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах. ждем пример асинхронности для однопоточной программы. И рассказ в чем его преимущества.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	140. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Ordu (ok), 30-Окт-20, 20:10
	>>> Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах. > ждем пример асинхронности для однопоточной программы. man 7 epoll > И рассказ в чем его преимущества. В том, что обрабатывая соединения синхронно, ты будешь обрабатывать их синхронно. Например, если одно из соединений окажется особо тормозным и ты два часа будешь почти ничего не делать, дожидаясь сначала пока клиент зашлёт тебе запрос, а потом дожидаясь когда он примет твой ответ, то все остальные клиенты будут вынуждены смирно ждать, пока ты закончишь с этим клиентом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	142. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от OpenEcho (?), 01-Ноя-20, 17:10
	Н-да, жалко потеряного времени. Нарцицизм и демагогия самоучки из подвала, пытающегося оправдать свою нужность на подобных ресурсах как этот. Ты говорил любишь советы, - мой совет слезай как можно скорее с интернет иглы и иди к реальным людям, там все совсем по другому, не как в этом уютном для лентяев местечке.
	Ответить \| Правка \| К родителю #134 \| Наверх \| Cообщить модератору


	143. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Ordu (ok), 01-Ноя-20, 20:34
	> Ты говорил любишь советы, - мой совет слезай > как можно скорее с интернет иглы и иди к реальным людям, > там все совсем по другому, не как в этом уютном для > лентяев местечке. Реальные люди, с которыми я общаюсь, в отличие от тебя не имеют никаких проблем понять слово "асинхронность". И все идеи о том, что какой-то практически неудачные решения проблемы могут быть более правильными, чем практически удачные, я им тоже отшиб, поэтому столь дебильных обсуждений не возникает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	94. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от Аноним (94), 23-Окт-20, 20:38
	Вы умрёте создавать 4 потока с мьютексами и следить за всеми из вашего же примера. В js просто создадут async функцию и будут программировать в императивном стиле если надо несколько асинхронных операций выполнить Или объединят промисы
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	126. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+1 +/–
	Сообщение от OpenEcho (?), 25-Окт-20, 17:34
	Ну тогда я с вами с того света говорю... если от 4х потоков должен был помереть Я не против ноды, просто акцентирую, что программеров все больше отдаляют от хардварной реальности накидывая абстрактные вещи. Как не крути, но под капотом в конце дня - это просто обыкновенный цикл с условиями
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Выпуск серверной JavaScript-платформы Node.js 15.0"	–1 +/–
	Сообщение от мяя (?), 23-Окт-20, 21:31
	> function(function(function(function{pook}))) Можно писать каллбеки без каллбечного ада и есть промизы. Например function asyncFunc(callback) { https.get("url", (result) => { result.on("data", (data) => { callback(data); } }.on("error", (error) => { console.error(error); }); } function anotherFunc() { // blabla let consoleLog = 1; asyncFunc((result) => { if (consoleLog) { console.log(result); } }); }
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	125. "Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
	Сообщение от OpenEcho (?), 25-Окт-20, 17:25
	Да можно конечно, но я про массовый хайп, а не про так надо бы
	Ответить \| Правка \| Наверх \| Cообщить модератору