Сообщение Re[21]: язык (source of truth) будет язык схемы для этого JS от 26.06.2022 15:35
Изменено 26.06.2022 16:05 Serginio1
Re[21]: язык (source of truth) будет язык схемы для этого JS
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Ну и что? Почему это плохо?
S>> Да потому, что JS ограничен!
НС>Теперь попробуй доказать что унаследованные от него ограничения критичны для коммуникаций.
https://russianblogs.com/article/2086122683/
НС>>>Проблема в том, что натягивание системы типов статического языка на сети аналогично натягиванию той же системы типов на РСУБД. Если язык специально под это не подгонять выходит какашка. С сетями та же история. Либо протокол уродский, либо систему типов, описывающих сетевое API приходится сильно урезать.
S>> C# прекрасно натягивается.
НС>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.
Ну Nullable типы появились до Linq.
НС>>>А замапить JSON на сложные типы в 2022 году совершенно не проблема.
S>> Ну вот сам JSON анахронизм для 2022 года.
НС>Bullshit bingo! Опять пустые лозунги.
НС>>>При чем тут многопоточность?
S>> Ну при том, что в браузере нет многопоточности
НС>Какое это имеет отношение к API для сети?
А то, что HTTP/2 использует мультиплексирование
S>>и не используется двухканальный режим чтения и записи
НС>Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть
С чего так? TCP/IP на том же Web сокетах прекрасно работает.
S>>>> Ну есть gRPC и в конце концов можно gRPC-Web или сервер микс gRPC c Json
НС>>>И нафига?
S>>Для таких как ты,
НС>О, перешел на личности. Со сливом.
Не личности, таких как ты предпочитающих REST gRPC. Или все расписывать надо?
НС>>>В чем тио больше, в чем то меньше
S>>А в чем меньше?
НС>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?
А самому кэшировать никак? Да и лучше самому заняться ибо все меняется во время жизни системы. Там где уже кэширование не работает из-за появившегося нового состояния, но используется GET запрос.
HTTP/2 и протобуф перекрывает этот малюсенький велосипед. Компонентов кэширования вагон и тележка. Но если для тебя важее сетевая инфраструктура кэширования.
Ок HTTP/2 идет лесом. Но таких сценариев ооочень мало. Анахронизм
НС>>>SOAP похоронил сам себя, ибо идея OORPC нежизнеспособна. Либо получается неудобное, ненадежное и тормозное чудовище, либо SOAP урезается до крайне примитивных протоколов.
S>>А gRPC это не OORPC?
НС>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.
Ну он мультиязыковый. Там как раз типы прото прекрасно ложатся на язык.
Так же как JSON сериализация десериализация из типов тех же C#. Только вот типов значительно больше!!
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Ну и что? Почему это плохо?
S>> Да потому, что JS ограничен!
НС>Теперь попробуй доказать что унаследованные от него ограничения критичны для коммуникаций.
https://russianblogs.com/article/2086122683/
HTTP / 2 не определяет JavaScript API и не поможет вам с легкостью создать REST API. В настоящее время клиенты JavaScript, работающие в веб-браузерах, имеют ограниченное использование новых функций. Однако для обмена данными между серверами HTTP / 2 предоставляет множество способов выйти за рамки существующих API REST.
НС>>>Проблема в том, что натягивание системы типов статического языка на сети аналогично натягиванию той же системы типов на РСУБД. Если язык специально под это не подгонять выходит какашка. С сетями та же история. Либо протокол уродский, либо систему типов, описывающих сетевое API приходится сильно урезать.
S>> C# прекрасно натягивается.
НС>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.
Ну Nullable типы появились до Linq.
НС>>>А замапить JSON на сложные типы в 2022 году совершенно не проблема.
S>> Ну вот сам JSON анахронизм для 2022 года.
НС>Bullshit bingo! Опять пустые лозунги.
НС>>>При чем тут многопоточность?
S>> Ну при том, что в браузере нет многопоточности
НС>Какое это имеет отношение к API для сети?
А то, что HTTP/2 использует мультиплексирование
S>>и не используется двухканальный режим чтения и записи
НС>Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть
С чего так? TCP/IP на том же Web сокетах прекрасно работает.
S>>>> Ну есть gRPC и в конце концов можно gRPC-Web или сервер микс gRPC c Json
НС>>>И нафига?
S>>Для таких как ты,
НС>О, перешел на личности. Со сливом.
Не личности, таких как ты предпочитающих REST gRPC. Или все расписывать надо?
НС>>>В чем тио больше, в чем то меньше
S>>А в чем меньше?
НС>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?
А самому кэшировать никак? Да и лучше самому заняться ибо все меняется во время жизни системы. Там где уже кэширование не работает из-за появившегося нового состояния, но используется GET запрос.
HTTP/2 и протобуф перекрывает этот малюсенький велосипед. Компонентов кэширования вагон и тележка. Но если для тебя важее сетевая инфраструктура кэширования.
Ок HTTP/2 идет лесом. Но таких сценариев ооочень мало. Анахронизм
НС>>>SOAP похоронил сам себя, ибо идея OORPC нежизнеспособна. Либо получается неудобное, ненадежное и тормозное чудовище, либо SOAP урезается до крайне примитивных протоколов.
S>>А gRPC это не OORPC?
НС>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.
Ну он мультиязыковый. Там как раз типы прото прекрасно ложатся на язык.
Так же как JSON сериализация десериализация из типов тех же C#. Только вот типов значительно больше!!
Re[21]: язык (source of truth) будет язык схемы для этого JS
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Ну и что? Почему это плохо?
S>> Да потому, что JS ограничен!
НС>Теперь попробуй доказать что унаследованные от него ограничения критичны для коммуникаций.
https://russianblogs.com/article/2086122683/
НС>>>Проблема в том, что натягивание системы типов статического языка на сети аналогично натягиванию той же системы типов на РСУБД. Если язык специально под это не подгонять выходит какашка. С сетями та же история. Либо протокол уродский, либо систему типов, описывающих сетевое API приходится сильно урезать.
S>> C# прекрасно натягивается.
НС>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.
Ну Nullable типы появились до Linq.
НС>>>А замапить JSON на сложные типы в 2022 году совершенно не проблема.
S>> Ну вот сам JSON анахронизм для 2022 года.
НС>Bullshit bingo! Опять пустые лозунги.
НС>>>При чем тут многопоточность?
S>> Ну при том, что в браузере нет многопоточности
НС>Какое это имеет отношение к API для сети?
А то, что HTTP/2 использует мультиплексирование
S>>и не используется двухканальный режим чтения и записи
НС>Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть
С чего так? TCP/IP на том же Web сокетах прекрасно работает.
S>>>> Ну есть gRPC и в конце концов можно gRPC-Web или сервер микс gRPC c Json
НС>>>И нафига?
S>>Для таких как ты,
НС>О, перешел на личности. Со сливом.
Не личности, таких как ты (а не тебе лично) предпочитающих REST gRPC. Или все расписывать надо?
НС>>>В чем тио больше, в чем то меньше
S>>А в чем меньше?
НС>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?
А самому кэшировать никак? Да и лучше самому заняться ибо все меняется во время жизни системы. Там где уже кэширование не работает из-за появившегося нового состояния, но используется GET запрос.
HTTP/2 и протобуф перекрывает этот малюсенький велосипед. Компонентов кэширования вагон и тележка. Но если для тебя важее сетевая инфраструктура кэширования.
Ок HTTP/2 идет лесом. Но таких сценариев ооочень мало. Анахронизм
НС>>>SOAP похоронил сам себя, ибо идея OORPC нежизнеспособна. Либо получается неудобное, ненадежное и тормозное чудовище, либо SOAP урезается до крайне примитивных протоколов.
S>>А gRPC это не OORPC?
НС>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.
Ну он мультиязыковый. Там как раз типы прото прекрасно ложатся на язык.
Так же как JSON сериализация десериализация из типов тех же C#. Только вот типов значительно больше!!
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Ну и что? Почему это плохо?
S>> Да потому, что JS ограничен!
НС>Теперь попробуй доказать что унаследованные от него ограничения критичны для коммуникаций.
https://russianblogs.com/article/2086122683/
HTTP / 2 не определяет JavaScript API и не поможет вам с легкостью создать REST API. В настоящее время клиенты JavaScript, работающие в веб-браузерах, имеют ограниченное использование новых функций. Однако для обмена данными между серверами HTTP / 2 предоставляет множество способов выйти за рамки существующих API REST.
НС>>>Проблема в том, что натягивание системы типов статического языка на сети аналогично натягиванию той же системы типов на РСУБД. Если язык специально под это не подгонять выходит какашка. С сетями та же история. Либо протокол уродский, либо систему типов, описывающих сетевое API приходится сильно урезать.
S>> C# прекрасно натягивается.
НС>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.
Ну Nullable типы появились до Linq.
НС>>>А замапить JSON на сложные типы в 2022 году совершенно не проблема.
S>> Ну вот сам JSON анахронизм для 2022 года.
НС>Bullshit bingo! Опять пустые лозунги.
НС>>>При чем тут многопоточность?
S>> Ну при том, что в браузере нет многопоточности
НС>Какое это имеет отношение к API для сети?
А то, что HTTP/2 использует мультиплексирование
S>>и не используется двухканальный режим чтения и записи
НС>Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть
С чего так? TCP/IP на том же Web сокетах прекрасно работает.
S>>>> Ну есть gRPC и в конце концов можно gRPC-Web или сервер микс gRPC c Json
НС>>>И нафига?
S>>Для таких как ты,
НС>О, перешел на личности. Со сливом.
Не личности, таких как ты (а не тебе лично) предпочитающих REST gRPC. Или все расписывать надо?
НС>>>В чем тио больше, в чем то меньше
S>>А в чем меньше?
НС>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?
А самому кэшировать никак? Да и лучше самому заняться ибо все меняется во время жизни системы. Там где уже кэширование не работает из-за появившегося нового состояния, но используется GET запрос.
HTTP/2 и протобуф перекрывает этот малюсенький велосипед. Компонентов кэширования вагон и тележка. Но если для тебя важее сетевая инфраструктура кэширования.
Ок HTTP/2 идет лесом. Но таких сценариев ооочень мало. Анахронизм
НС>>>SOAP похоронил сам себя, ибо идея OORPC нежизнеспособна. Либо получается неудобное, ненадежное и тормозное чудовище, либо SOAP урезается до крайне примитивных протоколов.
S>>А gRPC это не OORPC?
НС>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.
Ну он мультиязыковый. Там как раз типы прото прекрасно ложатся на язык.
Так же как JSON сериализация десериализация из типов тех же C#. Только вот типов значительно больше!!