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

"Выпуск серверной JavaScript-платформы Node.js 15.0"	+/–
Сообщение от opennews (ok), 23-Окт-20, 10:59
Состоялся релиз Node.js 15.0, платформы для выполнения  сетевых приложений на языке JavaScript. Node.js 15.0 относится к ветке с обычным сроком поддержки, обновления для которой  будут выпускаться до июня 2021 года. В ближайшие дни будет завершена стабилизация ветки  Node.js 14, которая получит статус LTS и будет поддерживаться до апреля 2023 года. Сопровождение прошлой LTS-ветки Node.js 12.0 продлится до апреля 2022 года, а позапрошлой LTS-ветки 10.0 до апреля 2021 года... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53950
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от zo0M (ok), 23-Окт-20, 10:59	–3 +/–
А почему про Deno так не клепаются новости на каждый новый релиз?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #34

3. Сообщение от m.makhno (ok), 23-Окт-20, 11:01	–2 +/–
> Обработчик unhandledRejection переключен на использование по умолчанию исключений "throw" ... В режиме "throw" при отсутствии явно определённого обработчика unhandledRejection генерирует неперехватываемое исключение, но если обработчик задан поведение не изменится. Что за «фича» такая?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

4. Сообщение от Неиллюзорная Машина Локалхоста (?), 23-Окт-20, 11:06	+3 +/–
> AbortController Как это до сих пор не переименовали?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78, #102

5. Сообщение от Страшно (?), 23-Окт-20, 11:13	–1 +/–
>код трансформируется в "db.query("select..", function (result) {обработка результата});", при котором управление мгновенно перейдёт к дальнейшему коду Это же кошмар!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #13, #22, #84, #92

6. Сообщение от Виталик (??), 23-Окт-20, 11:16	+4 +/–
>дополнительно Microsoft развивает вариант Node.js с движком Chakra-Core). Уже не развивает, гугл всех победил
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

7. Сообщение от Аноним (7), 23-Окт-20, 11:30	+/–
Вообще-то это неделю назад было.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

8. Сообщение от Аноним (8), 23-Окт-20, 11:33	–2 +/–
А слабо вам написать целый браузер на Bash? А я написал Так что вам ЖС не нужен
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20

9. Сообщение от Cradle (?), 23-Окт-20, 11:35	+/–
к асинхронному исполнению еще привыкнуть можно, но у ноды есть такие вот риски 1) в яваскрипте вы можете очень легко сделать замыкание, тогда на каждый вызов обработчика для каждой записи она будет резервировать неожиданно много памяти, 2) у V8 очень ленивый сборщик мусора, поэтому разгребать он начнет через какое-то время после того как весь запрос обработается В результате может очень легко случиться что запрос на порядка 100к записей может запросто сожрать все ваши гигабайты оперативки, при том что на тестах вы ничего такого не замечали, обьемы-то меньше были
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #14, #21, #26

11. Сообщение от vitalif (ok), 23-Окт-20, 11:48	+2 +/–
Потому что никому оно не нужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12

12. Сообщение от zo0M (ok), 23-Окт-20, 11:50	+18 +/–
местных грамотеев как послушать, так вообще интернеты эти ваши непонятно зачем существуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #28

13. Сообщение от Аноним (13), 23-Окт-20, 11:50	+2 +/–
Кошмар? Сразу видно человека, который слабо разбирается и не видит многих классных фич.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

14. Сообщение от vitalif (ok), 23-Окт-20, 12:01	+2 +/–
хз, по моим наблюдениям память хорошо подбирает, по крайней мере по сравнению с явой. яве допустим дали 10 гб - она такая оооо гуляем!!! а нода отдаёт быстро обратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

15. Сообщение от Good enough (?), 23-Окт-20, 12:10	+/–
Ловит все необработанные исключения. Что не понятно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #17

16. Сообщение от YetAnotherOnanym (ok), 23-Окт-20, 12:15	–3 +/–
> код трансформируется в "db.query("select..", function (result) {обработка результата});", при котором управление мгновенно перейдёт к дальнейшему коду, а результат запроса будет обработан по мере поступления данных Пытаюсь вспомнить что-нибудь хорошее про ноду, но пока не вспомнил, просто напишу какой-нибудь комментарий. > Добавлена экспериментальная реализация класса AbortController А впрочем, нуевонафиг, коммент уже написан, можно уже ничего не вспоминать.
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от m.makhno (ok), 23-Окт-20, 12:30	+/–
> Что не понятно? Возможно, я не так понял, но получается, что это ВСЕГДА неперехватываемое исключение? Оно ловится каким-то особым catch? Я просто не знаю Node.js, да и JavaScript, вот и уточняю. Может, эта фича действительно интересная. А может и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #24, #27

18. Сообщение от Аноним (21), 23-Окт-20, 12:30	+/–
отличный фреймворк. а уж с параллельными вычислениями там просто сказка о колобке.
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Аноним (19), 23-Окт-20, 12:31	+/–
> 2020-10-20
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

20. Сообщение от Аноним (21), 23-Окт-20, 12:31	+2 +/–
ссылку, сестра
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #23

21. Сообщение от Аноним (21), 23-Окт-20, 12:33	+/–
да, память кушать любит. но не сильно больше, чем руби какой-нибудь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

22. Сообщение от Ordu (ok), 23-Окт-20, 12:34	+/–
А как надо, чтобы не страшно было? Блокировать поток, в ожидании выполнения запроса? Или ты о слишком многословном синтаксисе для лямбд? В смысле надо писать так, чтоб не страшно было: db.query("select..", |result| {обработка результата}); ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #65, #86

23. Сообщение от Blind Vic (ok), 23-Окт-20, 13:13	+27 +/–
echo "Целый браузер"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

24. Сообщение от Аноним (24), 23-Окт-20, 13:25	+1 +/–
Если мы делаем fsp.writeFile('qwe.txt', 'aaaaaa').then(...) И не написали .catch(...) то мы не узнаем если в файл записать не удалось. Раньше это просто молча глаталось, теперь будет выкидывать ошибку. А надо не ловить через try, а писать где надо .catch(...). В случае с async функциями и await fsp.writeFile, оно и так сгенерит эксепшен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #136

26. Сообщение от Q2W (?), 23-Окт-20, 13:33	+2 +/–
> в яваскрипте вы можете очень легко сделать замыкание Вот это непонятно. В каких случаях замыкание получается легче ожидаемого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #31

27. Сообщение от НяшМяш (ok), 23-Окт-20, 13:53	+2 +/–
Этот обработчик ловит необработанные исключения - например сделал throw вне блока try-catch. В предыдущих версиях если ты не ставил свой обработчик например так: process.on('unhandledRejection', (reason, promise) => {   console.log('Unhandled Rejection at:', promise, 'reason:', reason);   // Application specific logging, throwing an error, or other logic here }); то обработчик по-умолчанию будет просто логировать в консоль типа "ай так нельзя, в будущем будет процесс завершаться". А в новой версии вот как раз включили падение при таком событии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

28. Сообщение от НяшМяш (ok), 23-Окт-20, 14:00	+4 +/–
Немного расширю комментарий прошлого оратора. Пока в Deno не будет совместимости с существующими библиотеками для ноды (вроде бы это пилится https://deno.land/std@0.67.0/node/README.md) - он никому не нужен. Если всё равно кардинально менять платформу - то проще на голанг сбежать, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #30

29. Сообщение от Javaist (?), 23-Окт-20, 14:43	+5 +/–
Скажите, зачем оно вообще нужно? Для поднятия ЧСВ бывших фронтэндеров, которых раньше не пускали в бекэнд? Как на JavaScript можно писать что-то более менее серьёзное?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #35, #37, #39, #71, #116

30. Сообщение от Аноним (30), 23-Окт-20, 14:48	–6 +/–
Вот не нужно это тут сравнивать, GO нормальный - императивный язык а не это фу... поделие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #56, #59

31. Сообщение от Cradle (?), 23-Окт-20, 15:07	–2 +/–
если в асинхронном обработчике использовать переменную из контекста вызывающей функции, например ненароком забыть обьявить через var, а тем более когда специально нужно использовать данные от caller, если по другому их туда не передать. Просто, многие яваскрипт используют а про замыкания не знают, и если в браузерном JS не часто требуется создавать > 100k объектов сразу, то в ноде при работе с sql реально можно нарваться. При том что до какого-то предела в тестах все будет работать, потому что эта память нужна кратковременно и GC ее потом освободит быстро, а в продакшене потом вдруг начинает процесс дохнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #32

32. Сообщение от Cradle (?), 23-Окт-20, 15:09	+1 +/–
пардон, из контекста создающей функции конечно, вызываться-то будет конечно в другом месте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

33. Сообщение от еее (?), 23-Окт-20, 15:10	+/–
Сам не пойму... Чел .. Когда кто то ответит ударьте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от Аноним (34), 23-Окт-20, 15:14	+1 +/–
Потому что ты их не пишешь. Подсказка пиши их туда https://www.opennet.ru/announce_news.shtml
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

35. Сообщение от Cradle (?), 23-Окт-20, 15:14	+/–
а что вы можете сказать про php ruby python? Ведь не явой единной, или ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #38

37. Сообщение от Аноним (131), 23-Окт-20, 15:20	+/–
Как человек, папу лет писавший на backend на Java, а потом на Scala пару лет. Если бы я, как архитектор, выбирал между Java / Scala / Python / PHP и JavaScript Node.js - я бы выбрал последнее. Во-первых, JavaScript очень хороший и хорошо спроектированный язык, по сравнению с Java. Если взять TypeScript - он вообще 90% проблем JavaScript решает. Это лучший язык на котором я писал. На JavaScript код пишется в разы быстрее, чем на Java. И он значительно понятнее. Все Cloud провайдеры AWS / Google Cloud / Azure имеют поддержку Node.js и предоставляют к ней библиотеки для работы со своим облаком. Если кто-то предоставляет библиотеки поверх API - 95% что в первую очередь он поддерживает Node.js. Огромное количество кода и библиотек. Большое количество знаний можно применить в смежных областях. Java очень многословна и монструозна. Например, я использую TypeORM для SQLITE на мобильных телефонах (React Native). И эту же TypeORM можно легко использовать в Node.js. Не надо ничего учить. А я потратил большое количество времени на изучение, это большая ORM с кучей возможностей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #40, #68, #76, #107

38. Сообщение от Аноним (38), 23-Окт-20, 15:23	+/–
пхп стоит сравнивать с пёрл, яву с дотнетом, и только с жс никто не конкурирует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #41

39. Сообщение от Аноним (131), 23-Окт-20, 15:35	–1 +/–
Не стоит забывать что JavaScript невероятно быстрый язык для интерпретируемого. Он всего в 5-7 раз медленнее самого оптимизированного C / C++ / Rust. В некоторых случаях (Regexp) даже быстрее. Ни в какой другой язык столько бабла / инвестиций / талантливых инженеров не вбухивали. V8 имеет передовой State of the Art Generational Garbage Collector. Огромное количество оптимизаций по памяти и выполнению. Что-то похожее есть только в Java. Остальные языки тихо...в сторонке стоят. Про tools вообще можно ничего не говорить. Здесь вообще даже близко нет конкурентов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #45, #79, #120

40. Сообщение от Cradle (?), 23-Окт-20, 15:35	+/–
IMHO если выбирать javascript для реально больших проектов то всетаки рискуете нарожать множество костылей и велосипедов решая довольно тривиальные задачи. Другое дело что не всякий бэкэнд должен быть большим и толстым; иногда нужны простые вещи которые потом простыми и останутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #42, #43

41. Сообщение от Cradle (?), 23-Окт-20, 15:44	+3 +/–
ну почему же, нода реально теснит php и python на бэкэнде, ruby там вроде как ни пытался но изза своих косяков не смог сильно распространиться, perl так вообще с 2005-го ушел из веба и не конкурент. Так что по сфере применения js сейчас вполне со старожилами бэкенда конкурирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #44, #95, #128

42. Сообщение от Аноним (131), 23-Окт-20, 15:49	+/–
Например, какие? Просто сейчас backend уже совсем не тот, что был раньше. Сейчас это тонкий клиент к AWS /Google Cloud / Azure. Обвязка. Он stateless и чисто сетевой. Для этого Node.js подходит идеально. Масштабирование тоже давно происходит за счёт контейнеров, а не "многопоточности". https://cloud.google.com/appengine/docs/flexible. Node.js идеален для современного backend, который service oriented. Пришёл JSON -> ушёл JSON.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #52, #77

43. Сообщение от Аноним (38), 23-Окт-20, 15:50	+1 +/–
Лет 10 назад было модно делать браузерные ммо, так фронт с бэком пилили на жс. Очень топили за это, мол, унификация, проще работать, и вообще серебряная пуля. Понятно, что у ммо бэк это в общем случае обёртка над базой данных, но всё же, есть и такое, и в результате мы все оказались в сегодняшнем болоте. Лично я бы не выбрал жс ни за какие коврижки, и даже на клиенте он нужен только ради юзерскриптов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #46

44. Сообщение от Аноним (38), 23-Окт-20, 15:58	+1 +/–
Так php с python это такие обёртки для си по факту (и всё интерпетируемое будет тормозить), а жс нет. При этом у жс были проблемы с однопоточностью, у питона же однопоточность отключается при переходе в сишный код. Какая уж тут конкуренция?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

45. Сообщение от Аноним (38), 23-Окт-20, 15:59	–1 +/–
Не стоит забывать, что это заслуга очень жручих и не всегда оптимальных jit с aot.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #49

46. Сообщение от Аноним (131), 23-Окт-20, 15:59	+1 +/–
Только 10 лет прошло. 10 лет назад это был совсем другой язык. Не было ни модулей, ни пакетов, ни npm, ни библиотек, ни Node.js, ни async / await, ни Promise, ни ... ничего не было. Никаких продвинутых оптимизаций в V8. Node.js появился May 27, 2009; 11 years ago. Те им ещё никто не пользовался. 10 лет для языка - это бездна, пропасть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #47

47. Сообщение от Аноним (38), 23-Окт-20, 16:02	+2 +/–
Ну, си за 40 лет не очень поменялся. Особенно не очень за последние 20. Всё так же хорош. D:
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #51, #64

48. Сообщение от Уася (?), 23-Окт-20, 16:03	+/–
1) "db.query("select..", function (result) {обработка результата});" легко превращается в 2) "var result = await db.query("select..");" при условии если db.query умеет в промисы а не коллбеки как в примере 1)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #97, #141

49. Сообщение от Аноним (131), 23-Окт-20, 16:09	+2 +/–
Да. Но есть и не жрущие альтернативы. В React Native JavaScript компилится в байт-код, как Java. И выполняется оптимизированной Hermes VM https://hermesengine.dev. Которая заточена под мобилки, в отличие от V8. Где мало памяти и слабые процессоры. Есть и движки, заточенные под embedded вообще и internet of things. https://github.com/jerryscript-project/jerryscript Есть и для Web похожий проект https://blog.cloudflare.com/binary-ast Есть WebAssembly на крайний случай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

50. Сообщение от Уася (?), 23-Окт-20, 16:13	+1 +/–
и слава госпаду богу. не нужен микрасофт с их get the facts и eee
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #115

51. Сообщение от Аноним (131), 23-Окт-20, 16:16	+1 +/–
Ахахах, я всё понял. "Всё также хорош" ахахах. Тут бесполезно серьезно что-то обсуждать, очень специфичная публика. Вероятно приходит чисто погундеть про "про..рали все полимеры" и потроллить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #53

52. Сообщение от Cradle (?), 23-Окт-20, 16:25	+/–
Ну о том и речь, если тонкий клиент к aws то идеально, а если самим свое облако делать то уже не обязательно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #54

53. Сообщение от Аноним (38), 23-Окт-20, 16:44	+/–
Ты не допёр, что это был сарказм, даже при наличии смайлика для особо одарённых. Так что я тоже всё понял. 10 лет не такой уж и срок на самом деле. Я не припомню ни одного промышленного языка со значительными изменениями за 10 лет, едва ли тут есть значительные отличия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #57

54. Сообщение от Аноним (131), 23-Окт-20, 16:47	+/–
Да, безусловно. Свой cloud provider на JavaScript писать не стоит. Наверное там нужна максимальная производительность. Но это очень узкая ниша. Я, кстати, писал такой в Parallels. У них был свой софт для развертывания кастомного cloud provider на базе их virtuozzo контейнеров. Сам cloud provider был написан на Java. Я бы сейчас уже Rust бы взял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

56. Сообщение от НяшМяш (ok), 23-Окт-20, 16:59	+7 +/–
Go похож на внебрачную дочь C и непонятно чего по синтаксису. Вот например, зачем там нужны указатели? В Java нет, в JS их нет. Я тогда лучше на голой сяшке попишу, её хотя бы на любой утюг с компилятором вкрячить можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #63, #73, #82, #111

57. Сообщение от Аноним (131), 23-Окт-20, 17:00	+/–
Ну 10 лет назад был переход между Python 2 и Python 3. Я не могу назвать это "незначительным". Java SE 7 и Java SE 15 достаточно сильно отличаются. В Java SE 8 / 9 завесли много новых синтаксических конструкций. C++11 и C++20 сильно отличаются. Там завезли какие-то type constraints и много чего другого. Конечно для таких языков никто не ломает совместимость. Однако новый код сильно отличается от старого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #62

59. Сообщение от proninyaroslav (ok), 23-Окт-20, 17:05	+2 +/–
Из преимуществ там только статическая типизация и компиляция в один бинарник. Других преимуществ придумать сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #60, #74, #75

60. Сообщение от Анын (ok), 23-Окт-20, 17:15	–2 +/–
Ну, например, Rest API и прочие JSON в стандартной библиотеке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #61

61. Сообщение от proninyaroslav (ok), 23-Окт-20, 17:34	+3 +/–
Ну это не один такой язык у котором в STD есть работа с json. Да и установить такую библиотеку в другом языке не представляется сложным, даже если её нет в STD.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

62. Сообщение от Аноним (38), 23-Окт-20, 17:40	–1 +/–
Если взять питон, то ничего заметного там не случилось в 3. Разве что добавили асинхронную модель исполнения, но он как был однопоточным, так и остался. Что-то перетянули из 3rd-party решений. И ещё немного иного сахара, но ничего из того, что можно назвать прямо изменениями. Это что касается языка, в интерпретаторе cpython провели ряд оптимизаций и изменений с заделом на будущее. Но в основном это новый сахар, и только. Жава допустим, но там в 9 просто отломали совместимость с предыдущими. Насчёт плюсов не знаю -- я до сих пор привыкаю к 11 после 03. Вроде там модули обещали? И сахар, конечно. Но чтобы прямо так уж отличался…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #67

63. Сообщение от АнонимГоним (?), 23-Окт-20, 18:00	+/–
А как без указателей делать указатель на указатель на, например, структуру, мм? Указатели топ, если херней не страдать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

64. Сообщение от пох. (?), 23-Окт-20, 18:22	–2 +/–
> Ну, си за 40 лет не очень поменялся. ну конечно, не очень. Возьми, скажем, исходники apache1.3, последнего, ему ни разу не сорок лет - и попробуй собрать. Потом приходи сюда, поржем - сумеешь ты вообще понять, что это значить, или как. Ну, или, вот: static struct vfs_fn_pointers vfs_xattr_tdb_fns = {         .getxattr_fn = xattr_tdb_getxattr,         .fgetxattr_fn = xattr_tdb_fgetxattr,         .setxattr_fn = xattr_tdb_setxattr,         .fsetxattr_fn = xattr_tdb_fsetxattr,         .listxattr_fn = xattr_tdb_listxattr,         .flistxattr_fn = xattr_tdb_flistxattr,         .removexattr_fn = xattr_tdb_removexattr,         .fremovexattr_fn = xattr_tdb_fremovexattr,         .open_fn = xattr_tdb_open,         .mkdir_fn = xattr_tdb_mkdir,         .unlink_fn = xattr_tdb_unlink,         .rmdir_fn = xattr_tdb_rmdir,         .connect_fn = xattr_tdb_connect, }; в данном случае, конечно, "всепонятна", но это - C99, добравшийся до gcc не так чтоб безумно давно - и, главное - имеет совершенно неочевидный побочный эффект. Если ты учил его по книжке сорокалетней давности - ниразу не угадаешь, какой. Про static_assert двух перпендикулярных синтаксисов уже молчу, поскольку в общем-то dd, и всех дел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #66

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

66. Сообщение от Аноним (38), 23-Окт-20, 18:48	–1 +/–
Лайтовый сугубо опциональный сахар. Что сказать то хотел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

67. Сообщение от пох. (?), 23-Окт-20, 18:58	–1 +/–
> Если взять питон, то ничего заметного там не случилось в 3. Абсолютно. > Разве что весь старый код внезапно работать перестал, и далеко не всегда починить легко и тривиально. Поправил, не благодари. В целом все верно - если пихоновский код надо чинить, а не выбросить, значит, ты выбрал не тот инструмент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #93

68. Сообщение от банан (?), 23-Окт-20, 19:01	+1 +/–
>  Как человек, папу лет писавший на backend на Java, а потом на Scala пару лет. > Во-первых, JavaScript очень хороший и хорошо спроектированный язык, Извиняюсь, но ваши слова звучат не убедительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #83

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

71. Сообщение от OpenEcho (?), 23-Окт-20, 19:30	–1 +/–
>  Как на JavaScript можно писать что-то более менее серьёзное? более менее серьёзное: EtherCalc, Etherpad, OnlyOffice, Diagram Maker... google-maps :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

72. Сообщение от Дерьмократ (?), 23-Окт-20, 19:42	+/–
Так и протащили обрезанный AbortController вместо нормальных CancellationToken
Ответить | Правка | Наверх | Cообщить модератору

73. Сообщение от анонимбр (?), 23-Окт-20, 19:47	–4 +/–
потому что в Go копирование по значению:) в не к ночи помянутой Java объекты создаются оператором new.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

74. Сообщение от анонимбр (?), 23-Окт-20, 19:48	+/–
статическая типизация помогает не писать тест на каждый чих. хотя можно использовать TS вместо JS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

75. Сообщение от анонимбр (?), 23-Окт-20, 19:49	+2 +/–
+ в Go есть такая шикарная особенность как goroutines
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

76. Сообщение от анонимбр (?), 23-Окт-20, 19:55	+/–
вот поэтому я и ушел с джабы и больше не вернусь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

77. Сообщение от анонимбр (?), 23-Окт-20, 19:57	+/–
> Пришёл JSON -> ушёл JSON. такая чушь. где в этой схеме полезная нагрузка которая не сводится к одним запросам к БД?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #81, #104

78. Сообщение от Дерьмократ (?), 23-Окт-20, 19:59	+/–
В BlackController?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

79. Сообщение от анонимбр (?), 23-Окт-20, 19:59	+/–
> Что-то похожее есть только в Java. Остальные языки тихо...в сторонке стоят. такая чушь. сами же про C, C++, Rust упомянули:) Google также много вложил в Go на котором написаны к слову Kubernetes и Docker.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #106

81. Сообщение от Аноним (19), 23-Окт-20, 20:08	+/–
Client-side render.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

82. Сообщение от Аноним (82), 23-Окт-20, 20:10	+1 +/–
Согласен убрать указатели и заменить на ссылки, а nul реализовать через Optional<>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

83. Сообщение от Аноним (19), 23-Окт-20, 20:12	+/–
Ну, а мой путь таков C# -> PHP -> Perl -> Node.JS И реально своременный JS самый приятный из них (хотя поначалу тоже от него плевался). Но и сишарп тоже неплохо так эволюционировал за эти годы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #99

84. Сообщение от Аноним (82), 23-Окт-20, 20:13	+1 +/–
> Это же кошмар! Потому что никто так не пишет. Все пишут уже с использованием асинхронного синтакиса: const result = await db.Query('...'); Правда остались какие-то непонятне любители callback-ов приплюснутые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #96

86. Сообщение от Аноним (94), 23-Окт-20, 20:19	+1 +/–
let result = await db.query("select.."); обработка результата...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

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

92. Сообщение от Онаним (?), 23-Окт-20, 20:35	–1 +/–
Это не кошмар, это новый макакерский манямирок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

93. Сообщение от Аноним (38), 23-Окт-20, 20:37	–1 +/–
Прохладная история, один и тот же код прекрасно работал в 2 и 3 одновременно. Потом six добавили и поддерживать совместимость вообще просто стало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

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

95. Сообщение от Онаним (?), 23-Окт-20, 20:40	+/–
Теснит, угу... Аж реально. https://w3techs.com/technologies/details/pl-php https://w3techs.com/technologies/details/ws-nodejs Даже если она кого-то и теснит, то это явно не PHP, потому что он никуда не подвинулся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #103

96. Сообщение от Антон (??), 23-Окт-20, 20:42	+1 +/–
эвейты крайне неудобны в сравнении с Rx из мира любителей колбэков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

97. Сообщение от Онаним (?), 23-Окт-20, 20:56	+1 +/–
Я знаю точно, асинхронное синхронно... Это ж надо до такой степени доизголяться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #112

98. Сообщение от мяя (?), 23-Окт-20, 21:31	–1 +/–
> 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);     }   }); }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #125

99. Сообщение от Аноним (99), 23-Окт-20, 21:42	+/–
Здесь только про плохое говорить принято, а то заминусят. Обратил внимание, что количество минусов ставят больше в это время, сначала перевес был в положительную сторону, днём. Можно предположить, что в данный момент сидят глубоко несчастные одинокие люди, и им больше ннчем заняться, как гадить на других. (Я не считаюсь, т.к. в командировке)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #105

100. Сообщение от Ordu (ok), 23-Окт-20, 21:43	+3 +/–
>> Зачем тебе здесь мьютекс? Мьютекс -- это медленно. А если у тебя >> 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ообщить модератору
Родитель: #88 Ответы: #127

101. Сообщение от Аноним (101), 23-Окт-20, 21:46	–1 +/–
Так так так, что тут у нас, релиз тормозного говна.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #110, #117

102. Сообщение от Аноним (102), 23-Окт-20, 23:21	+/–
А зачем переименовывать? pro-choiceров в США не травят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #113

103. Сообщение от Аноним (131), 24-Окт-20, 01:24	+/–
Кто в этот бред поверит? PHP используется для лошья и legacy. Его только WordPress и Drupal вытягивает. Какие бл...сайты? Сайты давным давно хостятся отдельно от бэкэнда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #114

104. Сообщение от Аноним (131), 24-Окт-20, 01:26	+/–
Поучи наконец современный web. Ты застрял в 90х
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

105. Сообщение от Аноним (131), 24-Окт-20, 01:33	+2 +/–
Да, очень странный сайт. Хотя новости самые интересные и подробные. Здесь надо кричать три вещи "про веб макак", про "не нужно", "нет чтобы написать на нормальном языке C++"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

106. Сообщение от Аноним (131), 24-Окт-20, 01:41	+/–
А C++ имеет Garbage Collection? У Go примитивный GC, не идёт ни в какое сравнение с тем что есть у JavaScript. Есть статья с хорошим анализом GC у Go. Там примитивный 40летний Mark-And-Sweep.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #138

107. Сообщение от нуприветдима (?), 24-Окт-20, 03:03	+1 +/–
"Если бы я, как архитектор, выбирал между Java / Scala / Python / PHP и JavaScript Node.js - я бы выбрал последнее." - вы точно писали бэкенд? "Во-первых, JavaScript очень хороший и хорошо спроектированный язык, по сравнению с Java" - всем отделом смеялись. Ага, хорошо спроектированный на коленке за 2 недели. (погуглите wtfjs) "На JavaScript код пишется в разы быстрее, чем на Java. И он значительно понятнее." - ложь. Оно не понятнее. "Огромное количество кода и библиотек. Большое количество знаний можно применить в смежных областях" - а в других языках нет библиотек? "Java очень многословна и монструозна." - и? А если серьезно. Я писал бэк на JS, TS, C#, и хочу сказать, что писать на JS будет только идиот. На TS еще куда ни шло, но джаваскриптовая экосистема сводит все плюсы TS на нет (если речь идет о крупных проектах). Писать небольшие сервисы на TS можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #108

108. Сообщение от Аноним (131), 24-Окт-20, 04:59	–1 +/–
Я писал backend на Java и Scala для мировых компаний, таких как Parallels Inc. и Glidewell Technologies, с высокими требованиями к производительности. Да, современный JavaScript хорошо спроектированный язык. И в первую очередь благодаря архитектуре смог эволюционировать без превращения в неподдерживаемую мешанину, как C++. Java хуже во всём. Создать npm package - это создать один json  файл с названием пакета и версией и готово. В Java надо разбираться с монструозным XML maven или учится мёртвый Groovy для Gradle. Даже такая тривиальная вещь требует нетривиальных усилий и приличного количества времени. Это хорошо видно в Android. Мерзкие скрипты на сотни строк кода в которых сами Java программисты нихрена не разбираются. Коммиты в GitHub это показывают отлично. Конечно, конечно. Java насколько хороша что до сих пор приходится пробираться через src/main/java/org/company/project/наконец-то.java. Просто передовой язык 2020 года! Удобно. "Код отревьюил"? - Нет, пока только смог открыть / найти код в папках. Ревью уже на завтра отложу ;))) И через всё это приходится пробираться в GitHub и всё протыкивать в мобильном приложении. В нём есть async / await. Которого нет ни в Java, ни Scala до сих пор. Есть Promises. Есть функции как first-class citizen и higher-order functions. То, чего никогда не было в Java и появилось только в Java 8 в 2014 году с появлением lambda. Он гораздо ближе к функциональным языкам и стилю программирования, чем Java. И функциональное программирование уже современный стандарт. Даже C++ и Java приходится как-то адаптироваться и костылись новые фичи в языке. Выходит так себе. Java монструозный язык, на нём нужно писать кучу ненужного кода только потому что он создавался как упрощённый C++ (считай, для тупых). И да, удачи с NullPointerException. Была Scala, но 90% Java программистов не в состоянии её осилить из-за продвинутой системы типов и функционального программирования. Дело заглохло. Они только фабрики фабрик инстансов умеют городить. Элитарность в говнокоде. wtfjs и что там? Дай угадаю, страшилки для тех кто не осилил TypeScript и ===? В JavaScript 99% процентов ошибок - неявное преобразование типов и неожиданным образом. Всё что тебе нужно сделать - использовать === и всё. TypeScript убирает 99% болячек JavaScript используя суперпродвинутые типы и конструкции и статическому анализу кода. Тебе такого и не снилось, ты наверное вообще не знаешь что такое disjoint types и intersection types. Понимаю, такое в твой замшелый манямирок никогда не придёт. Как и null как отдельный тип. Увы и ах, но в TypeScript одна из самых передовых систем типов со статическим анализом кода. Ой,а там где я создаю JSON или объект в несколько символов тебе приходится писать сотни строчек примитивного кода? Даже не сочувствую. Ложь. JavaScript значительно понятнее. Потому что не надо пробираться через многословность Java, которая сильно отвлекает от понимания кода. В других языках программирования значительно меньше библиотек, в разы. Может быть даже на порядок. Потому что и программистов высококлассных (как и вообще программистов) значительно меньше. И JavaScript инфраструктура заточена под open source. > Я писал бэк на JS, TS То, что ты просто говнокодил на JS/TS это понятно. Но даже это их плюс. Создал файлик index.js и погнали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #109, #119, #123

109. Сообщение от Аноним (131), 24-Окт-20, 05:13	+/–
Я написал несколько сотен тысяч строчек кода на JavaScript (TypeScript) и ни разу не сталкивался с ошибками преобразований типов (пустая строка в 0 и т.п.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #118

110. Сообщение от Аноним (131), 24-Окт-20, 05:14	+1 +/–
У нас говнокомментарий! По коням!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

111. Сообщение от Jh (?), 24-Окт-20, 05:27	+/–
указателей нет, но ссылочные типы ведут себя практически так же. постоянно надо проверять на null
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

112. Сообщение от Аноним (94), 24-Окт-20, 08:26	+/–
До чего доизголяться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

113. Сообщение от GNU Аноним (?), 24-Окт-20, 08:33	+/–
Уже забыл, как Столмана за abortion joke травили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

114. Сообщение от Онаним (?), 24-Окт-20, 09:23	+1 +/–
Этот "бред" знает любой, кто хотя бы мало-мальски плавает в отрасли. Хипстеры в своих маня-мирках, естественно, мимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

115. Сообщение от Аноним (115), 24-Окт-20, 10:13	+1 +/–
Слава гуголу, что всех нагнул.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

116. Сообщение от Lex (??), 24-Окт-20, 10:49	+3 +/–
> Как на JavaScript можно писать что-то более менее серьёзное? Вполне неплохо. Другое дело, что, процентов 95% «бэкендов» в принципе не так, чтобы очень серьёзные..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

117. Сообщение от Lex (??), 24-Окт-20, 10:50	+1 +/–
Не, питон и рубин пока не релизятся
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

118. Сообщение от банан (?), 24-Окт-20, 13:13	+1 +/–
> Я написал несколько сотен тысяч строчек кода на JavaScript (TypeScript) и ни > разу не сталкивался с ошибками преобразований типов (пустая строка в 0 > и т.п.) А вы код свой запускали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

119. Сообщение от банан (?), 24-Окт-20, 13:27	+/–
Мне нравятся ваши потуги доказать, что js - нормальный язык. Вы очень стараетесь и сами верите в свои слова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

120. Сообщение от банан (?), 24-Окт-20, 14:15	+/–
> Огромное количество оптимизаций по памяти и выполнению. > Что-то похожее есть только в Java. Остальные языки тихо...в сторонке стоят. > V8 имеет передовой State of the Art Generational Garbage Collector. Вы как будто с кастрюлей на голове. Ваш девиз - JS быстрый, всё остальное медленное! Я не уверен, что вы вообще как-то разбирались в вопросе и сравнивали те же самые сборщики у разных технологий, учитывая как вы бросаетесь словами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #121

121. Сообщение от Аноним (131), 24-Окт-20, 14:42	+/–
Ну вот и все аргументы типичного анонима с opennet. Сравнивают те, кто исследуют и пишут эти самые сборщики мусора. Я лишь анализирую информацию. https://stackoverflow.com/questions/7823725/what-kind-of-gar...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #124, #139

123. Сообщение от нуприветдима (?), 24-Окт-20, 17:50	+1 +/–
>[оверквотинг удален] > Ой,а там где я создаю JSON или объект в несколько символов тебе > приходится писать сотни строчек примитивного кода? Даже не сочувствую. > Ложь. JavaScript значительно понятнее. Потому что не надо пробираться через многословность > Java, которая сильно отвлекает от понимания кода. > В других языках программирования значительно меньше библиотек, в разы. Может быть даже > на порядок. Потому что и программистов высококлассных (как и вообще программистов) > значительно меньше. И JavaScript инфраструктура заточена под open source. >> Я писал бэк на JS, TS > То, что ты просто говнокодил на JS/TS это понятно. Но даже это > их плюс. Создал файлик index.js и погнали. Ты либо тролль, либо лжец. Не обижайся, просто 99 % людей не воспринимают человека всерьез после слов "javascript - хорошо спроектированный язык"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

124. Сообщение от банан (?), 24-Окт-20, 18:00	+/–
> Сравнивают те, кто исследуют и пишут эти самые сборщики мусора. Я лишь анализирую информацию. Здравствуй, программист со стаковерфлоу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

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

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

127. Сообщение от 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ообщить модератору
Родитель: #100 Ответы: #129

128. Сообщение от анонизмус (?), 25-Окт-20, 21:01	+2 +/–
Уже не теснит. Хайп по ноде уже прошел. И новых проектов на ней стартует все меньше. Как в свое время было с руби.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

129. Сообщение от 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ообщить модератору
Родитель: #127 Ответы: #130

130. Сообщение от 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ообщить модератору
Родитель: #129 Ответы: #131, #134

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

132. Сообщение от Аноним (132), 27-Окт-20, 10:10	+/–
> Для мультиплексирования соединений используется библиотека libuv, которая является надстройкой над libev в системах Unix и над IOCP в Windows. На самом деле libuv является надстройкой (wrapper) над системными вызовами epoll, kqueue, /dev/poll и select, IOCP, а не libev.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #133

133. Сообщение от Аноним (132), 27-Окт-20, 10:11	+/–
Возможно, имелось ввиду, что библиотека libuv выполняет те же задачи, что и libev + имеет поддержку IOCP в Windows.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

134. Сообщение от 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 придумать просто, а потому что его уже придумали за меня, и я дал себе труд посмотреть на него, и заглянуть под капот. И то, я отмечу, что если взять всё то время, которое я потратил на изучение работы с асинхронным вводом/выводом, то там получится не неделя и даже не две, там выйдет больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #137, #142

135. Сообщение от Ilya Indigo (ok), 29-Окт-20, 19:50	+1 +/–
Прочитал заголовок, как "Выпуск: скверной JavaScript-платформы Node.js 15.0 ", и не нащёл ошибок.
Ответить | Правка | Наверх | Cообщить модератору

136. Сообщение от a (??), 30-Окт-20, 18:57	+/–
>> Раньше это просто молча глаталось, теперь будет выкидывать ошибку. PIZS$%$AD, И как это жило 14 версий-то? О-о-о
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

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

138. Сообщение от a (??), 30-Окт-20, 19:17	+/–
>> У Go примитивный GC, не идёт ни в какое сравнение с тем что есть у JavaScript. >> Есть статья с хорошим анализом GC у Go. Там примитивный 40летний Mark-And-Sweep. Эта, та статья за 2012 год? А поновее не нашлось?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

139. Сообщение от a (??), 30-Окт-20, 19:19	+/–
What kind of Garbage Collection does Go use? ...  mark-and-sweep ...  Asked 9 years ago
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

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

141. Сообщение от rex (??), 31-Окт-20, 19:24	+/–
promisify
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

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

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

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

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