Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 04:35
Оценка: 3 (1) -3 :))) :))) :))) :))) :))) :))) :)
Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).

https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/
const http = require('http');

const requestListener = function (req, res) {
  res.writeHead(200);
  res.end('Hello, World!');
}

const server = http.createServer(requestListener);
server.listen(8080);



P.S. Господа смайликующие, вас не затруднит пояснить, что тут смешного?

P.P.S. Запоздало привожу вариант покороче.
require('http').createServer( (req, res) => res.end('Hello, World!') ).listen(3000);

https://youtu.be/qZ5xzkEdkhg?list=WL&t=8440
Отредактировано 10.06.2020 5:38 Lazytech . Предыдущая версия . Еще …
Отредактировано 09.06.2020 5:15 Lazytech . Предыдущая версия .
Re: Для тех, кто смеется над JavaScript
От: kov_serg Россия  
Дата: 09.06.20 05:15
Оценка: 3 (1) +2
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


L>https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/

L>
const http = require('http');

L>const requestListener = function (req, res) {
L>  res.writeHead(200);
L>  res.end('Hello, World!');
L>}

L>const server = http.createServer(requestListener);
L>server.listen(8080);

L>

И что?

http://perldancer.org/
https://docs.phalcon.io/3.4/ru-ru/application-micro
https://www.ultimatepp.org/srcdoc$Skylark$Tutorial$en-us.html
https://www.php.net/manual/ru/features.commandline.webserver.php
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 05:16
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>И что?


_>http://perldancer.org/

_>https://docs.phalcon.io/3.4/ru-ru/application-micro
_>https://www.ultimatepp.org/srcdoc$Skylark$Tutorial$en-us.html
_>https://www.php.net/manual/ru/features.commandline.webserver.php

кратко != просто


Особенно порадовали ссылки на Perl и PHP.
Отредактировано 09.06.2020 5:19 Lazytech . Предыдущая версия .
Re: Для тех, кто смеется над JavaScript
От: Михaил  
Дата: 09.06.20 05:45
Оценка: +7
Здравствуйте, Lazytech, Вы писали:

L>P.S. Господа смайликующие, вас не затруднит пояснить, что тут смешного?


Для всех языков, включая даже си и си++, на сегодняшний день созданы либы, реализующие этот самый веб-сервер, ибо задача распространенная. Пользователю приходится скопипастить всего несколько строк, чтобы его завести.
Если писать с нуля, пришлось бы поднапрячься, в том числе и на джиэс.
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 05:49
Оценка:
Здравствуйте, Михaил, Вы писали:

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

М>Если писать с нуля, пришлось бы поднапрячься, в том числе и на джиэс.

Само собой, с нуля в наше время не пишут. Просто Node.js при ближайшем знакомстве оказался не таким страшным, как я предполагал. Flask для меня в каком-то смысле даже сложнее, несмотря на простой питоновский синтаксис.
Re: ну-ну...
От: Sheridan Россия  
Дата: 09.06.20 06:41
Оценка: 4 (2) +2 :))
:;while [ $? -eq 0 ];do nc -vlp 8080 -c'(r=read;e=echo;$r a b c;z=$r;while [ ${#z} -gt 2 ];do $r z;done;f=`$e $b|sed 's/[^a-z0-9_.-]//gi'`;h="HTTP/1.0";o="$h 200 OK\r\n";c="Content";if [ -z $f ];then($e $o;ls|(while $r n;do if [ -f "$n" ]; then $e "`ls -gh $n`";fi;done););elif [ -f $f ];then $e "$o$c-Type: `file -ib $f`\n$c-Length: `stat -c%s $f`";$e;cat $f;else $e -e "$h 404 Not Found\n\n404\n";fi)';done

Кто не понял
Matrix has you...
Re[3]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 06:43
Оценка: +2 :))) :))) :)
Здравствуйте, Lazytech, Вы писали:

L>Просто Node.js ...

Просто node.js — сборник говна из всех вселенных. Даже драгон не с первого раза взлетел — node_modules была тяжеловата, пришлось чистить.
Matrix has you...
Re[2]: ну-ну...
От: Lazytech Ниоткуда  
Дата: 09.06.20 06:44
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Кто не понял


Повторюсь:

кратко != просто

Re[3]: ну-ну...
От: Sheridan Россия  
Дата: 09.06.20 06:50
Оценка:
Здравствуйте, Lazytech, Вы писали:

L>Повторюсь:

L>

кратко != просто


Да я что, против, чтоли?
Matrix has you...
Re[4]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 06:51
Оценка: :))) :))) :)
Здравствуйте, Sheridan, Вы писали:

S>Просто node.js — сборник говна из всех вселенных. Даже драгон не с первого раза взлетел — node_modules была тяжеловата, пришлось чистить.


Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.

https://youtu.be/qZ5xzkEdkhg?t=680
Re[5]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 06:58
Оценка: +9
Здравствуйте, Lazytech, Вы писали:

L>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.

Да, безусловно. Для тех, кто кроме жаваскрипта ничего больше не знает.
Matrix has you...
Re: Для тех, кто смеется над JavaScript
От: fmiracle  
Дата: 09.06.20 07:39
Оценка: 3 (1) +10
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


Сделать — это громко сказано. Ты просто подключил готовую реализацию и приписал один обработчик.

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

2. Основная библиотека на node.js — это обычно асинхронная обработка на коллбэках. Отличная вещь, но посмотри, во что превратится твой код, если тебе надо не просто сделать res.end('messsage') а слазить в БД, посмотреть что было возвращено и сделать запрос в тот или другой внешний сервис, а потом еще в третий, объединить результаты и вернуть. Не забыть вернуть специальные ответы с другим статусом, если любой из перечисленных запросов вернул условный ошибочный ответ.

Оно все реализуемо, но колбэк на колбэк на колбэк от колбэка заставляет пухнуть мозг. После этого сделать аналогичную задачу на C# с тасками — и возникает ощущение "да чтобы я еще хоть раз сел за баранку этого пылесоса!? (с)". В новых редакциях JS появился async/await что дело улучшило.
Но равно таски в шарпе мощнее и удобнее, имхо.

P.S.
Я, как бы, достаточно писал на js. И под браузер писал, и под node.js приходилось. Ничего против языка не имею, но при наличии выбора предпочту делать серверную часть на .net core чем на node.js
Re: Для тех, кто смеется над JavaScript
От: Privalov  
Дата: 09.06.20 07:53
Оценка:
Здравствуйте, Lazytech, Вы писали:

L>P.S. Господа смайликующие, вас не затруднит пояснить, что тут смешного?


Попробуй при случае на нем массив чисел отсортировать.

Ну и вот это
Автор: Privalov
Дата: 23.01.20
.
Re[5]: Для тех, кто смеется над JavaScript
От: varenikAA  
Дата: 09.06.20 07:55
Оценка: +1 -1
Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, Sheridan, Вы писали:


S>>Просто node.js — сборник говна из всех вселенных. Даже драгон не с первого раза взлетел — node_modules была тяжеловата, пришлось чистить.


L>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.


А нынче? deno !!!!
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re: Для тех, кто смеется над JavaScript
От: LuciferSaratov Россия  
Дата: 09.06.20 08:02
Оценка: +1
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


Я над ним не смеюсь, я просто не хочу на нем писать.
Но рано или поздно придется, учитывая современные тенденции.
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 08:02
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Попробуй при случае на нем массив чисел отсортировать.


Я как бы в курсе, что в JS есть свои заморочки с сортировкой чисел.

P>Ну и вот это
Автор: Privalov
Дата: 23.01.20
.


И насчет этого тоже в курсе.
Re: Для тех, кто смеется над JavaScript
От: scf  
Дата: 09.06.20 08:12
Оценка: +3 -2 :))
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


Я больше скажу — nodejs для скриптописания ничем не хуже питона, может даже лучше.
Re: Для тех, кто смеется над JavaScript
От: Евгений Акиньшин grapholite.com
Дата: 09.06.20 08:20
Оценка: 5 (3) +1
Здравствуйте, Lazytech, Вы писали:


L>P.S. Господа смайликующие, вас не затруднит пояснить, что тут смешного?


Мы не смеемся, мы плачем

Автор вот, кстати, пытается исправить, чего натворил и разрабывает WebAssembly:

JavaScript, I did it in a hurry in 1995 in 10 days in May at Netscape, ...
JavaScript was a rush job. It had bones borrowed from other languages put together in a
Frankenstein body in a hurry by me.


Полное интервью:
http://softwareengineeringdaily.com/wp-content/uploads/2017/04/SEDT02-Brendan-Eich.pdf
Не шалю, никого не трогаю, починяю примус Diagrams Designer for iPad and Windows 10
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 08:29
Оценка: +2
Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Автор вот, кстати, пытается исправить, чего натворил и разрабывает WebAssembly:


ES2015+ как бы достаточно сильно отличается от того JS, что был спешно разработан 25 лет назад...
Re[6]: Для тех, кто смеется над JavaScript
От: mtnl  
Дата: 09.06.20 08:30
Оценка: 1 (1)
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Lazytech, Вы писали:


L>>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.

S>Да, безусловно. Для тех, кто кроме жаваскрипта ничего больше не знает.

Там было много историй успеха о том, как фронтендеры смогли общаться с бакендерами и это позволило прямо сильно быстро сделать то что надо было сделать сильно быстро.
Потом, конечно, истории перешли к граблям в эксплуатации, из-за которых приходилось нанимать все больше народа и переходу на Go и подобное.
Re[3]: Для тех, кто смеется над JavaScript
От: Privalov  
Дата: 09.06.20 08:42
Оценка: :)
Здравствуйте, Lazytech, Вы писали:

L>Я как бы в курсе, что в JS есть свои заморочки с сортировкой чисел.


L>И насчет этого тоже в курсе.


Это вещи бросились мне в глаза сразу, как только я взял в руки JS. А я на нем не писал ничего сложнее Hello World. И если такое лезет в самом начале, что нас ждет в глубине?
Re[3]: Для тех, кто смеется над JavaScript
От: Mihas  
Дата: 09.06.20 08:47
Оценка: 3 (1) -2
Здравствуйте, Lazytech, Вы писали:

L>И насчет этого тоже в курсе.

Про придурошный float с неожиданными значениями в 15-м знаке после запятой тоже в курсе?
Re[4]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 08:47
Оценка:
Здравствуйте, Mihas, Вы писали:

M>Про придурошный float с неожиданными значениями в 15-м знаке после запятой тоже в курсе?


Признаюсь, не в курсе.

P.S. Я так понял, речь идет об этом:

https://gist.github.com/lsloan/f8c5ab552545ee968cca

Вроде эта проблема свойственна не только JS:

https://stackoverflow.com/questions/5098558/float-vs-double-precision

https://stackoverflow.com/questions/28045787/how-many-decimal-places-does-the-primitive-float-and-double-support

Или я полез не в те дебри?
Отредактировано 09.06.2020 9:44 Lazytech . Предыдущая версия .
Re[3]: Для тех, кто смеется над JavaScript
От: kov_serg Россия  
Дата: 09.06.20 08:50
Оценка: 3 (1)
Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, kov_serg, Вы писали:


_>>И что?


_>>http://perldancer.org/

_>>https://docs.phalcon.io/3.4/ru-ru/application-micro
_>>https://www.ultimatepp.org/srcdoc$Skylark$Tutorial$en-us.html
_>>https://www.php.net/manual/ru/features.commandline.webserver.php

L>кратко != просто

Именно если хочется кратко, и просто, и надёжно, и мастабируемо, и чтобы можно было поддерживать и обновлять не оставнавливая обслуживания клиентов то вам в erlang
и никакой javascript и перл и даже c++ рядом не лежали.

L>Особенно порадовали ссылки на Perl и PHP.

Таки да на php и perl можно очень просто и коротко писать.
И да perl используется в cloud.mail.ru
Re[5]: Для тех, кто смеется над JavaScript
От: Mamut Швеция http://dmitriid.com
Дата: 09.06.20 08:55
Оценка: 2 (2)
S>>Просто node.js — сборник говна из всех вселенных. Даже драгон не с первого раза взлетел — node_modules была тяжеловата, пришлось чистить.

L>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.


Не был. Он просто был грамотно распиарен. "Web Scale Node.js" долгое время не мог осилить даже c10k challenge


dmitriid.comGitHubLinkedIn
Re[7]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 09:00
Оценка:
Здравствуйте, mtnl, Вы писали:

M>Там было много историй успеха о том, как фронтендеры смогли общаться с бакендерами и это позволило прямо сильно быстро сделать то что надо было сделать сильно быстро.


Ну когда общаешся в терминах языка, а не сущностей...
Всмысле нопример вместо "я от тебя жду json структуру с пользователем где должны быть поля А Б и верну json структуру с результатом с полями Х У" общение идёт на "Сделай объект с полями А Б, сериализуй его в меня, я в тебя верну объект с результатом"
Тогда конечно дело быстрее пойдёт.
Matrix has you...
Re[6]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 09:01
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>А нынче? deno !!!!


curl -fsSL https://deno.land/x/install/install.sh | sh

Matrix has you...
Re[7]: Для тех, кто смеется над JavaScript
От: varenikAA  
Дата: 09.06.20 09:19
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, varenikAA, Вы писали:


AA>>А нынче? deno !!!!


S>
S>curl -fsSL https://deno.land/x/install/install.sh | sh
S>

S>

Не понял посыл. 8 часов C#+WPF. Сейчас code + vanila js — full relax!!!
Попробуйте, это вкусно!
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[8]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 09:31
Оценка: +1 :))
Здравствуйте, varenikAA, Вы писали:

S>>
S>>curl -fsSL https://deno.land/x/install/install.sh | sh
S>>

S>>

AA>Не понял посыл.


Посыл очень простой "Выполните этот скриптик и поимейте гемморой впоследствии, потому что нам плевать".
Matrix has you...
Re[8]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 09:46
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну когда общаешся в терминах языка, а не сущностей...

S>Всмысле нопример вместо "я от тебя жду json структуру с пользователем где должны быть поля А Б и верну json структуру с результатом с полями Х У" общение идёт на "Сделай объект с полями А Б, сериализуй его в меня, я в тебя верну объект с результатом"
S>Тогда конечно дело быстрее пойдёт.

Про SSR (server-side rendering) слыхали, наверное?
Re[9]: Для тех, кто смеется над JavaScript
От: varenikAA  
Дата: 09.06.20 09:48
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, varenikAA, Вы писали:


S>>>
S>>>curl -fsSL https://deno.land/x/install/install.sh | sh
S>>>

S>>>

AA>>Не понял посыл.


S>Посыл очень простой "Выполните этот скриптик и поимейте гемморой впоследствии, потому что нам плевать".


Вообще то, я хоть и не сторонник js, но web разработка нынче развита возможно чуть более сильно, чем традиционные
desktop и backend технологии на java или другом энтерпрайз языке.
Однако, если хоть немного углубится в эту тему.
То, уже давно даже на чистом js есть модульность, причем без всяких этих нэймспейсов, а почти честных основанных
на файловой структуре. импортируешь в модуль только тот функционал который нужен.
gulp и webpack собирают и обезжиривают кусочки компонентов в готовый продукт.
Просто многие не знают об этом.
Ну, а гемморой так он с возрастом приходит. От неправильного питания.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[10]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 09:52
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>То, уже давно даже на чистом js есть модульность, причем без всяких этих нэймспейсов, а почти честных основанных

AA>на файловой структуре. импортируешь в модуль только тот функционал который нужен.

На днях, делая свое первое приложение на Node.js, был приятно удивлен простотой использования CommonJS (особенно если применять деструктуризацию). А в свежую версию Node вроде добавили поддержку ECMAScript Modules (пока experimental), с которыми работать еще удобнее.
Отредактировано 09.06.2020 9:53 Lazytech . Предыдущая версия .
Re[9]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 09:57
Оценка:
Здравствуйте, Lazytech, Вы писали:

L>Про SSR (server-side rendering) слыхали, наверное?

Тоже мне бином ньютона...
История такова что этотсамый ssr был изначально. Потом реакты-вуи перетащили его на клиента. Теперь возвращают обратно?
Matrix has you...
Re[10]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 09:58
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>>>Не понял посыл.

S>>Посыл очень простой "Выполните этот скриптик и поимейте гемморой впоследствии, потому что нам плевать".

AA>Вообще то, я хоть и не сторонник js, но web разработка нынче развита возможно чуть более сильно, чем традиционные

AA>desktop и backend технологии на java или другом энтерпрайз языке.
AA>Однако, если хоть немного углубится в эту тему.
AA>То, уже давно даже на чистом js есть модульность, причем без всяких этих нэймспейсов, а почти честных основанных
AA>на файловой структуре. импортируешь в модуль только тот функционал который нужен.
AA>gulp и webpack собирают и обезжиривают кусочки компонентов в готовый продукт.
AA>Просто многие не знают об этом.
AA>Ну, а гемморой так он с возрастом приходит. От неправильного питания.

Посыл так и остался непонятым.
Matrix has you...
Re[10]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 10:34
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Тоже мне бином ньютона...

S>История такова что этотсамый ssr был изначально. Потом реакты-вуи перетащили его на клиента. Теперь возвращают обратно?

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

https://www.netlify.com/blog/2016/11/22/prerendering-explained/
Re[11]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 10:41
Оценка:
Здравствуйте, Lazytech, Вы писали:

S>>Тоже мне бином ньютона...

S>>История такова что этотсамый ssr был изначально. Потом реакты-вуи перетащили его на клиента. Теперь возвращают обратно?
L>То есть одностраничные приложения никуда не уходят.
Ну то есть вместо "отрендерили -> отправили в браузер" при старом подходе
Вместо "отправили в браузер код рендера, потом шлём только данные и рендерим в браузере" при новом подходе
Имеем ещо и хипстерское "Отправили в браузер код и готовую страницу, получили state, вычислили разницу, отправили кусок готовой страницы, встроили в дум, получили state, ..."
Ну, такое себе. Как по мне так самый приемлемый вариант — первое. Для приложений — второе.
Matrix has you...
Re[12]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 10:45
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну то есть вместо "отрендерили -> отправили в браузер" при старом подходе

S>Вместо "отправили в браузер код рендера, потом шлём только данные и рендерим в браузере" при новом подходе
S>Имеем ещо и хипстерское "Отправили в браузер код и готовую страницу, получили state, вычислили разницу, отправили кусок готовой страницы, встроили в дум, получили state, ..."
S>Ну, такое себе. Как по мне так самый приемлемый вариант — первое. Для приложений — второе.

В обращении находятся миллионы бюджетных смартфонов, которые, мягко говоря, очень неспешно рендерят страницы одностраничных приложений. Наверное, в подобных случаях пререндеринг на сервере может заметно улучшить ситуацию. То есть страница будет загружаться, скажем, не 10-15 секунд, а 2-3 секунды.
Re[13]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 10:47
Оценка: +1
Здравствуйте, Lazytech, Вы писали:

L>В обращении находятся миллионы бюджетных смартфонов, которые, мягко говоря, очень неспешно рендерят страницы одностраничных приложений. Наверное, в подобных случаях пререндеринг на сервере может заметно улучшить ситуацию. То есть страница будет загружаться, скажем, не 10-15 секунд, а 2-3 секунды.

Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.
Matrix has you...
Re[5]: Для тех, кто смеется над JavaScript
От: AleksandrN Россия  
Дата: 09.06.20 11:03
Оценка:
Здравствуйте, Lazytech, Вы писали:

L>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.


Что в нём прорывного?
Re[6]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 11:57
Оценка: :)
Здравствуйте, AleksandrN, Вы писали:

AN>Что в нём прорывного?


Event loop?

https://en.wikipedia.org/wiki/Node.js#Technical_details

Node.js operates on a single-thread event loop, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections without incurring the cost of thread context switching.[69] The design of sharing a single thread among all the requests that use the observer pattern is intended for building highly concurrent applications, where any function performing I/O must use a callback. To accommodate the single-threaded event loop, Node.js uses the libuv library—which, in turn, uses a fixed-sized thread pool that handles some of the non-blocking asynchronous I/O operations.[7]

Отредактировано 09.06.2020 11:59 Lazytech . Предыдущая версия .
Re[14]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 12:00
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.


Старый подход рулит больше в классических веб-сайтах, когда пользователь не против, чтобы на каждый чих заново загружалась и перерисовывалась страница. В наше время это вынужденная мера, когда другие подходы тупо не работают.
Отредактировано 09.06.2020 12:01 Lazytech . Предыдущая версия .
Re[14]: Для тех, кто смеется над JavaScript
От: Privalov  
Дата: 09.06.20 12:25
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.


Думаю, ты слишком категоричен.
Тупой рендеринг, должен я заметить, не самая простая задача. К тому же энергоемкий. Что имеет значение на мобильных устройствах.
В старые добрые времена разработчики сайтов строго следили, чтобы размер страниц не превышал определенного лимита. Один мой приятель всегда старался уложиться в 30 К. Сегодня такого ограничения нет. Но мобильный Интернет пока еще безлимитный не у всех. И шансов исчерпать лимиты при полной перезагрузке страниц довольно много.

С другой стороны клиентские скрипты — дело тонкое. В прошлом прокете соседи — web-разработчики, говорили, что скриптом браузер положить — как два байта переслать. Браузер просто перестает реагировать на любые раздражители. Деталей я не помню. В вебе не так, чтобы совсем гуманитарий, но теоретик.

Я тоже был бы сторонником первого подхода. Мне иногда приходится забирать с некоторых сайтов определенные страницы и доставать из них данные. И бывает так, что если просто выдать запрос, то в ответ приезжает куча клиентских скриптов. Приходится тогда WebBrowser задействовать, чтобы он их отработал. А с ним мне тоже не все ясно. ТО есть оно раюотает, но есть вопросы. Говорю же — теорерик я в вебе.
Re[15]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 12:48
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Думаю, ты слишком категоричен.

P>Тупой рендеринг, должен я заметить, не самая простая задача. К тому же энергоемкий. Что имеет значение на мобильных устройствах.
P>В старые добрые времена разработчики сайтов строго следили, чтобы размер страниц не превышал определенного лимита. Один мой приятель всегда старался уложиться в 30 К. Сегодня такого ограничения нет. Но мобильный Интернет пока еще безлимитный не у всех. И шансов исчерпать лимиты при полной перезагрузке страниц довольно много.

Дело даже не в безлимитности мобильного интернета, просто пользователь может находиться в зоне неустойчивого покрытия с низкой скоростью доступа (на даче, в горах, в метро, да мало ли где).

P>С другой стороны клиентские скрипты — дело тонкое. В прошлом прокете соседи — web-разработчики, говорили, что скриптом браузер положить — как два байта переслать. Браузер просто перестает реагировать на любые раздражители. Деталей я не помню. В вебе не так, чтобы совсем гуманитарий, но теоретик.


Я даже видел такие сайты. Правда, было это несколько лет назад, адреса сайтов не помню.

P>Я тоже был бы сторонником первого подхода. Мне иногда приходится забирать с некоторых сайтов определенные страницы и доставать из них данные. И бывает так, что если просто выдать запрос, то в ответ приезжает куча клиентских скриптов. Приходится тогда WebBrowser задействовать, чтобы он их отработал. А с ним мне тоже не все ясно. ТО есть оно раюотает, но есть вопросы. Говорю же — теорерик я в вебе.


Гугловский puppeteer для Node.js рулит. Но это только на мой дилетантский взгляд, поскольку есть еще Selenium.
Re[15]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 12:50
Оценка: :)
Здравствуйте, Privalov, Вы писали:

S>>Верно, первый, "старый" подход рулит. Браузеру даже никакого кода исполнять не надо. Тупо рендерить хтмл+цсс.

P>Тупой рендеринг, должен я заметить, не самая простая задача. К тому же энергоемкий. Что имеет значение на мобильных устройствах.
И поэтому его надо заменить на рендеринг+скрипты, да.
Matrix has you...
Re[16]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 12:51
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>И поэтому его надо заменить на рендеринг+скрипты, да.


Одно другому не мешает. Надо ли говорить, что дешевле обновить часть веб-страницы, чем всю веб-страницу? Я-то думал, крутые спецы лучше меня знают об этом.
Отредактировано 09.06.2020 12:55 Lazytech . Предыдущая версия . Еще …
Отредактировано 09.06.2020 12:52 Lazytech . Предыдущая версия .
Re[7]: Для тех, кто смеется над JavaScript
От: Mamut Швеция http://dmitriid.com
Дата: 09.06.20 12:54
Оценка: 3 (1)
AN>>Что в нём прорывного?

L>Event loop?


L>https://en.wikipedia.org/wiki/Node.js#Technical_details


А что прорывного в Event Loop? Идее Event Loop наверное лет 70 скоро будет. А в случае node.js это еще достаточно ограниченная реализация, недоступная из клиентского кода. То есть I/O нода еще худо-бедно передаст в асинхронные потоки (тоже ограниченное количество), а все остальное будет болтаться в одном потоке.

L>

Node.js operates on a single-thread event loop, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections


Они смогли «десятки тысяч соединений» хорошо, если лет пять тому назад. В 2012-м, например, 10k был для них недостижимой мечтой: https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md


dmitriid.comGitHubLinkedIn
Re[8]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 09.06.20 13:00
Оценка:
Здравствуйте, Mamut, Вы писали:

M>А что прорывного в Event Loop? Идее Event Loop наверное лет 70 скоро будет. А в случае node.js это еще достаточно ограниченная реализация, недоступная из клиентского кода. То есть I/O нода еще худо-бедно передаст в асинхронные потоки (тоже ограниченное количество), а все остальное будет болтаться в одном потоке.

M>Они смогли «десятки тысяч соединений» хорошо, если лет пять тому назад. В 2012-м, например, 10k был для них недостижимой мечтой: https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md

А какие были альтернативы на момент выходы Node.js? И почему тогда серверные решения на базе Node.js стали популярными? (Извиняюсь, если задаю бестолковые вопросы. Информацию в основном черпаю из видеолекций.)
Re[9]: Для тех, кто смеется над JavaScript
От: Mamut Швеция http://dmitriid.com
Дата: 09.06.20 13:03
Оценка: 3 (1) +5
L>А какие были альтернативы на момент выходы Node.js?

Абсолютно все остальное: от C# и Java до Erlang'а, Питона и даже PHP.

L>И почему тогда серверные решения на базе Node.js стали популярными? (Извиняюсь, если задаю бестолковые вопросы. Информацию в основном черпаю из видеолекций.)


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

Ну и да, достаточно аггресивный и нечестный маркетинг тоже присутсвовал. Они в этом с MongoDB, кстати, схожи.


dmitriid.comGitHubLinkedIn
Re[17]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 09.06.20 13:25
Оценка: -1
Здравствуйте, Lazytech, Вы писали:

S>>И поэтому его надо заменить на рендеринг+скрипты, да.

L>Одно другому не мешает. Надо ли говорить, что дешевле обновить часть веб-страницы, чем всю веб-страницу? Я-то думал, крутые спецы лучше меня знают об этом.
Это можно сделать и без ноды. Скрипт буквально в десяток строк. К тому же будет ли это дешевле — вопрос спорный.
Matrix has you...
Re[6]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.06.20 14:18
Оценка: 3 (1) +1 :)
Здравствуйте, AleksandrN, Вы писали:

L>>Насколько я понимаю, Node.js в свое время был технологическим прорывом в серверных технологиях.


AN>Что в нём прорывного?


Node.js позволил изменить структуру разработки веб приложений.

1 зоны ответственности между фронтами и бакендами

Типичная разработка с .Net или Java бакендом — фронты нихрена не понимают в бакенде, бакенды думают, что понимают во фронте. бОльшая часть JS-чудовищ написана теми самыми бакенд-девелоперами. Эти товарищи могут изобрести и менеджер пакетов, и формат пакетов, и даже свой репозиторий и тд и тд.

С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.

Более того, польза от бакендов на фронте, фронтов на беке стала гораздо больше — проще разгребать мелочевку, которой пруд пруди.

2 изоморфные приложений

1. фронт — жээс
2. бек — жээс
3. апи — жээс
4. инфраструктура, автоматизация, билды — жээс
5. тесты — жээс
6. нагрузочные — жээс
7. QA тоже используют жээс

Соответсвенно, проще работать с командой. Чем меньше требуется всяких особо хитрых баззвордов, тем проще.
Отредактировано 09.06.2020 14:39 Pauel . Предыдущая версия . Еще …
Отредактировано 09.06.2020 14:20 Pauel . Предыдущая версия .
Re[6]: Для тех, кто смеется над JavaScript
От: Reset  
Дата: 09.06.20 20:01
Оценка: 1 (1)
AN>Что в нём прорывного?

Весь код асинхронный был с самого начала. Затем сделали async/await и избавились от лесенок callback'ов.
Re: Для тех, кто смеется над JavaScript
От: Pzz Россия https://github.com/alexpevzner
Дата: 10.06.20 01:33
Оценка: 3 (1) :)
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.
Re: Для тех, кто смеется над JavaScript
От: varenikAA  
Дата: 10.06.20 03:52
Оценка: 3 (1)
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


L>https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/

L>
const http = require('http');

L>const requestListener = function (req, res) {
L>  res.writeHead(200);
L>  res.end('Hello, World!');
L>}

L>const server = http.createServer(requestListener);
L>server.listen(8080);

L>

L>P.S. Господа смайликующие, вас не затруднит пояснить, что тут смешного?


Это не смешно, а даже как-то обидно, вот вам пример еще более крутой(т.к. зависимости подтянутся автоматом, в nodejs сначала надо установить руками пакет):

#!/usr/bin/env dub
/+ dub.sdl:
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
    import vibe.d;
    listenHTTP(":8080", (req, res) {
        res.writeBody("Hello, World: " ~ req.path);
    });
    runApplication();
}


Да еще и отношение используемой памяти будет космическим.
Но, так то да, прелесть js в том, что не нода, а в том что это слаботипизрованный лисп с синтаксом java(си).
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 10.06.20 04:00
Оценка:
Pzz>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.

К сожалению, у меня пока недостаточно опыта для того, чтобы сделать это, какая бы технология при этом ни использовалась. Пока что весь мой опыт с Node.js сводится к созданию одного простенького приложения, притом даже не HTTP-сервера. COM-портов там и близко не было.
Отредактировано 10.06.2020 4:01 Lazytech . Предыдущая версия .
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 10.06.20 04:11
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>Это не смешно, а даже как-то обидно, вот вам пример еще более крутой(т.к. зависимости подтянутся автоматом, в nodejs сначала надо установить руками пакет):

[skip]
AA>Да еще и отношение используемой памяти будет космическим.
AA>Но, так то да, прелесть js в том, что не нода, а в том что это слаботипизрованный лисп с синтаксом java(си).

Вспомнил про еще один нишевый ЯП, Forth. Оказывается, на нем тоже можно сделать HTTP-сервер:

https://github.com/Payphone/F-HTTP/blob/master/http.fs
Re[7]: Для тех, кто смеется над JavaScript
От: AleksandrN Россия  
Дата: 10.06.20 05:43
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.


Как API с языком связан? В любом случае, когда в системе есть несколько взаимодействующих частей, нужно сначала подумать о протоколе и форматах данных для взаимодействия и о разделении зон ответственности. Тут полезен будет подход API first. Можно для описания API через HTTP использовать инструменты типа swagger или RAML.
Re[3]: Для тех, кто смеется над JavaScript
От: Mamut Швеция http://dmitriid.com
Дата: 10.06.20 06:02
Оценка: 1 (1) +2
L>Вспомнил про еще один нишевый ЯП, Forth. Оказывается, на нем тоже можно сделать HTTP-сервер:

HTTP-сервер можно сделать на любом языке с I/O.


dmitriid.comGitHubLinkedIn
Re[2]: Для тех, кто смеется над JavaScript
От: GarryIV  
Дата: 10.06.20 06:15
Оценка: -1
Здравствуйте, scf, Вы писали:

L>>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


scf>Я больше скажу — nodejs для скриптописания ничем не хуже питона, может даже лучше.


Питон незаслуженно обласкан, на деле говно намного хуже js. Это если на всю экосистему смотреть вцелом (c pip/npm, тулами сборки, библиотекамии тд). Да и на уровне языва у питона достаточно проблем.
WBR, Igor Evgrafov
Re[9]: Для тех, кто смеется над JavaScript
От: AleksandrN Россия  
Дата: 10.06.20 06:17
Оценка: 3 (1) +2
Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, Mamut, Вы писали:


M>>А что прорывного в Event Loop? Идее Event Loop наверное лет 70 скоро будет. А в случае node.js это еще достаточно ограниченная реализация, недоступная из клиентского кода. То есть I/O нода еще худо-бедно передаст в асинхронные потоки (тоже ограниченное количество), а все остальное будет болтаться в одном потоке.

M>>Они смогли «десятки тысяч соединений» хорошо, если лет пять тому назад. В 2012-м, например, 10k был для них недостижимой мечтой: https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md

L>А какие были альтернативы на момент выходы Node.js? И почему тогда серверные решения на базе Node.js стали популярными? (Извиняюсь, если задаю бестолковые вопросы. Информацию в основном черпаю из видеолекций.)


Альтернативные инструменты для создания сервера с event loop?

Их много. Node.JS использует библиотеку libuv, написанную на C. У этой библиотеки есть обёртки на других языках.

Похожие библиотеки — libevent, libev. Тоже написаны на C и имеющие обёртки на других языках.
Ещё есть NIO в Java. В C# тоже вроде имеется что-то похожее.

Задача и инструменты для её решения появились задолго до появления Node.JS.
Популярность Node.JS, видимо, связана с тем, что удобно, когда в команде все знают один язык.
Re[2]: Для тех, кто смеется над JavaScript
От: GarryIV  
Дата: 10.06.20 06:25
Оценка:
Здравствуйте, Pzz, Вы писали:

L>>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


Pzz>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.


Можно и рельсу бензопилой пробовать пилить...
WBR, Igor Evgrafov
Re[2]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 06:42
Оценка: 1 (1)
Здравствуйте, Pzz, Вы писали:

Pzz>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.


Точно так же, как и из tcp порта. Никакой разницы.
Re[2]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 06:48
Оценка: +1
Здравствуйте, varenikAA, Вы писали:

AA>Но, так то да, прелесть js в том, что не нода, а в том что это слаботипизрованный лисп с синтаксом java(си).


Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.
Re[8]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 06:53
Оценка:
Здравствуйте, AleksandrN, Вы писали:

I>>С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.


AN>Как API с языком связан? В любом случае, когда в системе есть несколько взаимодействующих частей, нужно сначала подумать о протоколе и форматах данных для взаимодействия и о разделении зон ответственности. Тут полезен будет подход API first. Можно для описания API через HTTP использовать инструменты типа swagger или RAML.


Непосредственно. Вот ты фронтненд разработчик к примеру. Тебе надо вызвать некоторый АПИ для своей формы. Джавы ты не знаешь, код у них энтерпрайзный, по паттернам, т.е. куда ни глянь, нигде нет полной картины происходящего. АПИ не готов.
Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.

Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.
Re[9]: Для тех, кто смеется над JavaScript
От: AleksandrN Россия  
Дата: 10.06.20 08:03
Оценка: 1 (1) -1
Здравствуйте, Ikemefula, Вы писали:

I>Непосредственно. Вот ты фронтненд разработчик к примеру. Тебе надо вызвать некоторый АПИ для своей формы. Джавы ты не знаешь, код у них энтерпрайзный, по паттернам, т.е. куда ни глянь, нигде нет полной картины происходящего. АПИ не готов.


Бардак в процессах разработки.

I>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.


Требовать описания API, собрать команду для обсуждения.

По моему опыту, всегда, когда была необходимость создания API или своих сетевых протоколов, люди из разных команд совместно обсуждали, какие данные нужно передавать и в каком виде. Совместно принятое решение документировалось.

А для того, что описать что-то на сваггере или других подобных инструментах, всё равно нужно решение о том, какое должно быть API. Такие инструменты удобны тем, что есть генератор документации и генератор кода на разных языках.

I>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.


Если используется один язык везде, удобно, конечно, написать обёртку над API и использовать её во всех частях. Но завтра может потребоваться прикрутить мобильное приложение на Kotlin/Java/Swift, послезавтра — железку с прошивкой на Си. Команда может за несколько лет поменяться полностью. Поэтому — документация по API необходима.

P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая.
  Например — на Highload++2019 была пара интересных докладов на похожую тему
Заключая контракт: как осуществить хороший API для (микро)сервиса / Анна Мелехова, Владимир Лапатин (Acronis)
Почему вам нужна платформа межсервисного взаимодействия / Артемий Рябинков (Авито)
Re[16]: Для тех, кто смеется над JavaScript
От: Privalov  
Дата: 10.06.20 08:11
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>И поэтому его надо заменить на рендеринг+скрипты, да.


Но ты же сам требовал писать энергосберегающий код. Вот тут как раз можно найти разумный компромисс между задачами сервера и клиента. Уровень повыше, чем машинных команд, но задача та же.
Re[10]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 08:21
Оценка:
Здравствуйте, AleksandrN, Вы писали:

I>>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.


AN>Требовать описания API, собрать команду для обсуждения.


Ну собрал, ну обсудили, убедились что твой вариант годный. Жди, пока другие закончат свои важные дела или переключайся на другую задачу.

AN>По моему опыту, всегда, когда была необходимость создания API или своих сетевых протоколов, люди из разных команд совместно обсуждали, какие данные нужно передавать и в каком виде. Совместно принятое решение документировалось.


То есть, документирование избавит тебя от реализации?

AN>А для того, что описать что-то на сваггере или других подобных инструментах, всё равно нужно решение о том, какое должно быть API. Такие инструменты удобны тем, что есть генератор документации и генератор кода на разных языках.


Ля-ля-ля. Реализацию кто делать будет?

I>>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.


AN>Если используется один язык везде, удобно, конечно, написать обёртку над API и использовать её во всех частях. Но завтра может потребоваться прикрутить мобильное приложение на Kotlin/Java/Swift, послезавтра — железку с прошивкой на Си. Команда может за несколько лет поменяться полностью. Поэтому — документация по API необходима.


При чем здесь документирование?

AN>P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая.


Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить. Бакенды заняты. Джавы ты не знаешь. Заглушки тебя не устраивают. Что дальше?
Re[3]: Для тех, кто смеется над JavaScript
От: Pzz Россия https://github.com/alexpevzner
Дата: 10.06.20 08:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:

Pzz>>Угу. А теперь сделай HTTP-сервер на Node.js, который получает запросы не из TCP-порта, а из условного COM-порта. При этом предположим, что поддержка самого COM-порта в виде объекта, из которого можно читать и писать, у тебя уже есть. Осталось только склеить ее с HTTP-сервером.


I>Точно так же, как и из tcp порта. Никакой разницы.


И как? Я гланул на спецификацию пакета http из ноды. Что-то не нашел там места, куда можно было бы самодельный объект для ввода-вывода передать.
Re[17]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 10.06.20 08:50
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Но ты же сам требовал писать энергосберегающий код. Вот тут как раз можно найти разумный компромисс между задачами сервера и клиента. Уровень повыше, чем машинных команд, но задача та же.

Можно, бесспорно. Только нода для этого не нужна ни разу.
Matrix has you...
Re[4]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 09:01
Оценка: :))
Здравствуйте, Pzz, Вы писали:

I>>Точно так же, как и из tcp порта. Никакой разницы.


Pzz>И как? Я гланул на спецификацию пакета http из ноды. Что-то не нашел там места, куда можно было бы самодельный объект для ввода-вывода передать.


Почему ты решил, что заданная функциональность непременно должна быть доступна именно в этом модуле?
Re[11]: Для тех, кто смеется над JavaScript
От: fmiracle  
Дата: 10.06.20 09:27
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

AN>>P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая.

I>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить. Бакенды заняты. Джавы ты не знаешь. Заглушки тебя не устраивают. Что дальше?

То есть это такой случай, когда есть фронт разработчик, который хорошо понимает устройство и работу бэкенда, настолько что вполне может туда вписать адекватный код вместо бэкенд разработчиков, но при этом вообще нисколько-нисколько не знает C#/Java, который используют эти разработчики, а вот с js он бы писал там легко?

Мне почему-то кажется, что это весьма редкий случай. Чаще будет что или фронт-разработчик вообще не готов лезть в бэк, или синтаксис другого языка ему не будет сильной проблемой.
Отредактировано 10.06.2020 9:27 fmiracle . Предыдущая версия .
Re[9]: Для тех, кто смеется над JavaScript
От: fmiracle  
Дата: 10.06.20 09:32
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Непосредственно. Вот ты фронтненд разработчик к примеру. Тебе надо вызвать некоторый АПИ для своей формы. Джавы ты не знаешь, код у них энтерпрайзный, по паттернам, т.е. куда ни глянь, нигде нет полной картины происходящего. АПИ не готов.

I>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.
I>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.

Ранее было сказано, что при использовании Java основная проблема что код "по паттернам, нигде нет ясной картины". Т.е. проблема НЕ в языке а в большой системе с неочевидными взаимосвязями. Почему в случае JS картина станет понятной и очевидной? Видимо, переход на node.js предполагает и упрощение структуры backend-а, но так может его просто надо было упростить на той же Java? Или там оно оправдано, но тогда, может быть, с упрощением в node.js варианте поспешили?
Re[18]: Для тех, кто смеется над JavaScript
От: Privalov  
Дата: 10.06.20 09:42
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Можно, бесспорно. Только нода для этого не нужна ни разу.


Раз я нодой никогда не пользовался, значит, действительно не нужна.
На самом деле я даже не знаю, что это такое.
Re[12]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 11:16
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, Ikemefula, Вы писали:


AN>>>P.S. Построение хорошего API и поддержание в актуальном виде его описания, проблема распространённая.

I>>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить. Бакенды заняты. Джавы ты не знаешь. Заглушки тебя не устраивают. Что дальше?

F>То есть это такой случай, когда есть фронт разработчик, который хорошо понимает устройство и работу бэкенда, настолько что вполне может туда вписать адекватный код вместо бэкенд разработчиков, но при этом вообще нисколько-нисколько не знает C#/Java, который используют эти разработчики, а вот с js он бы писал там легко?


Выставить АПИ, который уже оговорен, это не рокет саенс.

F>Мне почему-то кажется, что это весьма редкий случай. Чаще будет что или фронт-разработчик вообще не готов лезть в бэк, или синтаксис другого языка ему не будет сильной проблемой.


Реализовывать АПИ редкий случай? Это самый частый случай. Эта работа как правило не сильно сложная, рядом с одним методом прикрутить еще один похожий.

Соответсвенно автономность как фронтов, так и бакендов увеличивается. Пофиксил свою часть — пофиксил и смежные, нет проблем. А если js-java, надо или универсальных солдат заводить, которых днем с огнем на найдешь, или трекать зависимости.
Re[10]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 11:19
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>Ранее было сказано, что при использовании Java основная проблема что код "по паттернам, нигде нет ясной картины". Т.е. проблема НЕ в языке а в большой системе с неочевидными взаимосвязями. Почему в случае JS картина станет понятной и очевидной?

>Видимо, переход на node.js предполагает и упрощение структуры backend-а, но так может его просто надо было упростить на той же Java? Или там оно оправдано, но тогда, может быть, с упрощением в node.js варианте поспешили?

Нод жээс сам по себе проще джавы. Дополнительно, можно выделить АПИ таким образом, что бы его майнтейнили как фронты, так и бакенды.
На джаве когда то было нечто похожее, когда фронт пытались писать на джава. Но эти ужасы давно канули в лету.
Re[11]: Для тех, кто смеется над JavaScript
От: Буравчик Россия  
Дата: 10.06.20 12:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Заглушки тебя не устраивают. Что дальше?


Не понял, кто мешает написать на фронтенде код-заглушку, который будет возвращать какие-то данные вместо бэкенда, для тестов.
А потом, когда бэкенд будет готов, подключить к нему уже готовый фронтенд.
Best regards, Буравчик
Re[12]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 12:25
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Не понял, кто мешает написать на фронтенде код-заглушку, который будет возвращать какие-то данные вместо бэкенда, для тестов.

Б>А потом, когда бэкенд будет готов, подключить к нему уже готовый фронтенд.

Эту самую заглушку делают не вместо бакенда, а вместе с бакендом, и находится она на стороне бакенда. Только пишет её как правило фронтендщик. АПИ, данные — ничего лишнего. Понадобилось чтото еще — не проблема, добавим сами.
И вот здесь нужно что бы фронтенд мог писать этот простой серверный код.
Писать заглушки на фронтенде смысла немного — слишком много лишней работы, поддержка только вырожденных кейсов.

На самом деле нужно стремиться к хорошему варианту — за один заход написать 100% фичи, без каких либо зависимостей, без каких либо издержек. Заглушки здесь слабо помогают — растягивается деливери, нужно трекать зависимости, переключаться на ровном месте и тд и тд.
Это от безысходности, а не какой то рокет саенс.
Re[13]: Для тех, кто смеется над JavaScript
От: Буравчик Россия  
Дата: 10.06.20 12:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Буравчик, Вы писали:


I>Эту самую заглушку делают не вместо бакенда, а вместе с бакендом, и находится она на стороне бакенда. Только пишет её как правило фронтендщик. АПИ, данные — ничего лишнего. Понадобилось чтото еще — не проблема, добавим сами.

I>И вот здесь нужно что бы фронтенд мог писать этот простой серверный код.

Зачем писать серверный код, если можно написать заглушку на фронтенде, зная API.

I>Писать заглушки на фронтенде смысла немного — слишком много лишней работы, поддержка только вырожденных кейсов.


Работы не слишком много. Не все кейсы покрываются, но это позволяет написать 80% фронтенда. Пока будешь писать и бэк уже напишут.

I>На самом деле нужно стремиться к хорошему варианту — за один заход написать 100% фичи, без каких либо зависимостей, без каких либо издержек. Заглушки здесь слабо помогают — растягивается деливери, нужно трекать зависимости, переключаться на ровном месте и тд и тд.


Идеал недостижим. Над фичей работают разные люди, кому-то из них приходится ждать других. Здесь как раз заглушки помогают.
Best regards, Буравчик
Отредактировано 10.06.2020 12:45 Буравчик . Предыдущая версия .
Re[14]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 13:37
Оценка:
Здравствуйте, Буравчик, Вы писали:

I>>Эту самую заглушку делают не вместо бакенда, а вместе с бакендом, и находится она на стороне бакенда. Только пишет её как правило фронтендщик. АПИ, данные — ничего лишнего. Понадобилось чтото еще — не проблема, добавим сами.

I>>И вот здесь нужно что бы фронтенд мог писать этот простой серверный код.

Б>Зачем писать серверный код, если можно написать заглушку на фронтенде, зная API.


Забавно — ухитряешься задать вопрос сразу перед ответом на него.

I>>Писать заглушки на фронтенде смысла немного — слишком много лишней работы, поддержка только вырожденных кейсов.


Б>Работы не слишком много. Не все кейсы покрываются, но это позволяет написать 80% фронтенда. Пока будешь писать и бэк уже напишут.


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

I>>На самом деле нужно стремиться к хорошему варианту — за один заход написать 100% фичи, без каких либо зависимостей, без каких либо издержек. Заглушки здесь слабо помогают — растягивается деливери, нужно трекать зависимости, переключаться на ровном месте и тд и тд.


Б>Идеал недостижим. Над фичей работают разные люди, кому-то из них приходится ждать других. Здесь как раз заглушки помогают.


И по твоему это повод отказываться от оптимизации разработки ? Заглушки помогают, но можно лучше. Например — размещать их на бакенде.
Re[15]: Для тех, кто смеется над JavaScript
От: Буравчик Россия  
Дата: 10.06.20 13:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я бы сказал хорошо если половина. Заглушки на бакенде стоят дешевле, позволяют реализовать почти все кейсы, особенно, если используется микросервисная архитектура.

I>И по твоему это повод отказываться от оптимизации разработки ? Заглушки помогают, но можно лучше. Например — размещать их на бакенде.

А что такое заглушка на бэкенде? Может мы про разные вещи говорим.

Ты говорил о проблеме — пока бэк не реализован, фронтендеры не могут работать.
Не пойму, в чем суть твоей "оптимизации разработки". Подгонять бэкендеров? Превращать фронтендеров в фулл-стек?

Ну если фронтендеры бэкенд писать не умеют, то пишут фронт (заглушки на фронте). Да, это дополнительная работа, но скорость доставки фич у команды возрастает.
Best regards, Буравчик
Re[16]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.06.20 13:59
Оценка:
Здравствуйте, Буравчик, Вы писали:

I>>И по твоему это повод отказываться от оптимизации разработки ? Заглушки помогают, но можно лучше. Например — размещать их на бакенде.


Б>А что такое заглушка на бэкенде? Может мы про разные вещи говорим.


То же, что и на фронте, только возможностей больше.

Б>Ты говорил о проблеме — пока бэк не реализован, фронтендеры не могут работать.


Я пишу совсем другое
http://rsdn.org/forum/flame.comp/7750660.1
Автор: Ikemefula
Дата: 09.06.20


Б>Не пойму, в чем суть твоей "оптимизации разработки". Подгонять бэкендеров? Превращать фронтендеров в фулл-стек?


Большая автономность у разработчиков, границы ответственности изменяются. Фронты частично пишут бакенд. Бакенды частично пишут фронтенд.

Чем меньше заглушек, тем лучше.

Б>Ну если фронтендеры бэкенд писать не умеют, то пишут фронт (заглушки на фронте). Да, это дополнительная работа, но скорость доставки фич у команды возрастает.


А если фронты умеют писать бек, а бакенды — фронт, то скорость доставки еще более возрастает.
Re[3]: Для тех, кто смеется над JavaScript
От: Mr.Delphist  
Дата: 11.06.20 12:07
Оценка: +2 -1
Здравствуйте, Ikemefula, Вы писали:

I>Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.


...используя зоопарк JS-технологий

Беда JS в том, что он никак не войдёт в эпоху взросления, эдакий "вечный студент". Собственно, именно то, что в итоге погубило когда-то Бейсик (хотя были весьма взрослые для того времени диалекты языка, на уровне Паскаля и Си)
Re[4]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.06.20 13:15
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

I>>Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.


MD>...используя зоопарк JS-технологий


Что за зоопарк JS-технологий?

MD>Беда JS в том, что он никак не войдёт в эпоху взросления, эдакий "вечный студент". Собственно, именно то, что в итоге погубило когда-то Бейсик (хотя были весьма взрослые для того времени диалекты языка, на уровне Паскаля и Си)


Взросление началось уже давно, как на фронтенде, так и на бакенде. Что именно тебя не устраивает?
Re[4]: Для тех, кто смеется над JavaScript
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.06.20 13:18
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Ikemefula, Вы писали:


I>>Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.


MD>...используя зоопарк JS-технологий


MD>Беда JS в том, что он никак не войдёт в эпоху взросления, эдакий "вечный студент". Собственно, именно то, что в итоге погубило когда-то Бейсик (хотя были весьма взрослые для того времени диалекты языка, на уровне Паскаля и Си)

Видмо твое знание JS осталось на уровне стандарта ES3 и IE6. Сейчас в ходу уже ES6+, Node и TypeScript.
Re[5]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 12.06.20 20:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Что за зоопарк JS-технологий?

node_modules. Ну, например.
Matrix has you...
Re[6]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.06.20 17:07
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:


I>>Что за зоопарк JS-технологий?

S>node_modules. Ну, например.

node_modules это фолдер, куда зависимости складываются. Kahan это библиотека. Их много, т.к. нод очень популярный.
Re[7]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 13.06.20 19:14
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

I>>>Что за зоопарк JS-технологий?

S>>node_modules. Ну, например.
I>node_modules это фолдер, куда зависимости складываются. Kahan это библиотека. Их много, т.к. нод очень популярный.
Одним словом — зоопарк.
Matrix has you...
Re[8]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.06.20 07:06
Оценка: -1 :))
Здравствуйте, Sheridan, Вы писали:

I>>>>Что за зоопарк JS-технологий?

S>>>node_modules. Ну, например.
I>>node_modules это фолдер, куда зависимости складываются. Kahan это библиотека. Их много, т.к. нод очень популярный.
S>Одним словом — зоопарк.

Очевидно, нет. Веб приложение, где и дотнет и жээс, гораздо труднее в разработке. Например, потому, что нет шансов вынести общий код и его придется дублировать.
Отредактировано 14.06.2020 7:19 Pauel . Предыдущая версия .
Re[9]: ойвэй
От: Sheridan Россия  
Дата: 14.06.20 08:21
Оценка: 1 (1) +2 -1
Здравствуйте, Ikemefula, Вы писали:

S>>Одним словом — зоопарк.

I>Очевидно, нет. Веб приложение, где и дотнет и жээс, гораздо труднее в разработке. Например, потому, что нет шансов вынести общий код и его придется дублировать.
Ойвэй, так много, так много. Умопомрачитель, невообразимо много. Ажно все структуры данных, которые фронт и бак между собой перебрасывают. Да и то только в том случае, если хочется секса с трансляцией json в структуры а не работы с ним как с объектом.
Matrix has you...
Re: Для тех, кто смеется над JavaScript
От: Maniacal Россия  
Дата: 14.06.20 09:31
Оценка: 1 (1)
Здравствуйте, Lazytech, Вы писали:

L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).


Один опытный JavaScript-программист ещё во времена DHTML 4.0 мне тогда ещё неопытному в 1998 году говорил, что на JS можно сделать всё. И это реально правда даже по меркам того времени.
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 14.06.20 10:35
Оценка:
Здравствуйте, Maniacal, Вы писали:

M>Один опытный JavaScript-программист ещё во времена DHTML 4.0 мне тогда ещё неопытному в 1998 году говорил, что на JS можно сделать всё. И это реально правда даже по меркам того времени.


Я слышал, что в наше время JavaScript-движки стали настолько хороши, что переписывание кода с JavaScript на C или C++ иногда дает прирост по скорости всего в 10-15%. Хотя, насколько я понимаю, JavaScript охоч до памяти...
Re[10]: ойвэй
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.06.20 16:52
Оценка: -1 :)))
Здравствуйте, Sheridan, Вы писали:

S>Ойвэй, так много, так много. Умопомрачитель, невообразимо много. Ажно все структуры данных, которые фронт и бак между собой перебрасывают. Да и то только в том случае, если хочется секса с трансляцией json в структуры а не работы с ним как с объектом.


Вся инфраструктура дублируется. Если нужен SEO или что навроде — фактически, два бакенда, жээс и дотнет. Валидация — дважды.
А раз все это дважды, то и тестов в два раза больше.
Теперь нужно приседать с планированием и тщательно трекать зависимости, т.к. в общем случае один деввелопер ни одну фичу сделать не может. Нужно два — бакенд и дотнет. Или искать других, дороже. Фуллстеки как правило хорошо знают только одну часть и сносно — другую. Далеко не везде это приемлемо.
Как следствие — геморрой с АПИ.
Re: Для тех, кто смеется над JavaScript
От: TimurSPB Интернет  
Дата: 14.06.20 17:45
Оценка: 3 (1)
Nodejs это неплохо для сервисов которые имеют простую логику, учитывая масштабируемость для бедных из коробки. Например, порывшись на помойке(NPM), можно быстро соорудить бота для телеграмм в режиме "вопрос-ответ". Если бота настигнет успех, то можно будет горизонтально масштабироваться тупым наращиванием инстансов. Быстрота, красота, перспективы..
Как только логика усложняется, так сразу начнётся адъ и Израиль. Невозможно сделать серию запросов, например к корпоративной БД, с кучей данных и зависимостей, не сойдя с ума от спагетти из коллбеков/асинков. Конечно можно написать без спагетти, но язык не просто этому способствует, он практически заставляет это делать. Уже в четвёртой строчке примера от ТС выросла первая макаронина. Можно конечно простую часть типа обёртки на нём написать и дальше мутить микросервисы на Java/C#, но зачем плодить сущности в технологическом стеке компании? Понаиспользуют модных штук, а сеньёр девелопер потом еб..
Make flame.politics Great Again!
Re[11]: Для тех, кто смеется над JavaScript
От: AleksandrN Россия  
Дата: 14.06.20 21:35
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, AleksandrN, Вы писали:


I>>>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.


AN>>Требовать описания API, собрать команду для обсуждения.


I>Ну собрал, ну обсудили, убедились что твой вариант годный.


Для того, что бы убедиться, что реализация интерфейса в одной из частей системы правильная, нужны автоматические тесты.

I>Жди, пока другие закончат свои важные дела или переключайся на другую задачу.


До того, как будут закончены все части, интеграционное и системное тестирование проводить будет затруднительно и нужны будут заглушки. И нужно перед началом разработки разбить каждую часть на подзадачи и команде договориться о сроках, когда будут готовы части, позволяющие произвести предварительное интеграционное тестирование. Как вариант — выделить одного человека, который будет заниматься организацией взаимодействия частей системы.

Но это больше организационный вопрос, чем технический.

Можно использовать кодогенерацию, а разработчики фронта и бэка прикрутят сгенерированный код к своей части. Инстументы для этого есть и для REST и для для других способов взаимодействия.

I>>>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.


Ты же сам писал, о разделении ответственности: — "обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа". А теперь пишешь, что фронтендщик полезет бэк исправлять.

Один язык и на фронте и на бэке — удобно, но на прорыв не тянет.

I>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить.


Ты написал, "АПИ не готов", а не "реализация АПИ не готова". Интерфейс и реализация интерфейса — это не одно и тоже. Я тебе именно про интерфейс и писал, т.к. в первом сообщении было именно про него написано.
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 15.06.20 05:11
Оценка: +1
Здравствуйте, TimurSPB, Вы писали:

TSP>Как только логика усложняется, так сразу начнётся адъ и Израиль. Невозможно сделать серию запросов, например к корпоративной БД, с кучей данных и зависимостей, не сойдя с ума от спагетти из коллбеков/асинков. Конечно можно написать без спагетти, но язык не просто этому способствует, он практически заставляет это делать. Уже в четвёртой строчке примера от ТС выросла первая макаронина. Можно конечно простую часть типа обёртки на нём написать и дальше мутить микросервисы на Java/C#, но зачем плодить сущности в технологическом стеке компании? Понаиспользуют модных штук, а сеньёр девелопер потом еб..


Насколько я понимаю, разработчики на Node.js уже несколько лет как достаточно успешно борются с callback hell:

https://blog.risingstack.com/node-js-async-best-practices-avoiding-callback-hell-node-js-at-scale/

https://stackabuse.com/avoiding-callback-hell-in-node-js/
Отредактировано 15.06.2020 5:13 Lazytech . Предыдущая версия .
Re[12]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.20 08:57
Оценка:
Здравствуйте, AleksandrN, Вы писали:

Я скипнул, поскольку ты вырезаешь серединки фраз, любуйся:

AN>Ты же сам писал, о разделении ответственности: — "обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа". А теперь пишешь, что фронтендщик полезет бэк исправлять.


Ты вырезал серединку, а вот выделеное скромно пропустил:

С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.


Ради чего ты занялся такой вот непрыкрытой подтасовкой?

AN>Один язык и на фронте и на бэке — удобно, но на прорыв не тянет.


В том то и дело, что это давно прорыв. Каким будет АПИ для клиента, решает клиент. См. Backend-For-Frontend. Здесь не надо спрашивать никаких бакендов, ни ждать, пока они соизволят спуститься с гор. Можно и нужно обходиться безо всякой бюрократии, типа бесконечных митингов, соглашательств между фронтами и бакендами.
Простой принцип — кому надо, тот и делает. АПИ нужен фронтам. Вот они его и пилят. На самом деле бакенды в этом тоже учавствуют, т.к. технически это бакенд, деплоится с бакендом, билдится вместе с ним и тд. Но логически эта часть не что иное, как фронтенд — часть обязанностей с фронта искусственно перетащили на бакенд.

Особенность фронтенда — он меняется дико и часто. Иногда требования меняются буквально на ходу. Все процессы, которые построены на согласованиях, спецификация и прочей бюрократии, не успевают.
Скажем, добавить ровно один индикатор в виде красной точки который означает "свежие новости" означает изменение АПИ.
С т.з. UI изменений почти нет, одна красная точка. Тестируется очень просто — в одном браузере публикуешь новость, в другом браузере видишь точку.

Как правило, бизнес измеряет сложность решений в пикселах. Мало пикселов — ждём изменения уже завтра. Проблема в том, что по твоему подходу надо начать писать спецификации, проводить митинги, согласования и прочие вещи.
Теперь можно иначе — добавляешь роут, пишешь непровальную реализацию, тесты, подсвечиваешь эти три пикселя и делаешь демо.Потом эту фичу может и уберут, мало ли, часто так и бывает. Собирать консилиум, пилить сваггером, документировать, публиковать, апрувать — эдак и

I>>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить.


AN>Ты написал, "АПИ не готов", а не "реализация АПИ не готова". Интерфейс и реализация интерфейса — это не одно и тоже. Я тебе именно про интерфейс и писал, т.к. в первом сообщении было именно про него написано.


Еще раз — я про РЕАЛИЗАЦИЮ, а ты мне про согласование, интерфейы согласование.

Кто будет писать код этого самого АПИ, когда бакенды заняты? Нужна РЕАЛИЗАЦИЯ

Все твои заглушки это компромиссы от плохой жизни, а не рокет саенс.
Отредактировано 15.06.2020 10:56 Pauel . Предыдущая версия . Еще …
Отредактировано 15.06.2020 9:39 Pauel . Предыдущая версия .
Отредактировано 15.06.2020 9:02 Pauel . Предыдущая версия .
Re[2]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.20 09:01
Оценка:
Здравствуйте, TimurSPB, Вы писали:

TSP>Nodejs это неплохо для сервисов которые имеют простую логику, учитывая масштабируемость для бедных из коробки. Например, порывшись на помойке(NPM), можно быстро соорудить бота для телеграмм в режиме "вопрос-ответ". Если бота настигнет успех, то можно будет горизонтально масштабироваться тупым наращиванием инстансов. Быстрота, красота, перспективы..


Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.
Re[3]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.20 09:43
Оценка:
Здравствуйте, Ikemefula, Вы писали:

TSP>>Nodejs это неплохо для сервисов которые имеют простую логику, учитывая масштабируемость для бедных из коробки. Например, порывшись на помойке(NPM), можно быстро соорудить бота для телеграмм в режиме "вопрос-ответ". Если бота настигнет успех, то можно будет горизонтально масштабироваться тупым наращиванием инстансов. Быстрота, красота, перспективы..


I>Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.


Сейчас пишется огромное количество простых сервисов. Не монументальные памятники инженерной мысли, на века, как в нулевых, а обычные инструменты для бизнеса.
Рабочая сила имеет заоблачные цены, а наклепать сервис, проверить, годится или нет, стоит ли инвестировать, вот эти вещи всегда делаются быстро и задешево.
Re[13]: Для тех, кто смеется над JavaScript
От: Klikujiskaaan КНДР  
Дата: 15.06.20 09:49
Оценка: +1 -1
Здравствуйте, Ikemefula, Вы писали:

I>Еще раз — я про РЕАЛИЗАЦИЮ, а ты мне про согласование, интерфейcы согласование.

I>Кто будет писать код этого самого АПИ, когда бакенды заняты? Нужна РЕАЛИЗАЦИЯ
I>Все твои заглушки это компромиссы от плохой жизни, а не рокет саенс.


Если у вас фронты пишут за бэков API потому, что бэки заняты чем-то другим, это говорит лишь о том, что у вас что-то очень неладное творится в процессах управления командами.
Re[3]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 15.06.20 10:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.


Многие мелкие разработчики до сих пор jQuery используют, чего уж там...
Re[14]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.20 10:50
Оценка: -2 :)
Здравствуйте, Klikujiskaaan, Вы писали:

I>>Еще раз — я про РЕАЛИЗАЦИЮ, а ты мне про согласование, интерфейcы согласование.

I>>Кто будет писать код этого самого АПИ, когда бакенды заняты? Нужна РЕАЛИЗАЦИЯ
I>>Все твои заглушки это компромиссы от плохой жизни, а не рокет саенс.

K>Если у вас фронты пишут за бэков API потому, что бэки заняты чем-то другим, это говорит лишь о том, что у вас что-то очень неладное творится в процессах управления командами.


Наоборот, это вы месяцами согласуете вещи, которые делаются от силы за неделю. Автономность разработчика увеличивается, если он может залезть в смежную область и это ускоряет деливери. До кучи, см. Backend For Frontend.
Re[4]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.20 10:51
Оценка:
Здравствуйте, Lazytech, Вы писали:

I>>Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.


L>Многие мелкие разработчики до сих пор jQuery используют, чего уж там...


Используют, но это уже уходящий тренд. Многие вещи проще и быстрее сделать на реакте, нежели колупаться с джиквери.
Re[15]: Для тех, кто смеется над JavaScript
От: Klikujiskaaan КНДР  
Дата: 15.06.20 10:59
Оценка: +2 -1
Здравствуйте, Ikemefula, Вы писали:

I>Наоборот, это вы месяцами согласуете вещи, которые делаются от силы за неделю.


С чего ты взял, что мы месяцами согласуем вещи, которые делаются от силы за неделю?

I>Автономность разработчика увеличивается, если он может залезть в смежную область и это ускоряет деливери.


1) Это требует бОльшей квалификации, и, как следствие, большей оплаты труда. Особенно в мире JS, где большинство программистов пишут в стиле "200 метров джаваскрипта грузят текста 300 байт", и найти нормального спеца — это как найти вишенку в куче известной субстанции.
2) Повторюсь, если есть четкое разделение на фронт\бэк — ситуация когда бэк лезет на фронт что-то подправить, или наоборот, фронт лезет в бэк что-то доделать — это нездоровая ситуация, скорее всего — результат неумелого менеджмента.
Re[16]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.06.20 11:22
Оценка: -2 :)
Здравствуйте, Klikujiskaaan, Вы писали:

I>>Автономность разработчика увеличивается, если он может залезть в смежную область и это ускоряет деливери.


K>1) Это требует бОльшей квалификации, и, как следствие, большей оплаты труда. Особенно в мире JS, где большинство программистов пишут в стиле "200 метров джаваскрипта грузят текста 300 байт", и найти нормального спеца — это как найти вишенку в куче известной субстанции.


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

Отсюда ясно, что если фронт умеет редакс и fetch, то прикрутить еще один роут к имеющимся не составляет никакого труда. А это примерно минимальные требования к фронту на текущий момент.

K>2) Повторюсь, если есть четкое разделение на фронт\бэк — ситуация когда бэк лезет на фронт что-то подправить, или наоборот, фронт лезет в бэк что-то доделать — это нездоровая ситуация, скорее всего — результат неумелого менеджмента.


Четкое разделение на фронт и бек это слишком примитивный подход, слишком много зависимостей и связаных с ними ожидаданий.
Отредактировано 15.06.2020 11:32 Pauel . Предыдущая версия .
Re[5]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 15.06.20 12:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Используют, но это уже уходящий тренд. Многие вещи проще и быстрее сделать на реакте, нежели колупаться с джиквери.


Я как раз переделываю один код с jQuery + Bootstrap на Svelte + Sveltestrap.
Re[7]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 15.06.20 15:17
Оценка: 1 (1)
Здравствуйте, Reset, Вы писали:

R>Затем сделали async/await и избавились от лесенок callback'ов.


Так это сделали везде, от питона до C++/boost.
Re[3]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 15.06.20 15:30
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Да и на уровне языва у питона достаточно проблем.


Например, какие?
Re: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 15.06.20 15:39
Оценка:
Здравствуйте, Lazytech, Вы писали:

L>https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/

L>
const http = require('http');

L>const requestListener = function (req, res) {
L>  res.writeHead(200);
L>  res.end('Hello, World!');
L>}

L>const server = http.createServer(requestListener);
L>server.listen(8080);

L>

Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?
Re[2]: Для тех, кто смеется над JavaScript
От: varenikAA  
Дата: 15.06.20 15:57
Оценка:
Здравствуйте, Hobbes, Вы писали:

H>Здравствуйте, Lazytech, Вы писали:


L>>https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/

L>>
const http = require('http');

L>>const requestListener = function (req, res) {
L>>  res.writeHead(200);
L>>  res.end('Hello, World!');
L>>}

L>>const server = http.createServer(requestListener);
L>>server.listen(8080);

L>>

H>Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?


В смысле? С чего вы решили, что только гет?
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 15.06.20 16:22
Оценка:
Здравствуйте, Hobbes, Вы писали:

H>Чёт я не понял, а где написано, что функция requestListener выполняется только для запросов HTTP GET, а для других не выполняется?


К сожалению, пока не знаю ответа на этот вопрос. Я еще не сделал ни одного HTTP-сервера на Node.js
Re[3]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 15.06.20 16:34
Оценка: :)
Здравствуйте, varenikAA, Вы писали:

AA>В смысле? С чего вы решили, что только гет?


Из смысла протокола HTTP. Довольно странное отвечать такое на PUT или OPTONS.
Re[4]: Для тех, кто смеется над JavaScript
От: Reset  
Дата: 15.06.20 20:51
Оценка:
AA>>В смысле? С чего вы решили, что только гет?

H>Из смысла протокола HTTP. Довольно странное отвечать такое на PUT или OPTONS.


Это демонстрационный пример. Странно от него ожидать то же, что и от production.
Re[8]: Для тех, кто смеется над JavaScript
От: Reset  
Дата: 15.06.20 21:00
Оценка: 1 (1)
R>>Затем сделали async/await и избавились от лесенок callback'ов.

H>Так это сделали везде, от питона до C++/boost.


Чё, и в Java тоже? Про Kotlin я в курсе.

Бустовые корутины — они stackFull. Это хрень полная по сравнению со stackLess из C++20. Бустовые годятся только для legacy, потому что stackless по всем параметрам лучше.

Асинхронные фреймворки есть почти на всем, но в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.
Re[4]: Для тех, кто смеется над JavaScript
От: varenikAA  
Дата: 16.06.20 00:33
Оценка:
Здравствуйте, Hobbes, Вы писали:

H>Здравствуйте, varenikAA, Вы писали:


AA>>В смысле? С чего вы решили, что только гет?


H>Из смысла протокола HTTP. Довольно странное отвечать такое на PUT или OPTONS.

Тогда это бы был не хелоуворд. Код рассчитан на новичка — запустил и тут же в браузере увидел результат.
А что увидит новичок, если в примере будет "этот ваш" ПАТ или ОПШИНС?
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[6]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.06.20 06:31
Оценка:
Здравствуйте, Lazytech, Вы писали:

I>>Используют, но это уже уходящий тренд. Многие вещи проще и быстрее сделать на реакте, нежели колупаться с джиквери.


L>Я как раз переделываю один код с jQuery + Bootstrap на Svelte + Sveltestrap.


И как Svelte ?
Re[9]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 16.06.20 07:46
Оценка:
Здравствуйте, Reset, Вы писали:

R>в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.


Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?
Re[5]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 16.06.20 07:59
Оценка: -1 :)
Здравствуйте, varenikAA, Вы писали:

AA>Тогда это бы был не хелоуворд. Код рассчитан на новичка — запустил и тут же в браузере увидел результат.

AA>А что увидит новичок, если в примере будет "этот ваш" ПАТ или ОПШИНС?

Как минимум должно быть где-то указано, что обработчик действителен только для метода GET. Фреймворк по умолчанию, незаметно для новичка, должен предусмотреть возврат 405 Method Not Allowed, если обработчик не определён.
Re[7]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 16.06.20 08:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>И как Svelte ?


Намного проще, чем React (с которым я знаком только теоретически и крайне поверхностно), и, наверное, чуть проще, чем Vue.
Re[10]: Для тех, кто смеется над JavaScript
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 16.06.20 11:04
Оценка:
Здравствуйте, Hobbes, Вы писали:

H>Здравствуйте, Reset, Вы писали:


R>>в NodeJS асинхронщина изначально закладывалась как обязательная возможность. В результате она есть везде (сеть, диск, драйвера баз данных) в обязательном виде, а не опциональная возможность, которая в половине библиотек не реализована.


H>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?

Многопоточность есть, но не сильно нужна. Потому что есть асинхронность и в одном потоке вполне можно много чего делать.
Если использовать многопоточность, то у потоков нет общих ресурсов. Взаимодействие через сообщения.
Re[9]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 16.06.20 11:48
Оценка: 2 (1)
Здравствуйте, Reset, Вы писали:

R>Бустовые корутины — они stackFull. Это хрень полная по сравнению со stackLess из C++20. Бустовые годятся только для legacy, потому что stackless по всем параметрам лучше.


Есть и те, и другие. https://www.boost.org/doc/libs/1_73_0/doc/html/boost_asio/overview/core/coroutine.html
Re[10]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 16.06.20 13:19
Оценка: -1
Здравствуйте, Hobbes, Вы писали:

H>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?


Он однопоточных и асинхронный. Доступ по идее будет сериализуемым.
Кодом людям нужно помогать!
Re[11]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.06.20 09:34
Оценка: 4 (2)
Здравствуйте, Sharov, Вы писали:

H>>Это интересно. А как там с многопоточностью, в движке ноды? Как разграничивается доступ к общему ресурсу из нескольких потоков?


S>Он однопоточных и асинхронный. Доступ по идее будет сериализуемым.


Это фатальное заблуждение. В ноде никакого серилизуемого доступа, если речь не про блокирующие вызовы. Он однопоточный, но тем не менее многозадачный. Те самые колбеки и тд, это кооперативная многозадачность. То есть, недетерминизм в полный рост. Только гонки надо искать не из за потоков, а из за колбеков и эвентлупа.

Например, операция доступа к ресурсу следующая —
async update(path, pattern) {
   const resource = await open(path); // доступ к ресурсу разделяемый, а не эксклюзивный !!!
   const oldHeader = await readHeader(resource); 
   const {newPattern, newHeader} = await nextStep(pattern, oldHeader);

   await writeToEnd(resource, newPattern);
   await updateHeader(resource, newHeader);
   await close(resource); 
}


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

update(path, pattern1);
update(path, pattern2);
update(path, pattern3);
update(path, pattern4);
update(path, pattern5);
update(path, pattern6);


То есть, мы здесь запустили 6 параллельных цепочек, каждая из которых работает с одним и тем же разделяемым ресурсом.

Вопрос — что будет в конце? А будет хаос, содержимое файла скорее всего будет представлять непойми что — одна цепочка обновила хидер, этот хидер тут же перезаписывается другой цепочкой. Она цепочка сделала запись в конец, но по этому же смещению тут же пишет другая цепочки.

А если вот так:

await update(path, pattern1);
await update(path, pattern2);
await update(path, pattern3);
await update(path, pattern4);
await update(path, pattern5);
await update(path, pattern6);


Вот это сериализуемый доступ, и сделано это руками. То есть, такую гарантию, как сериализуемый доступ, в ноде приходится делать руками. И так с любым разделяемым ресурсом.

Реально вот такое чудо не встречается, что бы все опреации сами по себе шли подряд, нужно пилить чтото более приемлемое. Например, соорудить нечто навроде мутекса или семафора:

const mutex = queue(1); // 1 - количество читателей-писателей которым разрешено одновременно работать с ресурсом

// http хандлер
app.post(async (req, res) => {
  const {pattern} = resolveArgs(req);

  await mutex(() => update(path, pattern)); // все запросы автоматически становятся в очередь
  res.send('', 204);
});
Отредактировано 17.06.2020 12:13 Pauel . Предыдущая версия . Еще …
Отредактировано 17.06.2020 10:43 Pauel . Предыдущая версия .
Отредактировано 17.06.2020 9:37 Pauel . Предыдущая версия .
Отредактировано 17.06.2020 9:35 Pauel . Предыдущая версия .
Re[3]: Для тех, кто смеется над JavaScript
От: Privalov  
Дата: 17.06.20 09:41
Оценка: :)
Здравствуйте, Lazytech, Вы писали:

L>К сожалению, пока не знаю ответа на этот вопрос. Я еще не сделал ни одного HTTP-сервера на Node.js


Может, не стоит начинать?
Re[4]: Для тех, кто смеется над JavaScript
От: Lazytech Ниоткуда  
Дата: 17.06.20 14:53
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Может, не стоит начинать?


Так я больше по части фронтенда...
Re[12]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 17.06.20 19:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Например, операция доступа к ресурсу следующая —

I>
I>async update(path, pattern) {
I>   const resource = await open(path); // доступ к ресурсу разделяемый, а не эксклюзивный !!!
I>   const oldHeader = await readHeader(resource); 
I>   const {newPattern, newHeader} = await nextStep(pattern, oldHeader);

I>   await writeToEnd(resource, newPattern);
I>   await updateHeader(resource, newHeader);
I>   await close(resource); 
I>}
I>


I>В итоге, ресурс хранит данные всех шагов некоторого вычисления и в хидере указаны соответствующие ссылки.

I>Теперь представим, что будет, если сделаем, скажем, вот такую хрень

I>
I>update(path, pattern1);
I>update(path, pattern2);
I>update(path, pattern3);
I>update(path, pattern4);
I>update(path, pattern5);
I>update(path, pattern6);
I>


I>То есть, мы здесь запустили 6 параллельных цепочек, каждая из которых работает с одним и тем же разделяемым ресурсом.


Разве это параллельное исполнение? Это а-ля корутины для эмуляции многопоточности, т.е. в один момент времени с файлом будет работать только один
update(path, patternX), но мы правда не знаем какой...
Кодом людям нужно помогать!
Re[11]: Для тех, кто смеется над JavaScript
От: Ops Россия  
Дата: 17.06.20 22:46
Оценка: +1 :)
Здравствуйте, Lazytech, Вы писали:

L>На днях, делая свое первое приложение на Node.js, был приятно удивлен простотой использования CommonJS (особенно если применять деструктуризацию). А в свежую версию Node вроде добавили поддержку ECMAScript Modules (пока experimental), с которыми работать еще удобнее.


Да, у этих модулей тоже зоопарк.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[13]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.06.20 07:17
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

I>>То есть, мы здесь запустили 6 параллельных цепочек, каждая из которых работает с одним и тем же разделяемым ресурсом.


S>Разве это параллельное исполнение? Это а-ля корутины для эмуляции многопоточности,


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

async/await это не эмуляция многопоточности, это связывание кусочков одной цепочки вместе. Унутре принципиально те же колбеки.

S>т.е. в один момент времени с файлом будет работать только один update(path, patternX), но мы правда не знаем какой...


async/await это принципиально тот же коллбек. Что бы гарантировать, что с ресурсом будет работать ровно один update, нужен механизм для линеаризации, та самая queue из моего примера.

Если логическая цепочка одна — то её части выполняются последовательно, для этого и нужен async/await, это связывание. Ровно так же, как и с колбеком-продолжением.

А вот если цепочек несколько, то никаких гарантий тебе никто не даст.

Вот решение задачи — просто инкрементим содержимое файла. Попробуй поиграться, запуская от 1 до n задач.

Колбеки
http://rsdn.org/forum/flame.comp/6423076.1
Автор: Ikemefula
Дата: 20.04.16


async/await:
const {readFileSync} = require('fs');
const fs = require('fs').promises;
const fileName = 'i';

async function read_i() {
    const x = await fs.readFile(fileName, {encoding:'utf8'});
    
    return toNumber(x);
}

function write_i(i) {
    return fs.writeFile(fileName, i);
}

function toNumber(buffer) {
    return +(buffer || 0).toString();
}

async function task(n, id) {
    while(n--) {
        tap('before read_i', id);
        const i = await read_i();
        tap('after read_i', id);
        await write_i(i + 1);
        tap('after write_i', id);
    }
}

function tap(msg, id) {
    console.log(msg, readFileSync(fileName, {encoding:'utf8'}), id);
}

fs.writeFileSync(fileName,'');

task(10, 1);
task(10, 2);
task(10, 3);
task(10, 4);
task(10, 5);
task(10, 6);
Отредактировано 20.06.2020 4:59 Pauel . Предыдущая версия . Еще …
Отредактировано 18.06.2020 7:19 Pauel . Предыдущая версия .
Re[12]: Для тех, кто смеется над JavaScript
От: TimurSPB Интернет  
Дата: 18.06.20 09:30
Оценка: -1
I>А если вот так:

I>
I>await update(path, pattern1);
I>await update(path, pattern2);
I>await update(path, pattern3);
I>await update(path, pattern4);
I>await update(path, pattern5);
I>await update(path, pattern6);
I>


I>Вот это сериализуемый доступ, и сделано это руками. То есть, такую гарантию, как сериализуемый доступ, в ноде приходится делать руками. И так с любым разделяемым ресурсом.

А если из "await update(path, pattern3)" полетит exception, то будет невнятное "Unhandled blabla..." без нормального стека и отладочным адом. Там же надо .catch ещё прописать, если я ничего не путаю. Или уже придумали нового сахара?

I>Реально вот такое чудо не встречается, что бы все опреации сами по себе шли подряд, нужно пилить чтото более приемлемое. Например, соорудить нечто навроде мутекса или семафора:

Грозились же в ноде сделать мьютексы и потоки.

I>
I>const mutex = queue(1); // 1 - количество читателей-писателей которым разрешено одновременно работать с ресурсом
I>// http хандлер
I>app.post(async (req, res) => {
I>  const {pattern} = resolveArgs(req);

I>  await mutex(() => update(path, pattern)); // все запросы автоматически становятся в очередь
I>  res.send('', 204);
I>});
I>

Опять же с обработкой ошибок не понятно, и внутренний голос говорит что однажды всё зависнет в строчке "await mutex(() => update(path, pattern))" из-за хрен пойми чего.

Как только нужно будет всё сделать в продуктовом качестве, так сразу всё обрастёт соплями и затычками. Нужно очень хорошее понимание принципов работы всего под капотом ноды, знание всех бест практикс и развитый мозг. Где взять таких программистов? Это рушит концепцию быстрого тайм ту маркет, одного языка для бэкенда и фронта. Не получается дёшево и эффективно, как это нередко утверждается про nodejs.
Make flame.politics Great Again!
Re[2]: Для тех, кто смеется над JavaScript
От: Ops Россия  
Дата: 18.06.20 09:40
Оценка: +1
Здравствуйте, Maniacal, Вы писали:

M>Один опытный JavaScript-программист ещё во времена DHTML 4.0 мне тогда ещё неопытному в 1998 году говорил, что на JS можно сделать всё. И это реально правда даже по меркам того времени.


Это для любого тьюринг-полного языка правда.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[13]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.06.20 09:53
Оценка:
Здравствуйте, TimurSPB, Вы писали:

I>>Вот это сериализуемый доступ, и сделано это руками. То есть, такую гарантию, как сериализуемый доступ, в ноде приходится делать руками. И так с любым разделяемым ресурсом.

TSP>А если из "await update(path, pattern3)" полетит exception, то будет невнятное "Unhandled blabla..." без нормального стека и отладочным адом. Там же надо .catch ещё прописать, если я ничего не путаю. Или уже придумали нового сахара?

Обычный сахар — try...catch, и не надо ничего придумывать.

I>>Реально вот такое чудо не встречается, что бы все опреации сами по себе шли подряд, нужно пилить чтото более приемлемое. Например, соорудить нечто навроде мутекса или семафора:

TSP>Грозились же в ноде сделать мьютексы и потоки.

При чем здесь это? Увидел слово мутекс и решил вспомнить потоки? Мутекс нужен в любой многозадачности, даже однопоточной, как ноде.
Да, в ноде многозадачность на одном потоке.

TSP>Опять же с обработкой ошибок не понятно, и внутренний голос говорит что однажды всё зависнет в строчке "await mutex(() => update(path, pattern))" из-за хрен пойми чего.


Однажды у тебя и в потоке может случиться бесконечный цикл или дедлок. Что с того?
Async/await как и промисы, это обычные колбеки унутре, никакой магии.
Потерял маленький кусочек и никогда не дождешься окончания задачи. Чем это отличается от кода в дотнете на асинк-авейтах? Ничем. Потерял — недождешься.


TSP>Как только нужно будет всё сделать в продуктовом качестве, так сразу всё обрастёт соплями и затычками.


У меня ничего не обрастает и работает как положено. Собственно, у большинства примерно так же. Обрастает соплями и затычками в любом стеке, хоть дотнет, хоть нод, хоть джава, по самым разным причинам — в основном из за особого отношения к работе "и так сойдет".
Отредактировано 18.06.2020 9:57 Pauel . Предыдущая версия .
Re[3]: Для тех, кто смеется над JavaScript
От: Maniacal Россия  
Дата: 18.06.20 11:41
Оценка: 1 (1)
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Maniacal, Вы писали:


M>>Один опытный JavaScript-программист ещё во времена DHTML 4.0 мне тогда ещё неопытному в 1998 году говорил, что на JS можно сделать всё. И это реально правда даже по меркам того времени.


Ops>Это для любого тьюринг-полного языка правда.


Он имел в виду связку Винда+IE в те времена. Полноценный GUI со всякими прогрессбарами, статусбарами, листбоксами, выпадающими меню и другими интерактивными самописными элементами (DHTML), 2D и 3D анимация (DirectAnimation), работа со звуком, джойстиком (DirectInput), работа с сетью (DirectPlay). Про работу с "БД" тоже что-то было написано в учебнике (с файлами на стороне сервера).
Re[14]: Для тех, кто смеется над JavaScript
От: TimurSPB Интернет  
Дата: 18.06.20 12:01
Оценка:
I>Обычный сахар — try...catch, и не надо ничего придумывать.
Так?
try {
    await update(path, pattern1);
    await update(path, pattern2);
    await update(path, pattern3);
    await update(path, pattern4);
    await update(path, pattern5);
    await update(path, pattern6);
} catch(e) {
    console.log(e);
}

Тогда непонятно будет откуда оно полетело.

I>У меня ничего не обрастает и работает как положено. Собственно, у большинства примерно так же. Обрастает соплями и затычками в любом стеке, хоть дотнет, хоть нод, хоть джава, по самым разным причинам — в основном из за особого отношения к работе "и так сойдет".

У тебя будет, но сколько ты стоишь и где найти команду таких как ты? В суровой реальности с этим проблемы.
Make flame.politics Great Again!
Re[15]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.06.20 13:49
Оценка:
Здравствуйте, TimurSPB, Вы писали:

TSP>Тогда непонятно будет откуда оно полетело.


Бывает.

I>>У меня ничего не обрастает и работает как положено. Собственно, у большинства примерно так же. Обрастает соплями и затычками в любом стеке, хоть дотнет, хоть нод, хоть джава, по самым разным причинам — в основном из за особого отношения к работе "и так сойдет".

TSP>У тебя будет, но сколько ты стоишь и где найти команду таких как ты? В суровой реальности с этим проблемы.

Проблема аналогична тем, что в других стеках. Единственно, где сливает именно жээс, это числодробилки. Это особенность такой его многозадачности.
Re[14]: Для тех, кто смеется над JavaScript
От: Мирный герцог Ниоткуда  
Дата: 18.06.20 15:32
Оценка: 1 (1) +3 -1
Здравствуйте, Ikemefula, Вы писали:

I>Это именно параллельное исполнение. В каком порядке выполняться будут операции и их части — никому неизвестно.


пожалуйста изучите термины, прежде чем их использовать. Это не параллельное исполнение, это асинхронное исполнение continuation'ов (в случае с js — генераторов, в других языках, как уже упомянули выше — это могли бы быть корутины). Параллельное исполнение подразумевает два+ вычислителя(две+ машины тьюринга — два+ процессора, две+ виртуальные машины, два+ стека), работающих одновременно. В node.js исполнительный поток один (хотя есть и воркеры). Грубо говоря у вас например никогда не будет гонки при инкременте глобального счётчика, т.к. параллельно код инкремента исполнится не может в принципе.
нормально делай — нормально будет
Re[3]: Для тех, кто смеется над JavaScript
От: RonWilson Россия  
Дата: 18.06.20 15:33
Оценка: :)
Здравствуйте, Lazytech, Вы писали:

L>К сожалению, пока не знаю ответа на этот вопрос. Я еще не сделал ни одного HTTP-сервера на Node.js


не стоит этого делать, а то еще в backend затянет, а это заразно
Re[15]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.06.20 16:59
Оценка:
Здравствуйте, Мирный герцог, Вы писали:

МГ>Здравствуйте, Ikemefula, Вы писали:


I>>Это именно параллельное исполнение. В каком порядке выполняться будут операции и их части — никому неизвестно.


МГ>пожалуйста изучите термины, прежде чем их использовать. Это не параллельное исполнение, это асинхронное исполнение continuation'ов (в случае с js — генераторов, в других языках, как уже упомянули выше — это могли бы быть корутины).


В Windows файберы https://docs.microsoft.com/en-us/windows/win32/procthread/fibers
и солнце б утром не вставало, когда бы не было меня
Re[15]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.06.20 18:09
Оценка: 1 (1)
Здравствуйте, Мирный герцог, Вы писали:

МГ>пожалуйста изучите термины, прежде чем их использовать. Это не параллельное исполнение, это асинхронное исполнение continuation'ов (в случае с js — генераторов, в других языках, как уже упомянули выше — это могли бы быть корутины). Параллельное исполнение подразумевает два+ вычислителя(две+ машины тьюринга — два+ процессора, две+ виртуальные машины, два+ стека), работающих одновременно. В node.js исполнительный поток один (хотя есть и воркеры). Грубо говоря у вас например никогда не будет гонки при инкременте глобального счётчика, т.к. параллельно код инкремента исполнится не может в принципе.


Ты путаешь логическое и физическое выполнение. Физическое как раз интересует меньше всего, т.к. ты никогда не знаешь, сколько у тебя физических вычислителей. Все что ты можешь сказать, что их больше нуля. Раз код выполняется, есть минимум 1

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

Гонки это свойство многозадачности, а не только потоков. Абсолютно любая многозадачность имеет гонки в соответствии со своей природой.

Гонки при инкременте глобального счетчика — раскрой глаза, я именно этот вариант показал. Все определяет протокол доступа к ресурсу. Если операция над ресурсом в рамках конкретной многозадачности неатомарна, то она будут давать те самые гонки если запустить параллельно несколько таких операций.
Re[9]: Для тех, кто смеется над JavaScript
От: Sheridan Россия  
Дата: 19.06.20 06:52
Оценка: -1
Здравствуйте, Reset, Вы писали:

R>Асинхронные фреймворки есть почти на всем, но в NodeJS асинхронщина изначально закладывалась как обязательная возможность.

Нет. жс тупо по другому не умеет. Приходится изворачиваться.
Matrix has you...
Re[16]: Для тех, кто смеется над JavaScript
От: Мирный герцог Ниоткуда  
Дата: 19.06.20 07:43
Оценка: +2 -1
Здравствуйте, Ikemefula, Вы писали:

I>Ты путаешь логическое и физическое выполнение.

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

I>Гонки это свойство многозадачности, а не только потоков. Абсолютно любая многозадачность имеет гонки в соответствии со своей природой.

я смотрю ты не понимаешь что такое гонки. Гонки, это когда у тебя выполняется 10 инкрементов, а в результате переменная инкрементируется на 9, или вообще на 1, вот это гонки. А то что ты называешь "гонками" это обычное асинхронное исполнение. Оно по определению не упорядоченно, но это не гонки и не "параллелизм".

I>Гонки при инкременте глобального счетчика — раскрой глаза, я именно этот вариант показал.

Я ещё раз говорю, давай код в котором в ноде будет гонка с инкрементом счётчика. То что ты можешь растекаться по древу мыслями используя собственное понимание общепринятой терминологию я уже понял.
нормально делай — нормально будет
Re[17]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.06.20 09:30
Оценка:
Здравствуйте, Мирный герцог, Вы писали:

МГ>Здравствуйте, Ikemefula, Вы писали:


I>>Ты путаешь логическое и физическое выполнение.

МГ>нет, я ничего не путаю, я вообще не говорил о "логическом" и "физическом" выполнении, особенно странно слышать о "физическом" выполнении когда я явно упомянул виртуальную машину как вычислитель.

В том то и дело, что не говорил, а надо бы Логически в моем примере целых 6 задач выполняются параллельно. Физически — однопоточный интерпретатор управляет состоянием и работой многопоточной виртуальной машины.
Из букваря по Node.js — физически отдельные части операций или даже операции целиком выполняются на отдельных вычислителях, ядрах, процессорах или потоках. Например, чтение из файла может выполняться буквально одновременно — два разных потока вычитывают все что надо, а по окончании готовый результат прокидывают в интерпретатор. Возможности параллелизма ограничены в данном случае не количеством ядер-процессоров, а возможностями системной шины.
Даже если под капотом нода ничего не будет(гипотетически), все равно есть операционка, и она точно может делать несколько дисковых операций одновременно.

Даже если ограничить node, теоретически, одним ядром-потоком на все его активности, логически всё равно будет 6 параллельных задач. С т.з. физического параллелизма будет использоваться другая стратегия распределения времени.

I>>Гонки это свойство многозадачности, а не только потоков. Абсолютно любая многозадачность имеет гонки в соответствии со своей природой.

МГ>я смотрю ты не понимаешь что такое гонки. Гонки, это когда у тебя выполняется 10 инкрементов, а в результате переменная инкрементируется на 9, или вообще на 1, вот это гонки. А то что ты называешь "гонками" это о бычное асинхронное исполнение. Оно по определению не упорядоченно, но это не гонки и не "параллелизм".

Тут надо вспомнить, что гонки и есть отсутствие упорядочения доступа к разделяемому ресурсу из за неконтролируемых событий, таймингов и тд. Поскольку асинхронное исполнение неупорядочено по времени, то при доступе к разделяемому ресурсу будет плодить гонки. И так вне зависимости от вида многозадачности.
Например — мы знаем, что запросы open выполняются одним за другим, это гарантирует интерпретатор, а вот ответы ядра нода, операционки, могут приходить как им вздумается, в любом порядке, упорядочения нет, правильно? Отсюда и возникают гонки, что и демонстрируется примерами кода.

I>>Гонки при инкременте глобального счетчика — раскрой глаза, я именно этот вариант показал.

МГ>Я ещё раз говорю, давай код в котором в ноде будет гонка с инкрементом счётчика. То что ты можешь растекаться по древу мыслями используя собственное понимание общепринятой терминологию я уже понял.

Ты хочешь увидеть частный случай — гонки из за многопоточности. Объект в другой воркер или даже поток можно передавать как по значению, так и по ссылке.

Гонки возможны на всех без исключения видах многозадачности. Собственно, от них в любой многозадачности никуда не деться.
Отредактировано 19.06.2020 10:05 Pauel . Предыдущая версия .
Re[10]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.06.20 10:17
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

R>>Асинхронные фреймворки есть почти на всем, но в NodeJS асинхронщина изначально закладывалась как обязательная возможность.

S>Нет. жс тупо по другому не умеет. Приходится изворачиваться.

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

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

На самом деле большинство задач в веб-приложениях никакой тяжелой логики не выполняют, просто передают данные с минимальными изменениями. То есть, CPU не является узким местом. Большинство это примерно 8..9 из 10.
То есть, потоки фактически заняты на 80-90% времени ожиданием ответа другой системы, бд, нетворка и тд. Это было уже задолго до Нода.
Именно эта особенность побудила разных людей взяться за эксперименты — разные платформы, разные языки.
Один из этих людей был автор Нода.
Отредактировано 19.06.2020 10:48 Pauel . Предыдущая версия .
Re[4]: Для тех, кто смеется над JavaScript
От: Ватакуси Россия  
Дата: 19.06.20 11:00
Оценка:
GIV>>Да и на уровне языва у питона достаточно проблем.

H>Например, какие?

Щас тебе GIL вспомнят.
Все будет Украина!
Re[18]: Для тех, кто смеется над JavaScript
От: Мирный герцог Ниоткуда  
Дата: 19.06.20 11:31
Оценка: +2 -1
Здравствуйте, Ikemefula, Вы писали:

I>Ты хочешь увидеть частный случай — гонки из за многопоточности. Объект в другой воркер или даже поток можно передавать как по значению, так и по ссылке.


я хочу чтобы ты корректно использовал устоявшиеся термины — параллелизм, асинхронность, многопоточность, многозадачность, это всё разные термины, для разных (хотя иногда и пересекающихся) контекстов. То, о чём ты говоришь называется concurrency. И для таких как ты (толком не разбирающихся в теме, и потому использующие термины к месту и не очень) пишут специальные статьи: https://tproger.ru/explain/concurrency-vs-parallelism/
нормально делай — нормально будет
Re[5]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 19.06.20 12:21
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Щас тебе GIL вспомнят.


Ну такое. Это проблема не языка, а эталонной реализации.

Я бы в числе проблем назвал неочевидный scope имён и неочевидную разницу между statement и expression. Второе я встречал только в паскале в далёкие университетские годы.
Re[19]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.06.20 15:05
Оценка: -1
Здравствуйте, Мирный герцог, Вы писали:

I>>Ты хочешь увидеть частный случай — гонки из за многопоточности. Объект в другой воркер или даже поток можно передавать как по значению, так и по ссылке.


МГ>я хочу чтобы ты корректно использовал устоявшиеся термины — параллелизм, асинхронность, многопоточность, многозадачность, это всё разные термины, для разных (хотя иногда и пересекающихся) контекстов. То, о чём ты говоришь называется concurrency. И для таких как ты (толком не разбирающихся в теме, и потому использующие термины к месту и не очень) пишут специальные статьи: https://tproger.ru/explain/concurrency-vs-parallelism/


В итоге ты не нашел ошибки в коде, аргументировать разницу в терминах не смог, привел в качестве аргумента картинку из журнала Мурзилка Ты мог бы и не стараться, я и так понял, откуда у тебя термины.

Вот, навскидку:

1. многозадачность есть логическая и физическая. Логическая — как мы организуем. Физическая — как мы исполняем.

здесь уже нюанс — мой код логически можно рассматривать двояко, как одну задачу инкремента разбитую на 6 подзадач, так и шесть независимых задач конкурирующих за общий ресурс. И шесть задач они какие именно — цикл или только его внутренности?

2. многопоточность — стратегия разделения физических ресурсов, т.е. конкретная реализация. Поток = вычислитель и связаные с ним ресурсы, ядро, регистры, стек, контекст. Вместо потока может быть и процесс, и другой комп, и что угодно другое.

Нюанс — нод он однопоточно-многопоточный

3. синхронный, асинхронный код — указывает, как логические задачи перекладываются на физические. Например, один поток выполняет одну задачу. Это синхронный код. А может и иначе — поток может выполнять то одну, то другую, то третью. Это асинхронный код.
Отсюда ясно, что может быть целых 4 варианта
синхронный однопоточный
синхронный многопоточный
асинхронный однопоточный
асинхронный многопоточный

Последовательный-конкурентный-параллельный — стратегия использования времени. Конкурентный, значит в единицу времени прогресс происходит со всеми задачами. Последовательный — только с одной. Параллельный — не просто прогресс, а именно выполнение в единицу времени.

Три нюанса
1 что считать прогрессом, инкремент или полный цикл доступа к ресурсу. Очевидно — полный цикл.
2 параллелизм возможен, о ужас, в однопоточным асинхронном варианте, см. выше! В этом случае параллельными будут логические задачи, если между ними нет зависимостей. Ровно так же и параллелизм в многопоточном одноядерном исполнении.
3 часто, но не всегда, параллелизм есть способ реализации конкурентности

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

Теперь гонки — это ситуация с неопределенной последовательностью доступа к разделяемому ресурсу. Причины разные — параллелизм, сеть, что угодно.

В данном случае одного только параллелизма недостаточно, чтобы обеспечить искомый результат. Очевидно — параллелизм приводит к гонкам, которые и наблюдаем.
Нужно ввести явную зависимость между задачами, а именно — одна задача может работать с ресурсом за раз. Тогда за одно и то же время только одна из задач выполняется. А это уже будет не параллельное, а конкурентное исполнение, т.к. исполнение в наличии тольку у одной задачи, хотя прогресс есть у всех.

Всё, можешь пользоваться.
Отредактировано 19.06.2020 16:44 Pauel . Предыдущая версия . Еще …
Отредактировано 19.06.2020 15:19 Pauel . Предыдущая версия .
Отредактировано 19.06.2020 15:08 Pauel . Предыдущая версия .
Re[6]: Для тех, кто смеется над JavaScript
От: Ватакуси Россия  
Дата: 19.06.20 16:15
Оценка:
H>Я бы в числе проблем назвал неочевидный scope имён и неочевидную разницу между statement и expression. Второе я встречал только в паскале в далёкие университетские годы.

Можно примеры?
Все будет Украина!
Re[7]: Для тех, кто смеется над JavaScript
От: Hobbes Россия  
Дата: 21.06.20 08:46
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Можно примеры?


Пример разницы между statement и expression? Тысячи их. И это был бы оффтоп в топике про JS. Со scope сложнее, возможно, это мои личные заморочки.
Re[12]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 25.06.20 16:24
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>
I>update(path, pattern1);
I>update(path, pattern2);
I>update(path, pattern3);
I>update(path, pattern4);
I>update(path, pattern5);
I>update(path, pattern6);
I>


I>То есть, мы здесь запустили 6 параллельных цепочек, каждая из которых работает с одним и тем же разделяемым ресурсом.


Секундочку, допустим мы работаем с диском. Тогда код выше последовательно поставит в очередь контроллера диска какие-то операции. А вот что будет дальше, я
По идее также последовательно они и будут выполняться. Где здесь параллельность?

Далее, допустим мы инкрементируем какую-то глобальную переменную. В данном случае никакой параллельности нет, и rc тоже нет, ибо поток исполнения у нас 1.
Вот если у нас будет сеть и непредсказуемая задержка (latency), тогда да, предсказать кто раньше кто позже будет сложно.
Кодом людям нужно помогать!
Re[13]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.20 08:32
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Секундочку, допустим мы работаем с диском. Тогда код выше последовательно поставит в очередь контроллера диска какие-то операции. А вот что будет дальше, я

S>По идее также последовательно они и будут выполняться. Где здесь параллельность?

Ты запускать пробовал или тебе предпочтительно теоретизировать?

Код выше поставит какие то операции в очередь, но далеко не факт, что ответ от io придет в той же последовательности. По какой причине — дело десятое, надо копаться во внутренностях ядра нода, ос, драйверов и тд и тд.

S>Далее, допустим мы инкрементируем какую-то глобальную переменную. В данном случае никакой параллельности нет, и rc тоже нет, ибо поток исполнения у нас 1.


Неверно. В это время io занят выполнением файловых операций.

S>Вот если у нас будет сеть и непредсказуемая задержка (latency), тогда да, предсказать кто раньше кто позже будет сложно.


Задержка между запросом на чтение/запись и ответом непредсказуема. Попробуй поиграть с кодом, хотя бы запустить его, и увидишь своими глазами.
Re[14]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 26.06.20 09:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

S>>Секундочку, допустим мы работаем с диском. Тогда код выше последовательно поставит в очередь контроллера диска какие-то операции. А вот что будет дальше, я

S>>По идее также последовательно они и будут выполняться. Где здесь параллельность?
I>Ты запускать пробовал или тебе предпочтительно теоретизировать?

Теоретезировал. Пытаюсь понять теорию.

I>Код выше поставит какие то операции в очередь, но далеко не факт, что ответ от io придет в той же последовательности. По какой причине — дело десятое, надо копаться во внутренностях ядра нода, ос, драйверов и тд и тд.


Мне бы честно, хотелось бы узнать причины, по которой ответ придет в разом порядке. Учитывая, что в конкретном примере мы работаем с одним и тем же файлом.
Если файлы разные, тогда да, параллельность имеется.

S>>Далее, допустим мы инкрементируем какую-то глобальную переменную. В данном случае никакой параллельности нет, и rc тоже нет, ибо поток исполнения у нас 1.

I>Неверно. В это время io занят выполнением файловых операций.

Причем здесь io, если в ноде принципиально отсутствует многопоточность?

S>>Вот если у нас будет сеть и непредсказуемая задержка (latency), тогда да, предсказать кто раньше кто позже будет сложно.

I>Задержка между запросом на чтение/запись и ответом непредсказуема. Попробуй поиграть с кодом, хотя бы запустить его, и увидишь своими глазами.

Про параллельность в случае сети и разных файлов я вовсе не спорил. Спор про один и тот же файл и счетчик в памяти.
Кодом людям нужно помогать!
Re[15]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.20 11:10
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Теоретезировал. Пытаюсь понять теорию.


А что мешает взять да запустить?

I>>Код выше поставит какие то операции в очередь, но далеко не факт, что ответ от io придет в той же последовательности. По какой причине — дело десятое, надо копаться во внутренностях ядра нода, ос, драйверов и тд и тд.


S>Мне бы честно, хотелось бы узнать причины, по которой ответ придет в разом порядке. Учитывая, что в конкретном примере мы работаем с одним и тем же файлом.


Я даже не представляю, каким образом это можно выявить. Недетерминизм можно ождать откуда угодно — внутренности нода, ос, драйверов, кеш, протокол работы с железом, шина, сам контроллер устройства

S>>>Далее, допустим мы инкрементируем какую-то глобальную переменную. В данном случае никакой параллельности нет, и rc тоже нет, ибо поток исполнения у нас 1.

I>>Неверно. В это время io занят выполнением файловых операций.

S>Причем здесь io, если в ноде принципиально отсутствует многопоточность?


Нод — многопоточный! Это его основная фишка. Однопоточный только исполнитель джаваскрипта. Именно исполнитель, т.к. сам интерпретатор состоит из многих вещей, которые в т.ч. многопоточны, например, гц. Пока жээс инкрементит, унутре идут файловые операции.
Re[16]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 26.06.20 11:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sharov, Вы писали:


S>>Теоретезировал. Пытаюсь понять теорию.


I> А что мешает взять да запустить?


1)Хочется разобраться в теории.
2)Пока не вижу необходимости -- в принципе, со всем, что Вы тут пишите я в целом согласен. Есть теор. нюансы, которые надо бы прояснить.
3)Лень.

S>>Мне бы честно, хотелось бы узнать причины, по которой ответ придет в разом порядке. Учитывая, что в конкретном примере мы работаем с одним и тем же файлом.

I>Я даже не представляю, каким образом это можно выявить. Недетерминизм можно ождать откуда угодно — внутренности нода, ос, драйверов, кеш, протокол работы с железом, шина, сам контроллер устройства

А вот надо представлять! Иначе какой в этом смысл? Разве будет недетреминизм, если мы в очередь поставили обращение к одному и тому же файлу -- чтение, запись? Мне кажется, все будет последовательно. Соотв. результат будет аналогичен await.


S>>Причем здесь io, если в ноде принципиально отсутствует многопоточность?

I>Нод — многопоточный! Это его основная фишка. Однопоточный только исполнитель джаваскрипта. Именно исполнитель, т.к. сам интерпретатор состоит из многих вещей, которые в т.ч. многопоточны, например, гц. Пока жээс инкрементит, унутре идут файловые операции.

Вот именно однопоточный исполнитель и будет инкрементировать переменную в памяти. Т.е. никаких rc в принципе. Acинхронный io да, сколько угодно.
Кодом людям нужно помогать!
Re[17]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.20 11:47
Оценка:
Здравствуйте, Sharov, Вы писали:

I>>Я даже не представляю, каким образом это можно выявить. Недетерминизм можно ождать откуда угодно — внутренности нода, ос, драйверов, кеш, протокол работы с железом, шина, сам контроллер устройства


S>А вот надо представлять! Иначе какой в этом смысл? Разве будет недетреминизм, если мы в очередь поставили обращение к одному и тому же файлу -- чтение, запись? Мне кажется, все будет последовательно. Соотв. результат будет аналогичен await.


Ты продолжаешь теоретизировать. Запусти и сам увидишь, что никакого последовательного доступа нет. Каждый раз разные последовательности.

Важно иметь гарантии серилизованого доступа. И тут важно знать природу этого механизма — кто серилизует. А вот природа недетерминизма как раз так не сильно интересует.

S>>>Причем здесь io, если в ноде принципиально отсутствует многопоточность?

I>>Нод — многопоточный! Это его основная фишка. Однопоточный только исполнитель джаваскрипта. Именно исполнитель, т.к. сам интерпретатор состоит из многих вещей, которые в т.ч. многопоточны, например, гц. Пока жээс инкрементит, унутре идут файловые операции.

S>Вот именно однопоточный исполнитель и будет инкрементировать переменную в памяти. Т.е. никаких rc в принципе. Acинхронный io да, сколько угодно.


Гонки есть в каждой виде многозадачности. Такой вот неприятный факт. И совсем неважно, какая она — синхронная многопоточная или асинхронная однопоточная, вытесняющая или кооперативная.
Разница только в том, как именно выглядят эти гонки там и там.

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

У тебя почему то задача == поток. Это крайне неверное утверждение.
Отредактировано 26.06.2020 11:54 Pauel . Предыдущая версия .
Re[18]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 26.06.20 12:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ты продолжаешь теоретизировать. Запусти и сам увидишь, что никакого последовательного доступа нет. Каждый раз разные последовательности.

I>Важно иметь гарантии серилизованого доступа. И тут важно знать природу этого механизма — кто серилизует. А вот природа недетерминизма как раз так не сильно интересует.

Самое интересное и важное. Именно вот это св-во асинхронность и эксплуатирует. Нужно же знать степень недетерминизма. Если его нет совсем, то как async io поможет?


I> Гонки есть в каждой виде многозадачности. Такой вот неприятный факт. И совсем неважно, какая она — синхронная многопоточная или асинхронная однопоточная, вытесняющая или кооперативная.

I>Разница только в том, как именно выглядят эти гонки там и там.
I>У тебя почему то задача == поток. Это крайне неверное утверждение.

Вы мне чего-то приписываете странное. Я утверждаю, что при "однопоточном исполнителе" никаких гонок при инкрементирование переменной в памяти (это не io!!!) нету.
Параллельность io задач это никак не отменяет.

> В нашем случае read и write не обеспечивают атомарность. Соотвенно из за параллелизма получаем, например, write одной задачи вмешивается в read другой задачи.


При "однопоточном исполнителе" это не играет роли.
Кодом людям нужно помогать!
Re[19]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.20 12:31
Оценка:
Здравствуйте, Sharov, Вы писали:

I>>Важно иметь гарантии серилизованого доступа. И тут важно знать природу этого механизма — кто серилизует. А вот природа недетерминизма как раз так не сильно интересует.


S>Самое интересное и важное. Именно вот это св-во асинхронность и эксплуатирует. Нужно же знать степень недетерминизма. Если его нет совсем, то как async io поможет?


Это гарантии серилизованого доступа только наоборот.

I>>Разница только в том, как именно выглядят эти гонки там и там.

I>>У тебя почему то задача == поток. Это крайне неверное утверждение.

S>Вы мне чего-то приписываете странное. Я утверждаю, что при "однопоточном исполнителе" никаких гонок при инкрементирование переменной в памяти (это не io!!!) нету.


Я про ресурс, а ты про переменную Определяет не наличие переменной, а протокол доступа. При простом инкременте операция чтение-изменение-запись может быть атомарной. А вот если мы разнесем во времени эти три составляющие, то даже с одной переменной будут проблемы.

>> В нашем случае read и write не обеспечивают атомарность. Соотвенно из за параллелизма получаем, например, write одной задачи вмешивается в read другой задачи.


S>При "однопоточном исполнителе" это не играет роли.


Однопоточных исполнителей минимум два варианта. Поточность это всего лишь способ упаковки логических задач на физический исполнитель.
1. синхронный однопоточный
2. асинхронный однопоточный

В первом варианте с ресурсом все будет хорошо — один поток, ничего, кроме одной задачи он выполнять не может. Одна задача работает от начала до конца, другие гарантировано стоят неначавшись.
Во втором варианте все будет плохо — разные задачи выполняются передавая друг другу управление через эвент луп, фактически — кооперативная многозадачность.
Re[20]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 26.06.20 12:53
Оценка:
Здравствуйте, Ikemefula, Вы писали:

S>>Самое интересное и важное. Именно вот это св-во асинхронность и эксплуатирует. Нужно же знать степень недетерминизма. Если его нет совсем, то как async io поможет?

I>Это гарантии серилизованого доступа только наоборот.

Можете мысль развернуть?

S>>Вы мне чего-то приписываете странное. Я утверждаю, что при "однопоточном исполнителе" никаких гонок при инкрементирование переменной в памяти (это не io!!!) нету.

I>Я про ресурс, а ты про переменную Определяет не наличие переменной, а протокол доступа. При простом инкременте операция чтение-изменение-запись может быть атомарной. А вот если мы разнесем во времени эти три составляющие, то даже с одной переменной будут проблемы.

Я уже давно про переменную и про доступ к ней при "однопоточном исполнителе". Про ресурсы(io) мы пришли к консенсусу -- параллелилизм наличествует.
Я не до конца понимаю, а разве инструкция i+=1 может быть прервана? Ну допустим, мы убрали контекст задачи инкрементации, где в регистре процессора
у нас лежит i+1, но в память еще не записали, переключились на контекст callback'а . Ну прочитает callback значение i, ну и, в чем проблема? i+1 мы еще не опубликовали, это в чьем то стеке\регистре процессора и т.д. А как только i+1 опубликуем, так все последующие callback'и будут читать i+1. Т.е. никакой неконсистентности тут нет. Вполне наличествует сериализуемость.
Кодом людям нужно помогать!
Re[21]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.20 13:05
Оценка:
Здравствуйте, Sharov, Вы писали:

S>>>Самое интересное и важное. Именно вот это св-во асинхронность и эксплуатирует. Нужно же знать степень недетерминизма. Если его нет совсем, то как async io поможет?

I>>Это гарантии серилизованого доступа только наоборот.

S>Можете мысль развернуть?


Цитата "степень недетерминизма" @ — это серилизованый доступ наоборот. Проще говорить о серилизованом доступе, есть он, нет его, будет ровно то же.
Нас интересует не сам недетерминизм, а паралеллизм. Сам недерерминизм это просто сопутствующий эффект.

I>>Я про ресурс, а ты про переменную Определяет не наличие переменной, а протокол доступа. При простом инкременте операция чтение-изменение-запись может быть атомарной. А вот если мы разнесем во времени эти три составляющие, то даже с одной переменной будут проблемы.


S>Я уже давно про переменную и про доступ к ней при "однопоточном исполнителе". Про ресурсы(io) мы пришли к консенсусу -- параллелилизм наличествует.

S>Я не до конца понимаю, а разве инструкция i+=1 может быть прервана? Ну допустим, мы убрали контекст задачи инкрементации, где в регистре процессора

Мы можем протокол заменить на другой — прочитали, передали дальше, поймали, вычислили, передали дальше, поймали, записали.

S>у нас лежит i+1, но в память еще не записали, переключились на контекст callback'а . Ну прочитает callback значение i, ну и, в чем проблема? i+1 мы еще не опубликовали, это в чьем то стеке\регистре процессора и т.д. А как только i+1 опубликуем, так все последующие callback'и будут читать i+1. Т.е. никакой неконсистентности тут нет. Вполне наличествует сериализуемость.


Это потому, что протокол такой. А если протокол поменять, что я продемонстрировал кодом, то сразу ломается всё подряд.
Re[22]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 26.06.20 13:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

S>>Я уже давно про переменную и про доступ к ней при "однопоточном исполнителе". Про ресурсы(io) мы пришли к консенсусу -- параллелилизм наличествует.

S>>Я не до конца понимаю, а разве инструкция i+=1 может быть прервана? Ну допустим, мы убрали контекст задачи инкрементации, где в регистре процессора
I>Мы можем протокол заменить на другой — прочитали, передали дальше, поймали, вычислили, передали дальше, поймали, записали.

Какой протокол? Вы что в это слово вкладываете?

S>>у нас лежит i+1, но в память еще не записали, переключились на контекст callback'а . Ну прочитает callback значение i, ну и, в чем проблема? i+1 мы еще не опубликовали, это в чьем то стеке\регистре процессора и т.д. А как только i+1 опубликуем, так все последующие callback'и будут читать i+1. Т.е. никакой неконсистентности тут нет. Вполне наличествует сериализуемость.

I>Это потому, что протокол такой. А если протокол поменять, что я продемонстрировал кодом, то сразу ломается всё подряд.


Можно код, который сломает i+=1 при "однопоточном исполнителе"?
Кодом людям нужно помогать!
Re[23]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.06.20 18:13
Оценка:
Здравствуйте, Sharov, Вы писали:

I>>Мы можем протокол заменить на другой — прочитали, передали дальше, поймали, вычислили, передали дальше, поймали, записали.


S>Какой протокол? Вы что в это слово вкладываете?


Да всё то же, что и всегда.
Ты что, не видишь разницы между инкрементом переменной в памяти и инкрементом переменной в файле? Это ресурсы с разным протоколом доступа. И я показал, что именно там происходит. Что еще тебе надо ?

Вот если вместо асинхронного чтения-записи использовать синхронное, т.е. изменение протокола, все гонки устраняются.

S>>>у нас лежит i+1, но в память еще не записали, переключились на контекст callback'а . Ну прочитает callback значение i, ну и, в чем проблема? i+1 мы еще не опубликовали, это в чьем то стеке\регистре процессора и т.д. А как только i+1 опубликуем, так все последующие callback'и будут читать i+1. Т.е. никакой неконсистентности тут нет. Вполне наличествует сериализуемость.

I>>Это потому, что протокол такой. А если протокол поменять, что я продемонстрировал кодом, то сразу ломается всё подряд.
S>


S>Можно код, который сломает i+=1 при "однопоточном исполнителе"?


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

Ты можешь заменить операции с файлом, скажем на такие

async read(): number { return i }

async write(value: number) { i = value }


Собственно, атомарными будут только чтение переменной и её запись, весь цикл — чтение-инкремент-запись будет неатомарным, а следовательно, несколько параллельных цепочек сломают инвариант.

А вот если убрать async то все стает в норму. Проблема только в том, что теперь циклы будут выполняться последовательно.
Отредактировано 28.06.2020 18:20 Pauel . Предыдущая версия . Еще …
Отредактировано 28.06.2020 18:19 Pauel . Предыдущая версия .
Отредактировано 28.06.2020 18:15 Pauel . Предыдущая версия .
Re[24]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.06.20 18:23
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:


S>>Можно код, который сломает i+=1 при "однопоточном исполнителе"?


I>Если буквально такой вот код, то никакой, потому что один поток выполняет ровно одну операцию и никто больше на это не влияет. Глаза то раскрой — мои два примера именно про это, только ресурс не переменная в памяти, а внутри файла. Все что делает каждая из задач — инкрементит переменную. Только протокол доступа другой. Какой именно — надо взять, посмотреть, запустить и сравнить результаты двух-трех запусков.


I>Ты можешь заменить операции с файлом, скажем на такие


I>
I>async read(): number { return i }

I>async write(value: number) { i = value }
I>


Это уже не "однопоточном исполнителе"

Но если
 var i=await  read();
 await write(++i);


будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 28.06.2020 18:34 Serginio1 . Предыдущая версия .
Re[25]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.06.20 18:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>Ты можешь заменить операции с файлом, скажем на такие


I>>
I>>async read(): number { return i }

I>>async write(value: number) { i = value }
I>>


S>Это уже не "однопоточном исполнителе"



Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.
Re[26]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.06.20 18:36
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>Ты можешь заменить операции с файлом, скажем на такие


I>>>
I>>>async read(): number { return i }

I>>>async write(value: number) { i = value }
I>>>


S>>Это уже не "однопоточном исполнителе"


I>

I>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.
Ок. Назовем многозадачно! Или MultiPromises в переводе на русский МногоОбещающие
Просто задачи по аналогии с многопоточностью вызываемые на одном ядре, вызываются в одном потоке. Сути это не меняет, так как задача может начинатья, до окончания предыдущей. Есть очередь и планировщик

Откуда гонки?
 var i=await  read();
 await write(++i);


будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.

Покажи гонки если вызывается только один метод, по аналогии с однопоточным?
и солнце б утром не вставало, когда бы не было меня
Отредактировано 28.06.2020 19:13 Serginio1 . Предыдущая версия . Еще …
Отредактировано 28.06.2020 18:55 Serginio1 . Предыдущая версия .
Отредактировано 28.06.2020 18:49 Serginio1 . Предыдущая версия .
Отредактировано 28.06.2020 18:40 Serginio1 . Предыдущая версия .
Re[27]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.06.20 19:24
Оценка: 1 (1) -1
Здравствуйте, Serginio1, Вы писали:

I>>

I>>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.

S> Откуда гонки?

S>
S> var i=await  read();
S> await write(++i);
S>



await это тот же колбек, только управление от эвентлупа.

Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче.

Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

S>будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)


Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.

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

S>Читай и записывай хоть откуда. Тоже, что и при синхронном.


А тебе лишь бы теоретизировать, но не код запускать. Ты адекватный?

S> Покажи гонки если вызывается только один метод, по аналогии с однопоточным?


Все что надо, я показал, только у тебя тяга к теоретизированию

Вот смотри внимательно Вначале отрабатывают все 6 read и каждый зачитывает 0, после чего уходит в эвентлуп. Опаньки! Это уже доказывает что await работает не так как ты хотел. Далее, смотри логи в браузере

Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.

let iiii= 0;

async function read_i() {
    return iiii;
}

async function write_i(value) {
    iiii = value;
}


async function task(n, id) {
    while(n--) {
        tap('before read_i', id);
        const i = await read_i();
        tap('after read_i', id);
        await write_i(i + 1);
        tap('after write_i', id);
    }
}

function tap(msg, id) {
    console.log(msg, iiii, id);
}

debugger;

task(10, 1);
task(10, 2);
task(10, 3);
task(10, 4);
task(10, 5);
task(10, 6);
Re[28]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.06.20 20:47
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>

I>>>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.

S>> Откуда гонки?

S>>
S>> var i=await  read();
S>> await write(++i);
S>>


I>

I>await это тот же колбек, только управление от эвентлупа.

I>Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче. Windows Phone в 2011-м

Это я понимаю. Но если для данного класса выполняется только один метод, то откуда гонки.


I>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.


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

S>>будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)


I>Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.

Объясни как при выполнении одной задачи могут быть гонки?

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

I>Авайт это просто колбек, получает управление от эвентлупа. А эвентлуп раздает управлении в соответствии с тем, что в него напичкано. А за эвентлуп дерутся целых несколько идентичных задач.


S>>Читай и записывай хоть откуда. Тоже, что и при синхронном.


I> А тебе лишь бы теоретизировать, но не код запускать. Ты адекватный?


S>> Покажи гонки если вызывается только один метод, по аналогии с однопоточным?


I>Все что надо, я показал, только у тебя тяга к теоретизированию


I>Вот смотри внимательно Вначале отрабатывают все 6 read и каждый зачитывает 0, после чего уходит в эвентлуп. Опаньки! Это уже доказывает что await работает не так как ты хотел. Далее, смотри логи в браузере


I>Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.


function write_i(value) {
iiii = value;
}

I>task(10, 1);

I>task(10, 2);
I>task(10, 3);
I>task(10, 4);
I>task(10, 5);
I>task(10, 6);
write(10); тоже не будет атомарности.

await task(10, 1);
await task(10, 2);
await task(10, 3);
await task(10, 4);
await task(10, 5);
await task(10, 6);
write(10);


Никаких гонок не будет.
и солнце б утром не вставало, когда бы не было меня
Re[29]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 09:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче. Windows Phone в 2011-м

S> Это я понимаю. Но если для данного класса выполняется только один метод, то откуда гонки.

Гонки когда разные ЗАДАЧИ обращаются к одному ресурсу одновременно. ЗАДАЧИ, а не только потоки. Любые задачи, любого происхождения.
И гонки надо искать в зависимости от природы многозадачности.
То есть, всего три условия
1 ресурс разделяется между задачами
2 протокол доступа неатомарный с т.з. конкретной многозадачности.
3 параллельное исполнение

I>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.


S> Угу был вопрос по сути про однозадачность. Там нет гонок.


У тебя многозадачность = однопоточность. поточность это стратегия использоваться процессорного ядра, физическая реализация.
А задачи это логический уровень.

Синхронный код — одна задача на поток. Асинхронный — несколько задач на один и тот же задач, чередуются как попало.

I>>Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.

S> Объясни как при выполнении одной задачи могут быть гонки?

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

S>Тогда если выполняется обычный синхронный метод и один или множество асинхронный метод то будут гонки.


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

I>>Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.


[code]
S>function write_i(value) {
S> iiii = value;
S>}
S>[/cs]
S> тоже не будет атомарности.

Одного только write не хватит, т.к. read по прежнему неатомарный и весь цикл read-increment-write неатомарный.

S>
S>await task(10, 1);
S>await task(10, 2);
S>await task(10, 3);
S>await task(10, 4);
S>await task(10, 5);
S>await task(10, 6);
S>write(10);
S>


S>Никаких гонок не будет.


Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?

Атомарность будет только в том случае, когда и read и инкремент и write от начала и до конца не будут прерываться никакими другими цепочками.

Этого можно добиться двумя путями

1. переписать полностью на синхронный код, т.е. убрать все await и async. Тогда это гарантируется синхронным однопоточным исполнителем.

2. завернуть read-increment-write в очередь, эдакий асинхронный мутекс. Соответсвенно, снова никто вклиниваться не сможет.
Отредактировано 29.06.2020 9:47 Pauel . Предыдущая версия .
Re[30]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 10:12
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче. Windows Phone в 2011-м

S>> Это я понимаю. Но если для данного класса выполняется только один метод, то откуда гонки.

I>Гонки когда разные ЗАДАЧИ обращаются к одному ресурсу одновременно. ЗАДАЧИ, а не только потоки. Любые задачи, любого происхождения.

I> И гонки надо искать в зависимости от природы многозадачности.
I>То есть, всего три условия
I>1 ресурс разделяется между задачами
I>2 протокол доступа неатомарный с т.з. конкретной многозадачности.
I>3 параллельное исполнение

Ну вот не хрена не читатель! Еще раз речь про одну!! задачи. Внутри которой все подзадачи с awaite!
I>>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

Если задачи выполняются через await никакому другому эта задача не уйдет!
Для выполнения другой задачи ты должен запустить без awaite. Но тогда проблема у тебя будет и в синхронном коде!

S>> Угу был вопрос по сути про однозадачность. Там нет гонок.


I> У тебя многозадачность = однопоточность. поточность это стратегия использоваться процессорного ядра, физическая реализация.

I>А задачи это логический уровень.

В JS нет задач, там Обещание! В .Net задача не равно потоку. Может быть пул из одного потока, но множество задач.
Но есть планировщик со своей очередью потоков (в данном случае 1)

I>Синхронный код — одна задача на поток. Асинхронный — несколько задач на один и тот же задач, чередуются как попало.

Ну я то знаю. Уж поверь давно на asinc\awate программирую. Кстати в TS они появились раньше чем в JS

I>>>Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.

S>> Объясни как при выполнении одной задачи могут быть гонки?

I>Асинхронный однопоточный код это такая вот реализация многозадачности. Соответсвенно,несколько задач работают с одним и тем же ресурсом.

Какие несколько задач? Я говорил про одну!

S>>Тогда если выполняется обычный синхронный метод и один или множество асинхронный метод то будут гонки.


I>Разумеется. Асинхронный код дает гонки вне зависимости от числа потоков. Синхронный код дает гонки на нескольких потоках.


I>>>Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.


I>[code]

S>>function write_i(value) {
S>> iiii = value;
S>>}
S>>[/cs]
S>> тоже не будет атомарности.

I>Одного только write не хватит, т.к. read по прежнему неатомарный и весь цикл read-increment-write неатомарный.


S>>
S>>await task(10, 1);
S>>await task(10, 2);
S>>await task(10, 3);
S>>await task(10, 4);
S>>await task(10, 5);
S>>await task(10, 6);
S>>write(10);
S>>


S>>Никаких гонок не будет.


I>Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?

То есть у тебя при последовательном выполнении через await выполняются непоследовательно?
Тогда проблема в JS или ты где то запустил еще задачу без await

I>Атомарность будет только в том случае, когда и read и инкремент и write от начала и до конца не будут прерываться никакими другими цепочками.


I>Этого можно добиться двумя путями


I>1. переписать полностью на синхронный код, т.е. убрать все await и async. Тогда это гарантируется синхронным однопоточным исполнителем.


I>2. завернуть read-increment-write в очередь, эдакий асинхронный мутекс. Соответсвенно, снова никто вклиниваться не сможет.


Если ты будешь запускать задачи без await то покажи как это на онопотоке будет выглядеть?
Такая цепочка должна выполняться последовательно. Без гонок если конечно не запустить task без await
await task(10, 1);
await task(10, 2);
await task(10, 3);
await task(10, 4);
await task(10, 5);
await task(10, 6);
write(10);


Для параллельного выполнение на .Net ожидают через WhenAll или WhenAny
Иногда можно просто запустить долгоиграющую задачу без awaite.

А так можно использовать асинхронные очереди
https://docs.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
AsyncProducerConsumerCollection

А так JS похож на Виндовое окно с очередью сообщений
и солнце б утром не вставало, когда бы не было меня
Отредактировано 29.06.2020 10:29 Serginio1 . Предыдущая версия .
Re[31]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 11:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>2 протокол доступа неатомарный с т.з. конкретной многозадачности.

I>>3 параллельное исполнение

S> Ну вот не хрена не читатель! Еще раз речь про одну!! задачи. Внутри которой все подзадачи с awaite!


Ты хочешь получить гонки на одной задаче? Гонки это когда много задач Или много под-задач.

I>>>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.


S>Если задачи выполняются через await никакому другому эта задача не уйдет!


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

S>Для выполнения другой задачи ты должен запустить без awaite. Но тогда проблема у тебя будет и в синхронном коде!


Это неверная интерпретация. Запускай хоть с авайт, хоть без него — выполняется кусочек жээс кода, который заканчивается выходом в эвент луп.
Всё. Кусочек задачи завершен. Далее эвент луп берет из очереди следующий колбек, передает управление туда. И так до скончания времен.

I>> У тебя многозадачность = однопоточность. поточность это стратегия использоваться процессорного ядра, физическая реализация.

I>>А задачи это логический уровень.

S> В JS нет задач, там Обещание!


Еще раз — задача это логический уровень. А у тебя задача == поток. Промис это те же колбеки, только в виде паттерна. Авайт — сахар над промисами.

Очевидно, что ничего сверх колбеков авайтами не выжмешь.

I>>Синхронный код — одна задача на поток. Асинхронный — несколько задач на один и тот же задач, чередуются как попало.

S> Ну я то знаю. Уж поверь давно на asinc\awate программирую. Кстати в TS они появились раньше чем в JS

Да чтото не похоже, у тебя авайт это какой то всемогутор, который чего то там исполняет

I>>Асинхронный однопоточный код это такая вот реализация многозадачности. Соответсвенно,несколько задач работают с одним и тем же ресурсом.

S> Какие несколько задач? Я говорил про одну!

А я везде пишу — гонки возникают на более чем одной задаче. Чего ты сказать хочешь?

I>>
S>>>function write_i(value) {
S>>>    iiii = value;
S>>>}
S>>>

S>>> тоже не будет атомарности.

I>>Одного только write не хватит, т.к. read по прежнему неатомарный и весь цикл read-increment-write неатомарный.


I>>Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?

S> То есть у тебя при последовательном выполнении через await выполняются непоследовательно?

Ты запускать пробовал? Алё, это ж элементарно. Вместо этого ты мне доказываешь непойми что.



Для одной цепочки — последовательно. Для нескольких — как угодно. Авайт ничего не знает про другие цепочки, это просто связывание двух контекстов.

Я тебе страшное скажу — эвент-луп тоже не делает никакого упорядочения. Он просто выполняет в том порядке, в каком колбеки ставятся в очередь.

S>Тогда проблема в JS или ты где то запустил еще задачу без await


Теоретик, у тебя же весь код перед глазами, что мешает запустить да посмотреть?

I>>Этого можно добиться двумя путями


I>>1. переписать полностью на синхронный код, т.е. убрать все await и async. Тогда это гарантируется синхронным однопоточным исполнителем.


I>>2. завернуть read-increment-write в очередь, эдакий асинхронный мутекс. Соответсвенно, снова никто вклиниваться не сможет.


S> Если ты будешь запускать задачи без await то покажи как это на онопотоке будет выглядеть?


Нахер надо, ты примеры даже не запускаешь Попробуй скопировать, вставить в консоль да посмотреть

S>Такая цепочка должна выполняться последовательно. Без гонок если конечно не запустить task без await


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

Собственно, я именно это и показываю

Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее

VM42:23 before read_i 0 1  << цепочка 1 начало
VM42:23 before read_i 0 2
VM42:23 before read_i 0 3
VM42:23 before read_i 0 4
VM42:23 before read_i 0 5
VM42:23 before read_i 0 6
VM42:23 after read_i 0 1   << цепочка 1 чтение закончено, 0 инкремент, и тут же идет запись
VM42:23 after read_i 1 2   << следующие 5 цепочек зачитали единицу, гы-гы-гы  
VM42:23 after read_i 1 3
VM42:23 after read_i 1 4
VM42:23 after read_i 1 5
VM42:23 after read_i 1 6
VM42:23 after write_i 1 1  << цепочка 1 запись единицы, следующие 5 цепочек ... ну, ты понял :-)


Понятно что происходит? Авайт выстраивает последовательность только одного экземпляра цепочки, про другие он ничего не знает. А поскольку все это делается через эвент-луп, то другие цепочки вклиниваются перезатирают результаты друг друга.

S> Такая цепочка должна выполняться последовательно.


Это всё, что ты мне хотел показать? Ничего, что мои все примеры показывают как await , так и его отсутствие ?

S> А так JS похож на Виндовое окно с очередью сообщений


Именно. Только ты ждешь чудес от авайт. Это просто синтаксический сахар над колбеками и ничего более.
Отредактировано 29.06.2020 11:22 Pauel . Предыдущая версия . Еще …
Отредактировано 29.06.2020 11:19 Pauel . Предыдущая версия .
Отредактировано 29.06.2020 11:08 Pauel . Предыдущая версия .
Отредактировано 29.06.2020 11:03 Pauel . Предыдущая версия .
Re[32]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 11:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>2 протокол доступа неатомарный с т.з. конкретной многозадачности.

I>>>3 параллельное исполнение

S>> Ну вот не хрена не читатель! Еще раз речь про одну!! задачи. Внутри которой все подзадачи с awaite!


I>Ты хочешь получить гонки на одной задаче? Гонки это когда много задач Или много под-задач.

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

I>>>>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.


S>>Если задачи выполняются через await никакому другому эта задача не уйдет!

Если ты запустил несколько задач без await, то это уже многозадачность!


I>"задачи выполняются через await" — это откровенная чушь. await это синтаксический сахар над колбеками. Асинхронный код изначально нарезан на кусочки. Каждый кусочек запускается эвент-лупом. Авайт всего лишь связывает последовательность. Но это никакой не мутекс, соотвественно, в другой части кода может происходить что угодно.


Это не сахар, а конечный автомат. Внутри стоит yield. Код разбивается на несколько методов по yield Когда вызывается await запоминается текущее состояние объекта, а после выполнения задачи вызывется Next и код выполняется дальше.
Там могут быть рекурсивные вызовы итд.

Это .Net реализация. Она же была и в TS до asinc/await в JS.

А при чем тут мьютекс? Ты же сам пишешь " Авайт всего лишь связывает последовательность", то есть части awaite выполняются последовательно.
О каких нескольких цепочках идет речь? Вторую цепочку ты можешь запустить без awaite. Тогда и синхронному коду придет кирдык!

Возьми мой код с await и посмотри. Если там будет разнобой значит дерьмо ваша JS.

Если, же ты хочешь писать многозадачный код, то неатомарный код тебе нужно синхронизировать.
Но речь то идет про однозадачность. Будь она синхронная или асинхронная.
Все твои примеры из многозадачности от которой не спасает и синхронный код.
и солнце б утром не вставало, когда бы не было меня
Re[32]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 11:53
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее


I>
I>VM42:23 before read_i 0 1  << цепочка 1 начало
I>VM42:23 before read_i 0 2
I>VM42:23 before read_i 0 3
I>VM42:23 before read_i 0 4
I>VM42:23 before read_i 0 5
I>VM42:23 before read_i 0 6
I>VM42:23 after read_i 0 1   << цепочка 1 чтение закончено, 0 инкремент, и тут же идет запись
I>VM42:23 after read_i 1 2   << следующие 5 цепочек зачитали единицу, гы-гы-гы  
I>VM42:23 after read_i 1 3
I>VM42:23 after read_i 1 4
I>VM42:23 after read_i 1 5
I>VM42:23 after read_i 1 6
I>VM42:23 after write_i 1 1  << цепочка 1 запись единицы, следующие 5 цепочек ... ну, ты понял :-)
I>


То есть на таком коде
await task(10, 1);
await task(10, 2);
await task(10, 3);
await task(10, 4);
await task(10, 5);
await task(10, 6);
write(10);


before read_i 0 1
VM52:23 after read_i 0 1
VM52:23 after write_i 1 1
VM52:23 before read_i 1 1
VM52:23 after read_i 1 1
VM52:23 after write_i 2 1
VM52:23 before read_i 2 1
VM52:23 after read_i 2 1
VM52:23 after write_i 3 1
VM52:23 before read_i 3 1
VM52:23 after read_i 3 1
VM52:23 after write_i 4 1
VM52:23 before read_i 4 1
VM52:23 after read_i 4 1
VM52:23 after write_i 5 1
VM52:23 before read_i 5 1
VM52:23 after read_i 5 1
VM52:23 after write_i 6 1
VM52:23 before read_i 6 1
VM52:23 after read_i 6 1
VM52:23 after write_i 7 1
VM52:23 before read_i 7 1
VM52:23 after read_i 7 1
VM52:23 after write_i 8 1
VM52:23 before read_i 8 1
VM52:23 after read_i 8 1
VM52:23 after write_i 9 1
VM52:23 before read_i 9 1
VM52:23 after read_i 9 1
VM52:23 after write_i 10 1
VM52:23 before read_i 10 2
VM52:23 after read_i 10 2
VM52:23 after write_i 11 2
VM52:23 before read_i 11 2
VM52:23 after read_i 11 2
VM52:23 after write_i 12 2
VM52:23 before read_i 12 2
VM52:23 after read_i 12 2
VM52:23 after write_i 13 2
VM52:23 before read_i 13 2
VM52:23 after read_i 13 2
VM52:23 after write_i 14 2
VM52:23 before read_i 14 2
VM52:23 after read_i 14 2
VM52:23 after write_i 15 2
VM52:23 before read_i 15 2
VM52:23 after read_i 15 2
VM52:23 after write_i 16 2
VM52:23 before read_i 16 2
VM52:23 after read_i 16 2
VM52:23 after write_i 17 2
VM52:23 before read_i 17 2
VM52:23 after read_i 17 2
VM52:23 after write_i 18 2
VM52:23 before read_i 18 2
VM52:23 after read_i 18 2
VM52:23 after write_i 19 2
и солнце б утром не вставало, когда бы не было меня
Re[33]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 12:04
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее


I>>
I>>VM42:23 before read_i 0 1  << цепочка 1 начало
I>>VM42:23 before read_i 0 2
I>>VM42:23 before read_i 0 3
I>>VM42:23 before read_i 0 4
I>>VM42:23 before read_i 0 5
I>>VM42:23 before read_i 0 6
I>>VM42:23 after read_i 0 1   << цепочка 1 чтение закончено, 0 инкремент, и тут же идет запись
I>>VM42:23 after read_i 1 2   << следующие 5 цепочек зачитали единицу, гы-гы-гы  
I>>VM42:23 after read_i 1 3
I>>VM42:23 after read_i 1 4
I>>VM42:23 after read_i 1 5
I>>VM42:23 after read_i 1 6
I>>VM42:23 after write_i 1 1  << цепочка 1 запись единицы, следующие 5 цепочек ... ну, ты понял :-)
I>>


S>То есть на таком коде

S>
S>await task(10, 1);
S>await task(10, 2);
S>await task(10, 3);
S>await task(10, 4);
S>await task(10, 5);
S>await task(10, 6);
S>write(10);
S>


Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?
Re[33]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 12:13
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>Ты хочешь получить гонки на одной задаче? Гонки это когда много задач Или много под-задач.

S> Был вопрос про однопоточность. По сути подразумевалось про однозадачность для данного объекта.

Ты путаешь однопоточность и однозадачность.

S>>>Если задачи выполняются через await никакому другому эта задача не уйдет!

S>Если ты запустил несколько задач без await, то это уже многозадачность!

Капитан, я про это и пишу!

S> Это не сахар, а конечный автомат. Внутри стоит yield.


Стоит или не стоит, это прячется компилятором. Один из вариантов это трансляция в промисы, второй вариант — нативный await, еще вариант — yield, еще вариант — конечный вариант, самый упоротый из всех.
И, о ужас, еще вариант — обычные колбеки.

Функционально все это сводится к колбекам. Никаких преимуществ сверх этого нет и не будет.

S> А при чем тут мьютекс? Ты же сам пишешь " Авайт всего лишь связывает последовательность", то есть части awaite выполняются последовательно.


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

S>О каких нескольких цепочках идет речь? Вторую цепочку ты можешь запустить без awaite. Тогда и синхронному коду придет кирдык!


Я именно про это и пишу.

S>Возьми мой код с await и посмотри. Если там будет разнобой значит дерьмо ваша JS.


Ты похоже влез и начал не читая махать шашкой.

Читай себя

будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.


Собственно, здесь ты наврал. Во первых, исполнение жээс это один поток, а во вторых, читать и записывать хоть откуда не выйдет и я показал, почему именно не выйдет.

S>Если, же ты хочешь писать многозадачный код, то неатомарный код тебе нужно синхронизировать.


И про это я тоже пишу. Все мои примерно про многозадачность в жээсе и про необходимость синхронизации.

S>Но речь то идет про однозадачность. Будь она синхронная или асинхронная.




S>Все твои примеры из многозадачности от которой не спасает и синхронный код.


Бинго! С этого все и начиналось. Только надо было читать внимательно.
Отредактировано 29.06.2020 12:17 Pauel . Предыдущая версия .
Re[34]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 12:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?

Был вопрос приведи пример где будет i++ не атомарным в однопотоке
Ты начал приводить примеры с async и добавил, что JS выполняется в одном потоке.
Тогда я сказал ок. Какие могут быть проблемы в однозадачном режиме с await?
Потому, что если будет запуск без await то и синхронный код с гонками.
Только и всего. Наконец ты понял
и солнце б утром не вставало, когда бы не было меня
Re[34]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 12:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>Ты хочешь получить гонки на одной задаче? Гонки это когда много задач Или много под-задач.

S>> Был вопрос про однопоточность. По сути подразумевалось про однозадачность для данного объекта.

I>Ты путаешь однопоточность и однозадачность.

Я тебе про однозадачность уже много расписывал. Ничего я не путаю.

S>>>>Если задачи выполняются через await никакому другому эта задача не уйдет!

S>>Если ты запустил несколько задач без await, то это уже многозадачность!

I>Капитан, я про это и пишу!

А я тебе пишу про однозадачность!

S>> Это не сахар, а конечный автомат. Внутри стоит yield.


I>Стоит или не стоит, это прячется компилятором. Один из вариантов это трансляция в промисы, второй вариант — нативный await, еще вариант — yield, еще вариант — конечный вариант, самый упоротый из всех.

I>И, о ужас, еще вариант — обычные колбеки.

I>Функционально все это сводится к колбекам. Никаких преимуществ сверх этого нет и не будет.


S>> А при чем тут мьютекс? Ты же сам пишешь " Авайт всего лишь связывает последовательность", то есть части awaite выполняются последовательно.


I>А потому, что я изначально пишу про многозадачность, а именно — асинхронный однопоточный код.

Потому, что ты не читатель! Я тебе сразу написал про однозадачность.

S>>О каких нескольких цепочках идет речь? Вторую цепочку ты можешь запустить без awaite. Тогда и синхронному коду придет кирдык!


I>Я именно про это и пишу.


S>>Возьми мой код с await и посмотри. Если там будет разнобой значит дерьмо ваша JS.


I>Ты похоже влез и начал не читая махать шашкой.


I>Читай себя

I>

I>будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
I>Читай и записывай хоть откуда. Тоже, что и при синхронном.


I>Собственно, здесь ты наврал. Во первых, исполнение жээс это один поток, а во вторых, читать и записывать хоть откуда не выйдет и я показал, почему именно не выйдет.


S>>Если, же ты хочешь писать многозадачный код, то неатомарный код тебе нужно синхронизировать.


I>И про это я тоже пишу. Все мои примерно про многозадачность в жээсе и про необходимость синхронизации.


S>>Но речь то идет про однозадачность. Будь она синхронная или асинхронная.


I>


S>>Все твои примеры из многозадачности от которой не спасает и синхронный код.


I>Бинго! С этого все и начиналось. Только надо было читать внимательно.

Во во. Я тебе сразу писал про однозадачность
B i++ будет атомарным при любом режиме.
В .Net используют для SpinLock вернее Interlocked.Increment(ref nextTaskIndex)

Ладно. Зря потратил время. Извини. Завелся. Только вот за что минусы я так и не понял
Ну промисы это не всегда калбеки
Метод Promise.resolve(value) возвращает Promise выполненый с переданным значением.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 29.06.2020 12:33 Serginio1 . Предыдущая версия . Еще …
Отредактировано 29.06.2020 12:28 Serginio1 . Предыдущая версия .
Re[35]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 12:29
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?

S>Был вопрос приведи пример где будет i++ не атомарным в однопотоке

Але — тут вся подветка про многозадачность. Товарищ на полном серьез утверждал, что

await серилизует доступ к ресурсу


Тебе понятно, про что речь шла?

S>Ты начал приводить примеры с async и добавил, что JS выполняется в одном потоке.


См выше.

S>Тогда я сказал ок. Какие могут быть проблемы в однозадачном режиме с await?


Стоит таки читать, особенно когда влазишь в конец беседы.

S>Потому, что если будет запуск без await то и синхронный код с гонками.

S> Только и всего. Наконец ты понял

Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.
Re[35]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 12:35
Оценка: -1
Здравствуйте, Serginio1, Вы писали:

I>>Ты путаешь однопоточность и однозадачность.

S> Я тебе про однозадачность уже много расписывал. Ничего я не путаю.

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

I>>Капитан, я про это и пишу!

S> А я тебе пишу про однозадачность!
I>>А потому, что я изначально пишу про многозадачность, а именно — асинхронный однопоточный код.
S>Потому, что ты не читатель! Я тебе сразу написал про однозадачность.

То есть, ты влез в беседу про многозадачный код и попросил показать гонки в однозадачном коде? Ты адекватен?

S> Ладно. Зря потратил время. Извини. Завелся. Только вот за что минусы я так и не понял


Минусы за то, что ты влез не вникая в тему, и начал махать шашкой. Речь была про доступ к ресурсу и сериализацию этого доступа.
Re[36]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 12:37
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?

S>>Был вопрос приведи пример где будет i++ не атомарным в однопотоке

I>Але — тут вся подветка про многозадачность. Товарищ на полном серьез утверждал, что

I>

I>await серилизует доступ к ресурсу


I>Тебе понятно, про что речь шла?

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

S>>Ты начал приводить примеры с async и добавил, что JS выполняется в одном потоке.


I>См выше.


S>>Тогда я сказал ок. Какие могут быть проблемы в однозадачном режиме с await?


I>Стоит таки читать, особенно когда влазишь в конец беседы.

Угу то есть я и виноват, что ты меня не читаешь.
S>>Потому, что если будет запуск без await то и синхронный код с гонками.
S>> Только и всего. Наконец ты понял

I>Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.

Я не читал всю ветку у меня был вопрос только по одному вопросу. Все.
То есть стоит читать сообщения других. Только и всего. Я же на русском пишу
и солнце б утром не вставало, когда бы не было меня
Re[37]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 14:04
Оценка:
Здравствуйте, Serginio1, Вы писали:

I>>Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.

S> Я не читал всю ветку у меня был вопрос только по одному вопросу. Все.
S> То есть стоит читать сообщения других. Только и всего. Я же на русском пишу

Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?
Re[38]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 15:11
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:


I>>>Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.

S>> Я не читал всю ветку у меня был вопрос только по одному вопросу. Все.
S>> То есть стоит читать сообщения других. Только и всего. Я же на русском пишу

I>Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?

Все давай закончим. Я пишу тебе про одно, ты мне отвечаешь про другое. Я тебе говорю, что ты нифига не читатель, но ты продолжаешь дальше.
Я тебе пишу
S>
S>await task(10, 1);
S>await task(10, 2);
S>await task(10, 3);
S>await task(10, 4);
S>await task(10, 5);
S>await task(10, 6);
S>write(10);
S>


S>Никаких гонок не будет.


ответ

Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?


Прошло еще куча ответов
и вдруг наконец

Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?


Охренеть, а я тут распинаюсь, ссылочки ищу итд.
Потратил кучу времени. Нахрен этот RSDN сдался
и солнце б утром не вставало, когда бы не было меня
Re[39]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 15:46
Оценка:
Здравствуйте, Serginio1, Вы писали:


I>>Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?

S> Все давай закончим. Я пишу тебе про одно, ты мне отвечаешь про другое. Я тебе говорю, что ты нифига не читатель, но ты продолжаешь дальше.
S>Я тебе пишу
S>>
S>>await task(10, 1);
S>>await task(10, 2);
S>>await task(10, 3);
S>>await task(10, 4);
S>>await task(10, 5);
S>>await task(10, 6);
S>>write(10);

Я дал тебе цельный пример кода, а ты зачем то сделал await впереди task
Я на это обратил внимание не сразу.

Речь то была не про превращение параллельного когда в последовательный, а про серилизацию доступа к ресурсу.

S>Охренеть, а я тут распинаюсь, ссылочки ищу итд.

S>Потратил кучу времени. Нахрен этот RSDN сдался

Ога, рсдн виноват да.
Re[40]: Для тех, кто смеется над JavaScript
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.20 16:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:



I>>>Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?

S>> Все давай закончим. Я пишу тебе про одно, ты мне отвечаешь про другое. Я тебе говорю, что ты нифига не читатель, но ты продолжаешь дальше.
S>>Я тебе пишу
S>>>
S>>>await task(10, 1);
S>>>await task(10, 2);
S>>>await task(10, 3);
S>>>await task(10, 4);
S>>>await task(10, 5);
S>>>await task(10, 6);
S>>>write(10);

I>Я дал тебе цельный пример кода, а ты зачем то сделал await впереди task

I>Я на это обратил внимание не сразу.

I>Речь то была не про превращение параллельного когда в последовательный, а про серилизацию доступа к ресурсу.

Вообще то все началось вот отсуда
I>>>Ты можешь заменить операции с файлом, скажем на такие

I>>>

I>>>async read(): number { return i }

I>>>async write(value: number) { i = value }

I>>>


S>>Это уже не "однопоточном исполнителе"


I>

I>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.
Откуда гонки?
 var i=await  read();
 await write(++i);



будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.

Покажи гонки если вызывается только один метод, по аналогии с однопоточным?


Ладно трачу время и нервы! нахрен. Я еще и виноват оказался.
и солнце б утром не вставало, когда бы не было меня
Re[24]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 29.06.20 19:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Собственно, атомарными будут только чтение переменной и её запись, весь цикл — чтение-инкремент-запись будет неатомарным, а следовательно, несколько параллельных цепочек сломают инвариант.


Понял, да. Вот нормальный пример, который это демонстрирует -- https://stackoverflow.com/a/37792247/241446
Кодом людям нужно помогать!
Re[36]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 29.06.20 19:48
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Але — тут вся подветка про многозадачность. Товарищ на полном серьез утверждал, что

I>

I>await серилизует доступ к ресурсу


А разве нет?

await op1()
await op2()

Не последовательно выполняться? Во всяком случае в примере с SO, который я привел выше, rc уже не будет. Поэтому работу с памятью таки сериализует.
Кодом людям нужно помогать!
Re[37]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.06.20 20:28
Оценка:
Здравствуйте, Sharov, Вы писали:

I>>Але — тут вся подветка про многозадачность. Товарищ на полном серьез утверждал, что

I>>

I>>await серилизует доступ к ресурсу


S>А разве нет?


S>await op1()

S>await op2()

Авайт выстраивает цепочку, связывает два контекста, условно — начало и конец. А серилизация доступа к ресурсу это тот самый Lock или Mutex, когда принуждаем все параллельные цепочки выстраиваться в очередь.

S>Не последовательно выполняться? Во всяком случае в примере с SO, который я привел выше, rc уже не будет. Поэтому работу с памятью таки сериализует.


Последовательно — в пределах одной цепочки. Но другие то могут спокойно обращаться к ресурсу. Что, собственно, мои примеры и показывают.
Re[38]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 29.06.20 21:33
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

S>>await op1()

S>>await op2()
I>Авайт выстраивает цепочку, связывает два контекста, условно — начало и конец. А серилизация доступа к ресурсу это тот самый Lock или Mutex, когда принуждаем все параллельные цепочки выстраиваться в очередь.
S>>Не последовательно выполняться? Во всяком случае в примере с SO, который я привел выше, rc уже не будет. Поэтому работу с памятью таки сериализует.
I>Последовательно — в пределах одной цепочки. Но другие то могут спокойно обращаться к ресурсу. Что, собственно, мои примеры и показывают.

Кто такие другие? Всего ве операции op1 и op2. Запускаем op2 строго после op1 отработает, разве нет? А вот если без await -- другое дело. И опять речь не об io, а о
переменной в памяти.
Кодом людям нужно помогать!
Re[39]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.20 07:15
Оценка:
Здравствуйте, Sharov, Вы писали:

S>>>Не последовательно выполняться? Во всяком случае в примере с SO, который я привел выше, rc уже не будет. Поэтому работу с памятью таки сериализует.

I>>Последовательно — в пределах одной цепочки. Но другие то могут спокойно обращаться к ресурсу. Что, собственно, мои примеры и показывают.

S>Кто такие другие? Всего ве операции op1 и op2. Запускаем op2 строго после op1 отработает, разве нет? А вот если без await -- другое дело. И опять речь не об io, а о

S>переменной в памяти.

Ок, начинаем сначала. Протокол доступа какой? Тебе почему то представляется i++. Такое далеко не всегда случается.

Попробуй реализовать i++ используя вот эти функции
async function read() { return global_i }

async function write(v) { global_i = v }


На самом деле нужно смотреть именно ио, т.к. взрослые приложения прибиты к нему гвоздями. Соответственно все твои i++ это попытки теоретизировать.
Re[40]: Для тех, кто смеется над JavaScript
От: Sharov Россия  
Дата: 30.06.20 08:16
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:


I>Ок, начинаем сначала. Протокол доступа какой? Тебе почему то представляется i++. Такое далеко не всегда случается.


Как в примере SO, баланс. Если расставить await перед add$50, то никаких гонок не будет. Речь не про io.

I>На самом деле нужно смотреть именно ио, т.к. взрослые приложения прибиты к нему гвоздями. Соответственно все твои i++ это попытки теоретизировать.


У нас и был концептуальный спор.
Кодом людям нужно помогать!
Re[41]: Для тех, кто смеется над JavaScript
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.20 08:30
Оценка: +1
Здравствуйте, Sharov, Вы писали:

I>>Ок, начинаем сначала. Протокол доступа какой? Тебе почему то представляется i++. Такое далеко не всегда случается.

S>Как в примере SO, баланс. Если расставить await перед add$50, то никаких гонок не будет. Речь не про io.

У них пример кривой, поэтому есть иллюзия, что авайтом все можно пофиксать и выстроить все запросы в очередь. На самом деле — нет, такого никогда не бывает. В веб приложении запросы приходят параллельно, их невозможно встроить в линеечку одним авайтом.

I>>На самом деле нужно смотреть именно ио, т.к. взрослые приложения прибиты к нему гвоздями. Соответственно все твои i++ это попытки теоретизировать.

S>У нас и был концептуальный спор.

Никакого концептуально спора — ты даже не пробовал запустить примеры.
Re: Для тех, кто смеется над JavaScript
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 05.07.20 11:13
Оценка: :)
Здравствуйте, Lazytech, Вы писали:

L>Для тех, кто смеется над JavaScript


И те, кто не смеются над JavaScript, так же далеки от него, как и те, кто смеются.

 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.