История изменений

У меня есть проблемы с поиском асинхронных либ для JS.

Как вы это сделали? За более чем 5 лет разработке на NodeJS не встречал такой проблемы. Скорее была проблема найти синхронную.

Потому что встроенная асинхронщина в JS появилась примерно одновременно с аналогичной в питоне,

Вы серьезно? ИМХО вы ничего не знаете ни про JS, ни про Python. Первый оооочень давно в себе имел систему событий/колбеков без блокировки VM, которые собственно и реализовывали асинхронщину.

а кучу безальтернативного наследия так никто и не переписал на новые механизмы.

Внезапно, большая часть современных либ идут на нативных Promise, что уже позволяет использовать их и async/await. Любые callback based либы можно «превратить» в Promise через promisify. Надо только доку почитать было.

Причем, в JS асинхронщина — это всё тот же сахар поверх синхронного языка.

JS умеет асинхронно выполнять код вызываемой функции/метода. И асинхронность в нём - не сахар, а вполне себе часть event loop виртуальной машины (мы сейчас не про полифилы ведь). Из тезиса могу сделать вывод, что вы не понимаете как работает NodeJS.

У Erlang, например, замечательная асинхронщина.

Так скажите, чем она лучше? Да и не спрашивал я где лучше, а просил описать рпимер лучшего подхода, чем события + колбеки.

Сама по себе асинхронность ничего из себя не представляет — вся разница как раз и заключается в батарейках и инструментах описания решения задачи.

Собственно я это и сказал, да. И сказал, что на Python инструментов для этого меньше.

Тоесть, асинхронность — это подход, метод, а конкретный ЯП и библиотека — это реализация асинхронного подхода.

И? В Python подход является инородным исходя из банально dao python, которую вкорячили, т.к. проще сделать это, чем оптимизировать достаточно медленный язык. В JS изначально приходилось делать инструменты для работы с асинхронщиной, т.к. в браузерах была событийная модель для вызова исполнения JS кода. Корнями асинхронщина JS уходит туда.

Ну с Go я так-то даже соглашусь, к нему у меня претензий нет.

Даже не удивлён. И всё равно, что Go сливает по производительности NodeJS в реальных приложениях для web’a (и плевать, что не для этого язык делался). Он модный зато. И нравится. А JS - фу, а не язык.

И с Elixir, как производным Erlang, я соглашусь.

Думаю, при оспаривании - вы бы ещё более глупо выглядели.

Меня возмутило наличие в этом списке ноды, которую я считаю самым бессмысленным и беспощадным решением для сервера.

Ваше мнение очень важно для сообщества. Я думаю вы - эксперт гораздо больший, чем специалисты IBM, которые почему-то втащили (вот идиоты!) в свой стек JS, а не Go или Elixir.

Если не стебать, то детский подход - считаю/не считаю. Есть задачи и инструменты. Работа программиста решать задачи эффективно. Если для решения берётся менее эффективный инструмент потому, что «не нравится», то что… такой программист.

Я плохо относился сам к NodeJS пока не начал решать задачи, в которых он на самом деле лучший.

З.Ы.: прекрасный «слух» про Golang. Его начали делать в «корпорации зла», т.к. у них была куча Python разработчиков, которым не давались высоконагруженные сервисы, а в асинхронщину на каком-нибудь более сложном языке они не могла. Поэтому Пайку заказали язык с нулевым порогом входа, чтобы под высокую нагрузку могли даже питонисты)

Май, Михайлов С - 3 дня Веха - 2ххх

Оценка + 3.14

У меня есть проблемы с поиском асинхронных либ для JS.

Как вы это сделали? За более чем 5 лет разработке на NodeJS не встречал такой проблемы. Скорее была проблема найти синхронную.

Потому что встроенная асинхронщина в JS появилась примерно одновременно с аналогичной в питоне,

Вы серьезно? ИМХО вы ничего не знаете ни про JS, ни про Python. Первый оооочень давно в себе имел систему событий/колбеков без блокировки VM, которые собственно и реализовывали асинхронщину.

а кучу безальтернативного наследия так никто и не переписал на новые механизмы.

Внезапно, большая часть современных либ идут на нативных Promise, что уже позволяет использовать их и async/await. Любые callback based либы можно «превратить» в Promise через promisify. Надо только доку почитать было.

Причем, в JS асинхронщина — это всё тот же сахар поверх синхронного языка.

JS умеет асинхронно выполнять код вызываемой функции/метода. И асинхронность в нём - не сахар, а вполне себе часть event loop виртуальной машины (мы сейчас не про полифилы ведь). Из тезиса могу сделать вывод, что вы не понимаете как работает NodeJS.

У Erlang, например, замечательная асинхронщина.

Так скажите, чем она лучше? Да и не спрашивал я где лучше, а просил описать рпимер лучшего подхода, чем события + колбеки.

Сама по себе асинхронность ничего из себя не представляет — вся разница как раз и заключается в батарейках и инструментах описания решения задачи.

Собственно я это и сказал, да. И сказал, что на Python инструментов для этого меньше.

Тоесть, асинхронность — это подход, метод, а конкретный ЯП и библиотека — это реализация асинхронного подхода.

И? В Python подход является инородным исходя из банально dao python, которую вкорячили, т.к. проще сделать это, чем оптимизировать достаточно медленный язык. В JS изначально приходилось делать инструменты для работы с асинхронщиной, т.к. в браузерах была событийная модель для вызова исполнения JS кода. Корнями асинхронщина JS уходит туда.

Ну с Go я так-то даже соглашусь, к нему у меня претензий нет.

Даже не удивлён. И всё равно, что Go сливает по производительности NodeJS в реальных приложениях для web’a (и плевать, что не для этого язык делался). Он модный зато. И нравится. А JS - фу, а не язык.

И с Elixir, как производным Erlang, я соглашусь.

Думаю, при оспаривании - вы бы ещё более глупо выглядели.

Меня возмутило наличие в этом списке ноды, которую я считаю самым бессмысленным и беспощадным решением для сервера.

Ваше мнение очень важно для сообщества. Я думаю вы - эксперт гораздо больший, чем специалисты IBM, которые почему-то втащили (вот идиоты!) в свой стек JS, а не Go или Elixir.

Если не стебать, то детский подход - считаю/не считаю. Есть задачи и инструменты. Работа программиста решать задачи эффективно. Если для решения берётся менее эффективный инструмент потому, что «не нравится», то что… такой программист.

Я плохо относился сам к NodeJS пока не начал решать задачи, в которых он на самом деле лучший.

З.Ы.: прекрасный «слух» про Golang. Его начали делать в «корпорации зла», т.к. у них была куча Python разработчиков, которым не давались высоконагруженные сервисы, а в асинхронщину на каком-нибудь более сложном языке они не могла. Поэтому Пайку заказали язык с нулевым порогом входа, чтобы под высокую нагрузку могли даже питонисты)