Здравствуйте, kaa.python, Вы писали:

vsb>>Лично для меня у Go самая фатальная проблема это система обработки ошибок. Я считаю, что исключения в сто раз лучше, чем то, что сделали в Go.

KP>В то же время подход с явной обработкой не выходит боком фактически никогда

Подход с явной обработкой выходит боком практически всегда. Ошибку либо тупо прокидывают вверх, теряя стектрейс, либо игнорируют, либо пытаются обрабатывать на месте (очень часто с багами, т.к. этот сценарий никогда не тестируют).

> в отличие от исключений, который крайне легко забыть, или не верно обработать.

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

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

S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Нет ООП. Выбрасывайте.

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

S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?

Ну, фраза "я программист на C++" заставляет девок покраснеть и дышать чаще, а то же самое про Go заставляет их лишь пожать плечами.

S>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Pzz>Ну, фраза "я программист на C++" заставляет девок покраснеть и дышать чаще, а то же самое про Go заставляет их лишь пожать плечами.
Девок QAщиц?

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

S>>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Pzz>>Ну, фраза "я программист на C++" заставляет девок покраснеть и дышать чаще, а то же самое про Go заставляет их лишь пожать плечами.
O>Девок QAщиц?

Да есть ли разница? Или ты программировать с ними собрался?

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

S>Вот, кстати, что на счет Go?

Го выбирают из-за:
1) поддержки очень крупной компанией,
2) поддержки очень крупной компанией,
3) поддержки очень крупной компанией,
4) киллер-фич и комьюнити

Первые три пункта перечёркивают его любые слабые стороны

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

Pzz>Ну, на самом деле, Go как раз позиционируется именно как язык, в котором нет и никогда не будет всех этих крутых и совершенно непостижимых фич, которыми столь славен C++.

Каких непостижимых фич? Итераторы блин непостижимые? Перегрузка оператора сравнения это непостижимо? Без перегрузки оператора сравнения зачастую нельзя использовать тип для индексирования map.

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

S>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов. Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.

Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.
Все внешние зависимости приводят к вариациям dll/libc-hell

Здравствуйте, night beast, Вы писали:

S>>>>Это тоже способ уйти от необходимости обновлять у себя используемое.
NB>>>макс, давай ты не будешь фантазировать о том, почему ушли от монолитов.
S>>Ну расскажи ты.
NB>Pzz уже изложил
Ни разу не опроверг а местами даже подтвердил.

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

I>Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.

Это не лечится. Уже были эти споры. Все уже тысячу раз доказано а у Шеридана все "Нужно сечь разработчиков плетями". Он остановился, закостенел.

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

Лучше подумать о том, что каждый из наз подвержен такой же ловушке. И надо ее избежать.

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

S>Сначала были монолиты. Чтобы решить проблему используемых при разработке либ (не всем дано вовремя обновляться, да и лень) — придумали микросервисы.

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

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

S>Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер)

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

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

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

S>А казалось бы — обновляйтесь вовремя и никаких проблем.

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

S>Вот, кстати, что на счет Go?
S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Хреновая поддержка динамических библиотек. Ее фактически нет.
Ну и наличие GC как бы намекает, что это совершенно другая ниша. Впрочем, имеющая пересечения с исторической нишей С/С++ в плане написания командлайновых полезняшек.

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

Pzz>>Пайк задумывал Go как C 2.0. Как язык для настоящих мужчин, но без недостатков C, и с достоинствами Алефа и Лимбо и с современным синтаксическим стилем, без всех этих ненужных скобочек после if'а. Но все мы знаем, что программировать на Go побежали в основном не небритые сишники, а молодые и прыщавые программисты на Питоне, не способные освоить даже JavaScript.

T>И те и другие побежали. Посмотри на список крутых OSS проектов на го, это же как раз небритые сишники

Ну, даже Пайк где-то жаловался, что они рассчитывали привлечь сишников/плюсовиков, а прибежали питонщики.

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

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

Pzz> Пайк задумывал Go как C 2.0. Как язык для настоящих мужчин, но без недостатков C, и с достоинствами Алефа и Лимбо и с современным синтаксическим стилем, без всех этих ненужных скобочек после if'а. Но все мы знаем, что программировать на Go побежали в основном не небритые сишники, а молодые и прыщавые программисты на Питоне, не способные освоить даже JavaScript.

А я слышал, что его делали для неосиливающих нормальные языки:

давайте послушаем слова самого Роба Пайка:

Фишка в том, что наши программисты гуглеры, а не ученые. Это обычно молодые, только выпустившиеся пацаны, которые возможно выучили Java, возможно даже C/C++ и может быть Python. Они не в состоянии понимать пробздетый язык, но мы все равно хотим, чтобы они делали хороший софт. Таким образом, мы даем им легкопонимаемый язык, к которому они быстро привыкнут.

Короче, нужно было хоть как-то этих обезьян утилизировать... GO!

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

Pzz>Ну, даже Пайк где-то жаловался, что они рассчитывали привлечь сишников/плюсовиков, а прибежали питонщики.

привлекать сишников языком с GC -- так себе идея

Здравствуйте, Anton Batenev, Вы писали:

AB>А зачем? Для ниши go монобинарь удобнее (в деплое и поддержке).
Насрать вообщето деплою и поддержке.
Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.

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

S>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.

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

CC>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.
Ещё раз: абсолютно насрать. Что надо — то и задеплоится. Надо один ьинарник — будет один бинарник. Надо 100500 либ впридачу — будет 100500 либ впридачу. Не программистское дело — лезть в деплой. Просто скажите что надо — то и будет.

CC>Все внешние зависимости приводят к вариациям dll/libc-hell
Это от некомпетентности того кто допустил этот самый hell.

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

S>>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
CC>>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
S>>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.

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

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

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


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

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

I>И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.
Это когда петух приходит. А когда вовремя всё — то и затраты около нуля.

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

I>Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.
Это от некомпетентности/лени. Потому что лень обновить либу, лень посмотреть/почитать чего нового появилось в мире.

Приведу пример:
Берём линупс. Буквально любой. А на больших промежутках времени (десятилетия) то и любую вообще ОС.
Устанавливаем ОС и не обновляем несколько лет. А потом обновляем. ВНЕЗАПНО возникает такая гора проблем, что для их решения реально нужны действительно дорогие специалисты и время.
А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.

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

CC>>>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.
NB>>или как альтернатива разворачивать свой докер образ

S>Это тоже способ уйти от необходимости обновлять у себя используемое.

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

S>А казалось бы — обновляйтесь вовремя и никаких проблем.

не просто обновляйся, но и заставь всех клиентов обновляться. причем на ту версию, что поставилась в твоей системе.
в реальной жизни это почему-то не работает

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

I>>>Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.
S>>Решение подсказать? Нужно свой софт писать так, чтобы использовал те версии либ, которые есть в дистрибутиве. А если нет такой либы вообще, то в свой репозиторий складывать в виде зависимости к пакету с твоим софтом. А заказчику давать линк на свою репу, которую надо подключить ему к дистрибутиву чтобы потом стандартными средствами установить ваш софт.
I>В любом случае конфигурация финишного деплоймента на момент разработки неизвестна. И в конце спокйно может оказаться мешанина вида "софтина-плагины-еще-софтина-еще-плагины" имее взаимоисключающие требования.
Всмысле неизвестна? Как софт должен установиться и как работать уже должно быть известно ещо до первой строки кода, на проектировании. Окружение по мере разработки да, может поменяться. Наприер, используемая БД или средства мониторинга. Но чем ближе к финишу, тем всё более точно известно и окружение.
При этом деплой пишется сразу, параллельно разработке. И этим кодом деплоя выкатывается продукт на stage сервера.


I>>>Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?
S>>Если заказчик платит деньги чтобы ваш софт появился в его дистрибутиве то вам нужно опакетить ваш софт для того дистрибутива.
I>Заказчик платит не за софт в дистрибутиве, а за решение конкретной его проблемы. all-in-one это хороший вариант исключить проблемы с шаред/транзитивными зависимостями.
Определитесь уже. То заказчик не может на свои сервера поставить для вашего продукта нужную ОС (из списка популярных и заведомо стабильных), то ему побоку на ОС и ему надо решить некую проблему. Взаимоисключающие пункты.


S>>У меня значит получалось выяснить что и почему не работает (и это включало в себя например сборку подправленного постгреса с дополнительным дебаг-логом). А у настоящих тру-программистов-профессионалов лапки.
I>Снова тебе программисты мешают.
Я чтото не так сказал? Программисты умеют находить корни проблем и исправлять их? Если да, то к чему этот разговор? Срач ради срача?


I>>>Похоже, ты уже начал кое что понимать.
S>>Я изначально к этому вёл, но у тебя закостенение "шеридан-долбоклюй-непрофессионал" и это мешает тебе воспринимать то что я пишу.
I>Здесь ровно наоборот- ты по пять раз на сообщении утверждашь, что с прграммистами чтото не то.
Конечно чтото не то. Вас послушать так программист умеет только код в студии набирать. Чуть чтото не так и сразу у него лапки.


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


S>>Ну то есть никто на протяжениии нескольких лет не чинит баги означает что либа полностью и адекватно поддерживается автором?
S>>Г — лоГика.
I>Да, бывают такие баги, которые трудно воспроизводятся, или их фикс ломает обратную совместимость. БОлее того — приоритеты в разработке никто не отменял. А в опен-сорсе тебе никто ничего не должен.
Это ты к чему? Да, такие баги бывают. Но как это относится к тому что автор забил на свой проект и несколько лет его вообще не сопровождает?


I>>>У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?
S>>Опиши так как у тебя проявляется. Надеюсь ты сам понимаешь, что это поможет автору баг исправить.
I>Это только с детскими багами так, когда сразу ясно где он, и как его воспроизвести. А слишком часто баг в одном месте, а причина — в противоположном, и появляется не сразу, а время от времени, через пару дней и последствия
То у тебя тот же баг в другом месте. То у тебя баг вообще неуловимый. Сколько у тебя обуви то?


S>>А как ещо назвать разрабов, которые говорят "если на баг никто не отвечает, то ты неправ что либа не поддерживается автором а наоборот."?
I>А это норма в опен-сорсе — игнорить баги. Заходишь зарепортать в популярный репозиторий, а там булькают вещи еще с нулевых.
Если брать к себе в проект либу которую когдато вася пуповкин написал для себя то так и будет. И часто у вас ошибки выбора используемых либ? Как часто вы хватаете первое попавшееся а потом "ойвей, а либа то мёртвая!"?.


I>>>Выглядит как юношеский максимализм. Я и моя команда и без тебя все это делаем.
S>>Если вы и так это всё делаете, то какого Иакова вы мне тут мозги полоскаете? Так и напиши "да, мы этим занимаемся, но по мере возможностей". И вопросов не будет. Срач ради срача?
I>Так я не сужу по себе.
Вот только не надо говорить мне что если весь мир называет белое чорным то и я обязан это делать.


I>>>Зато факт в том, что большинство долгоиграющих проектов такой роскоши позволить себе не могут. Причины самые разные. И только ты один обвиняешь разрабов в некометентности. Тут похоже весь мир живет не по твоим правилам
S>>Причин две: лень и некомпетентность. Я бы добавил третью: недальновидность. Но программисту бизнес-бабки-платит-я-кодю этого не понять.
I>Снова программисты виноваты.
Не все, а только те, которые тупы.

I>У тебя похоже риск и инцидент это одно и то же.
Нет. Но тебе же важно набросить на вентилятор.

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

S>>Макака одно приложение сваяет на образе одно версии убунту, второе на образе другой версии, третье на образе какой-нибудь sles11 (ибо нужные компоненты только под неё есть). И пропали твои слои
V_>Что, у вас нет человека, который Docker image не может написать, сохранив путь макаки на требуемом образе?
V_>Переделать под общий корпоративный стиль, какой нибудь Alpine, scratch или distroless ?
V_>Это не та проблема, о которой-то и упоминают, вообще. Делают, и работает.
V_>Тем более, что, собралось раз и, порядок.
А что мешает то сделать второй шаг и поддерживать свежие версии либ для проектов? Тогда и докер не нужен то будет.

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

H>А общие данные и методы можно вынести в общего абстрактного предка. Или отдельно в общего мембера.
Не должно быть общих методов. Если есть общая функциональность — вынести её в отдельный класс и использовать композицию.

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

NB>>я же пример приводил -- команды гет в одну сторону, другие в другую.

_>Да, прошу прощения, что пропустил это тогда, хотя ещё тогда должен был среагировать. Собственно реакция:
_>А зачем собственно может понадобится подобная сомнительная балансировка?

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

NB>>как ты это будешь в grpc делать?

_>Если мне вдруг всё же понадобится реализовывать подобное (крайне сомневаюсь в полезности подобной задачи), то я просто поделю весь сервис на две части (с мутабельными и иммутабельными функциями), разместив их соответственно по разным адресам (т.е. так весь gRPC сервис живёт на одном URL, а так будет на двух).

то есть будешь колхозить, о чем и речь.

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

Pzz> R>давайте послушаем слова самого Роба Пайка:

Pzz> R> Фишка в том, что наши программисты гуглеры, а не ученые. Это обычно молодые, только выпустившиеся пацаны, которые возможно выучили Java, возможно даже C/C++ и может быть Python. Они не в состоянии понимать пробздетый язык, но мы все равно хотим, чтобы они делали хороший софт. Таким образом, мы даем им легкопонимаемый язык, к которому они быстро привыкнут.

Pzz> R>Короче, нужно было хоть как-то этих обезьян утилизировать... GO!

Pzz> Вот тут он врет. Перед кем, хоть, выступает-то?

Lang.NEXT 2014. From Parallel to Concurrent. Вот именно этот отрывок...

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

S>Ну как бы, на секундочку, это минус. Негоже в рамках одного проекта держать зоопарк подпроектов на разных языках. Нет, оно конечно можно, если смысл есть и профит, но мультиязычность ради мультиязычности — никуда не годится.
S>Такой себе аргумент, короче.
Ну, во-первых, я там ниже пояснил, что "что угодно" в контексте enterprise-проекта запросто может оказаться тупо разными версиями одного и того же рантайма.
S>Вот разве что если речь идет про модули-плагины которые можно под ваш сервис самостоятельно писать — то да, мультиязычность будет плюсом. И это пожалуй единственное место где оно действительно оправдано.
Во-вторых, в рамках достаточно крупной компании, всё примерно так и есть. Нет никакого "вашего сервиса", а есть огромная платформа, в которой варится огромное количество разного кода. И контрибутят в код этого решения с десяток различных команд, которые разбросаны по всему глобусу, и зачастую между собой вообще незнакомы.
Нет, если этого монстра пишет и маинтейнит одна небольшая сплочённая команда в пару десятков человек, то плодить вавилон будет неэффективно. Как раз потому, что трудно её укомплектовать сотрудниками, каждый из которых может и в питон, и в джаву, и в тайпскрипт, и в го, и в раст, и в сишарп, и в sql, и в редис, и в монгу, а заодно хорошо понимает HTML5 и css с его less/sass вариантами.
Но даже в этом случае имеет смысл смотреть в перспективу: а не захотим ли мы отдать часть рутинной разработки в какой-нибудь регион с дешёвой рабочей силой?
Какие-то куски у нас будут вычислительно сложными, с тяжёлыми алгоритмами — там нам будут нужны крутые спецы, которые умеют пользоваться профайлерами, и понимают не только синтаксис своего ЯП, но и особенности его компиляции в нативный код и тонкости всяких эффектов типа кэширования и многопоточности.
А какие-то куски — это одноразовые лендинги типа "зарегистрируйтесь на нашу конференцию и получите 12 часов VM бесплатно". Тратить силы вот этих вот бородатых парней с двумя PhD в несмежных областях — оверкилл.
Пусть там студенты за миску плова это делают, и пусть это будет на чём угодно.

То есть в мс-архитектуре вся система и состоит из "модулей-плагинов". Те же самые идеи, что и в компонентной архитектуре, популярной 30 лет назад, только механика взаимодействия теперь построена не на RPC или CORBA, а на HTTP.
И, да, называть вот это "проектом" — неверно. "Проект" — это ограниченная во времени активность, у которой есть фиксированный набор ожидаемых результатов.
А рамках подобного решения параллельно выполняются десятки/сотни "проектов". Вот как раз "добавить лендинг для регистрации на саммит" — это проект. В рамках него принимается набор независимых решений по выбору технологического стека, без оглядки на Главного Архитектора Всей Системы и остальные команды. При этом никакими "подпроектами" они не являются — у них независимый жизненный цикл.

Это в монолите у нас есть цикл релизов, и кто-то должен решить, что войдёт в версию 67, а что не войдёт. И все команды должны успеть прибежать к общему дедлайну; и приходится принимать трудные решения типа задержать релиз ешё на месяц, или выпилить какой-то из "подпроектов" (с риском потратить ещё больше времени на тестирование "системы без лендинга"). А если задерживать ещё на месяц — появляется искушение всунуть в релиз что-то ещё сверх исходного скоупа, а то те команды, которые уже всё сделали, будут простаивать (ну или ведь крайне же обидно, когда в бранче уже готова ещё одна фича, которая нам будет приносить +XXX бабла в месяц; по плану она выйдет только в версии 68 ещё через год. Релиза-то ещё нет, так давайте вкатим её в 67 и заработаем на 11*XXX больше долларов).

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

S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?

Укуренная система типов. Слабые средства метапрограммирования, отсутствие статического полиморфизма. Набор библиотек слабоват.

Парадигма обработки ошибок приводит к бойлерплейту. В целом, средства абстракции слабоваты, например итераторов — нет, и никак не сделать.

Моё резюме: берите го, если вам позарез нужны горутины. В остальных случаях не рекомендую. Да и в том же C++ тоже есть корутины, только с более мудрёным синтаксисом, явной передачей контекста и т. д., короче в го корутины реально удобнее.

Лично для меня у Go самая фатальная проблема это система обработки ошибок. Я считаю, что исключения в сто раз лучше, чем то, что сделали в Go.

В остальном язык классный.

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

o> Хреновая поддержка динамических библиотек. Ее фактически нет.

А зачем? Для ниши go монобинарь удобнее (в деплое и поддержке).

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

vsb>Лично для меня у Go самая фатальная проблема это система обработки ошибок. Я считаю, что исключения в сто раз лучше, чем то, что сделали в Go.

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

S>>>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Pzz>>>Ну, фраза "я программист на C++" заставляет девок покраснеть и дышать чаще, а то же самое про Go заставляет их лишь пожать плечами.
O>>Девок QAщиц?
Pzz>Да есть ли разница? Или ты программировать с ними собрался?
Девка QAщица, узнав что ты С++сник — может внезапно достать изза пазухи десятидюймовый pentesting tool.

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


S>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
CC>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов. Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.

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

S>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
CC>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
S>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.

Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?

Надо вспомнить, что стоимость труда разработчиков выросла до небес, а стоимость стораджа упала ниже плинтуса, при этом сложность софта растет непрерывно.

> Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.

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

Больше всего проблем доставляют шаред и транзитивные зависимости. Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку что не всегда возможно, писать тикеты и ждать фиксов, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию.
Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат, и часто абсолютно непредсказуемо по продолжительности.
И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.

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

Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.

Здравствуйте, night beast, Вы писали:

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

CC>>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.

NB>или как альтернатива разворачивать свой докер образ
Это тоже способ уйти от необходимости обновлять у себя используемое.
Смотри:
Сначала были монолиты. Чтобы решить проблему используемых при разработке либ (не всем дано вовремя обновляться, да и лень) — придумали микросервисы.
Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер)
А теперь и докер перестал устраивать. Поэтому с одной стороны появляются языки, где секут плетями за "не такой" код и либы вкомпиливаются в бинарник (сабж). А с другой стороны пилят кубернетес чтобы хоть както управлять контейнерами и их версиями.
А казалось бы — обновляйтесь вовремя и никаких проблем.

Здравствуйте, night beast, Вы писали:

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

S>>А казалось бы — обновляйтесь вовремя и никаких проблем.
NB>не просто обновляйся, но и заставь всех клиентов обновляться. причем на ту версию, что поставилась в твоей системе.
NB>в реальной жизни это почему-то не работает
Причины я уже назвал

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

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

Именно потому, что на машине может крутиться чтото еще, стоит использовать, как вариант, all-in-one.

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

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

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

Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
Я выбрал апгрейд на OutOfMemory,т.к. выяснил, что это ошибка — бросается не то исключение. Это стоило примерно один месяц — перебрать версии, идентифицировать проблемы, подебажить, выбрать нужную, протестировать, понаписывать сто заплаток и вкомитать.

I>>Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат.
S>Про трудозатраты я уже сказал. Про квалификацию: что, серьёзно настолько всё плохо что программисты разучились читать ченгджлоги и пользоваться поиском? Серьёзно?

К твоему сведению, в ченджлогах пишут зафикшеные баги, а не новые неизвестные.

I>>И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.
S>Это когда петух приходит. А когда вовремя всё — то и затраты около нуля.

Это голословно.

S>Ты придумал высокие затраты и теперь пишешь про то что можно сделать вместо них. И выглядит всё логично и правильно.
S>Только вот высокие затраты ты придумал. В этом проблема.

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

> Это от некомпетентности/лени. Потому что лень обновить либу, лень посмотреть/почитать чего нового появилось в мире.

См выше про содержимое ченджлога.

S>А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.

Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.
Когда проблема в общих/транзитивных зависимостях, не существует способа гарантировано безопасно перекатиться на новую версию. Отвалилась кучка тестов и все решилось небольшим багфиксом — это идеальный случай.
Проблема не в девелоперах, в новых, неизвестных проблемах которые содержатся в новых версиях. Писать без багов пока что только шериданы умеют, и то на словах.

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

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

I>>>Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?
S>>Может это программисты деплой не понимают? Может это программисты не понимают что на машине может крутиться не только их, безусловно божественный, проект?
I>Именно потому, что на машине может крутиться чтото еще, стоит использовать, как вариант, all-in-one.
Нет. Это должно происходить когда все остальные шаги (такие как обновления библиотек в своём проекте) предприняты и не помогла.


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


S>>Когда проепустили пару десятков версий а потом пришол петух с вооот таким клювом и таки клюнул — то да. Очень трудозатратный процесс. Потому что надо в кратчайшие сроки сделать работу, которую надо было делать на протяжении нескольких лет.
I>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
Написать баг авторам либы и не переходить пока он не будет починен.


I>>>Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат.
S>>Про трудозатраты я уже сказал. Про квалификацию: что, серьёзно настолько всё плохо что программисты разучились читать ченгджлоги и пользоваться поиском? Серьёзно?
I>К твоему сведению, в ченджлогах пишут зафикшеные баги, а не новые неизвестные.
Для них есть багтрекер. Выше только что написал.


I>>>И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.
S>>Это когда петух приходит. А когда вовремя всё — то и затраты около нуля.
I>Это голословно.
Нет, так делают люди, у которых процесс поставлен нормально а не "и так сойдёт".


S>>Ты придумал высокие затраты и теперь пишешь про то что можно сделать вместо них. И выглядит всё логично и правильно.
S>>Только вот высокие затраты ты придумал. В этом проблема.
I>Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.
ВНЕЗАПНО, я тоже. И я знаю, что если обновления планировать и выполнять в запланированное время (хотя бы раз в квартал), то затраты сильно ниже, чем обновляться только тогда когда приходит петух со своим клювом.


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


S>>А вот если обновлять ОС хотя бы раз в месяц — то и проблем не будет. Либо для их решения достаточно обычного приходящего админа.
I>Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.
Я понял, ты теперь прицепился к возможным багам и не отцепишся. Багтрекер, друже, бааагтрееекер.

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

S>>>Может это программисты деплой не понимают? Может это программисты не понимают что на машине может крутиться не только их, безусловно божественный, проект?
I>>Именно потому, что на машине может крутиться чтото еще, стоит использовать, как вариант, all-in-one.
S>Нет. Это должно происходить когда все остальные шаги (такие как обновления библиотек в своём проекте) предприняты и не помогла.

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

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

Как я вижу, у нас есть Шеридан, который не в курсе что на этапе разработки нет сведений из будущего
1. кто куда чего может задеплоить
2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей?

I>>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
S>Написать баг авторам либы и не переходить пока он не будет починен.

Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии.
А потом заходишь ты в гитхаб либы, и видишь, что эта проблема булькает уже три последних года.

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

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

I>>Это голословно.
S>Нет, так делают люди, у которых процесс поставлен нормально а не "и так сойдёт".

Шериданы что ли?

I>>Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.
S>ВНЕЗАПНО, я тоже. И я знаю, что если обновления планировать и выполнять в запланированное время (хотя бы раз в квартал), то затраты сильно ниже, чем обновляться только тогда когда приходит петух со своим клювом.

Это какие то общие слова вида "хорошее лучше плохого".

I>>Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.
S>Я понял, ты теперь прицепился к возможным багам и не отцепишся. Багтрекер, друже, бааагтрееекер.

Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку.
В каждом проекте либы/фремворка есть кучка вечно живых багов, которые никто не берется фиксать, потому что
1. фикс ломает обратую совместимость
2. есть проблемы более приоритетные
Тем, для кого такой баг стал критичным, можно только посочувствовать.

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


S>Как по мне — контейнеры нужны в паре случаев всего:
S>1. Для разработки, чтобы не захламлять рабочую машину всевозможными кроликами, постгрями, мускулями итд
S>2. Когда нужно уметь разворачивать мощности при возрастании нагрузки и сворачивать обратно потом (aws тотже)

Есть ещё третий вариант, и именно он обеспечил массовость популярность контейнеров и докера в частности. Это когда сидит макака, ваяет у себя на локалхосте на последней убунту приложение, тащит для этого кучу всякого разношерстного и разноверсионного хлама из самых разных реп, самыми разными пакетными менеджерами, отличными от штатного (pip-ы, npm-ы). Поучается нагроможение и мессиво. Работать будет только у него на локалхосте. А нужно чтоб работало где-то на любом сервере, в закрытом или публичном облаке. Что делать? Завернуть всю эту кучу вместе с загаженным обазом ОС в контейнер, и этот контейнер можно уже запускать где угодно. А то, что вместе с жалкими 10KB творения макаки на каждый сервер тащится ещё 500MB образа ОС, то это макаку не волнует, а провайдеры только за-повышенное потребление ресурсов клиентами для них прибыль.
Контейнеры, их необходимость и популярность-это деградация именно культуры разработки ПО.

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

S>ЧСХ, я сразу написал что в гошечке нет ООП и потому надо закапывать. Но пытаются из-за этого закопать меня

Закапывать надо ООП, а не гошечку.

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

S>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
S>Нет ООП. Выбрасывайте.

ООП? Согласен.

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

I>>Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.
S>Решение подсказать? Нужно свой софт писать так, чтобы использовал те версии либ, которые есть в дистрибутиве. А если нет такой либы вообще, то в свой репозиторий складывать в виде зависимости к пакету с твоим софтом. А заказчику давать линк на свою репу, которую надо подключить ему к дистрибутиву чтобы потом стандартными средствами установить ваш софт.

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

I>>Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?
S>Если заказчик платит деньги чтобы ваш софт появился в его дистрибутиве то вам нужно опакетить ваш софт для того дистрибутива.

Заказчик платит не за софт в дистрибутиве, а за решение конкретной его проблемы. all-in-one это хороший вариант исключить проблемы с шаред/транзитивными зависимостями.

S>У меня значит получалось выяснить что и почему не работает (и это включало в себя например сборку подправленного постгреса с дополнительным дебаг-логом). А у настоящих тру-программистов-профессионалов лапки.

Снова тебе программисты мешают.

I>>Похоже, ты уже начал кое что понимать.
S>Я изначально к этому вёл, но у тебя закостенение "шеридан-долбоклюй-непрофессионал" и это мешает тебе воспринимать то что я пишу.

Здесь ровно наоборот- ты по пять раз на сообщении утверждашь, что с прграммистами чтото не то.

I>> Смешно. У тебя похоже экономическая составляющая вообще в рассуждениях не присутствует. С чего ты взял, что влегкую фиксанешь произвольную либу?
S>А я говорил что это будет легко? Я сказал что если либа не поддерживается больше, то выполнить один из этих двух пунктов тупо придётся. Ты будешь с этим спорить? Ты правда программист?

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

S>Ну то есть никто на протяжениии нескольких лет не чинит баги означает что либа полностью и адекватно поддерживается автором?
S>Г — лоГика.

Да, бывают такие баги, которые трудно воспроизводятся, или их фикс ломает обратную совместимость. БОлее того — приоритеты в разработке никто не отменял. А в опен-сорсе тебе никто ничего не должен.

I>>У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?
S>Опиши так как у тебя проявляется. Надеюсь ты сам понимаешь, что это поможет автору баг исправить.

Это только с детскими багами так, когда сразу ясно где он, и как его воспроизвести. А слишком часто баг в одном месте, а причина — в противоположном, и появляется не сразу, а время от времени, через пару дней и последствия
Соответственно, такие вещи тестами просто так не возьмешь.

S>А как ещо назвать разрабов, которые говорят "если на баг никто не отвечает, то ты неправ что либа не поддерживается автором а наоборот."?

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

I>>Выглядит как юношеский максимализм. Я и моя команда и без тебя все это делаем.
S>Если вы и так это всё делаете, то какого Иакова вы мне тут мозги полоскаете? Так и напиши "да, мы этим занимаемся, но по мере возможностей". И вопросов не будет. Срач ради срача?

Так я не сужу по себе.


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

Снова программисты виноваты. У тебя похоже риск и инцидент это одно и то же.

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

НС>>Да. Про контейнеры слышал?
CC>Предлагаешь каждую софтину запихивать в контейнер?
CC>А не дороговато ли выйдет?
Да ну откуда? Контейнеры же из слоёв; как я понял — слои повторно используются.
Поэтому если у тебя на железке 30 контейнеров с аппликухами построены на одном и том же дистрибутиве, и в 20 используется питон, а в 10 — go, то физически на диске будет лежать 1 питон и 1 го.
Если кому-то потребовался питон 2.7, а не 3.1, то появится 1 экземпляр питона 2.7, при этом он никак не помешает тем 20 аппликухам, которым нужен питон 3.1.

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

S>Падажжите. Разве там не будет слой незагаженного образа ОС...

Макака одно приложение сваяет на образе одно версии убунту, второе на образе другой версии, третье на образе какой-нибудь sles11 (ибо нужные компоненты только под неё есть). И пропали твои слои

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


V_>Что, у вас нет человека, который Docker image не может написать, сохранив путь макаки на требуемом образе?

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

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

V_>>Я за этим не слежу, у всех разные требования к либам. Чтобы все оптимизировать до одного слайса, у нас есть много других, более актуальных дел. Префекционизм любой ценой — зло
S>Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
Учитывая, что дистрибутивы Линукса пишут жопорукие, то да. Ни одному из них доверять вообще нельзя без того, чтобы 10 раз протестировать на staging с постепенным сдвигом трафика на production.

Вот из-за этой реальности и приходится использовать Docker/k8s. Если бы дистрибутивы не писали полные идиоты, то может быть такое и возможно было бы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Неадекватность современным задачам, плохо работающие идеи.
S>>эммм... Можешь более подробно пжлст?

НС>Могу
Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно? Что с эволюцией делать будем?
Ну и вообще там всё такое.. "А может быть, а может и не быть". В челом написано умно но ничего существенного.
Ну отсутствуют какието формализованные правила — ну так их и нигде нет.
OO is Xenophobic — вообще фантастический аргумент

В общем, автор очень хочет очернить ООП, явно видно.

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

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

Это не бизнес требование. Это не всегда нужно, не всегда целесообразно и, часто, вредит. Уже 100 раз написали про эту твою религиозную догму.
В реальной жизни это не применяется, что доказывает, что в реальных проектах тебя нет и самозвание словом "специалист" — абсурдно и смехотворно.

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

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

_>1. Максимально убогая сериализация. Т.е. в том же gRPC используется далеко не идеальный Protocol Buffers (например MessagePack намного эффективнее), но по сравнению со стандартным подходом сериализации из REST, это просто мегашедевр эффективности. )))
Да, хороший поинт. Впрочем, сам REST ничего про сериализацию не говорит. Если state, который мы передаём, хорошо описывается MessagePack, то почему бы не передавать его MessagePack?
Но есть у меня подозрение, что для REST MessagePack мало что даст. Ну, из банального — там есть очевидный, механический способ построить delta-encoding?

_>2. Несимметричные возможности у клиента и сервера. По сути REST — это однонаправленный протокол, в то время как в gRPC после установки соединения сервер может спокойно инициировать отсылку данных клиенту.
Ну, сделать reliable two-way state transfer ещё тяжелее, чем однонаправленный. Я пока что не очень представляю себе задачу, где это было бы уместно с точки зрения архитектуры.
То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...

_>3. Одновременная и убогость и излишество базовых методов REST (которые наследие HTTP). Это наверное самый важных архитектурный пункт, так что поясню подробнее. При использование REST возможны два разных архитектурных подхода:
_>- использование базовых методов в качестве набора команд (API) нашего сервиса. Очевидно, что это подходит только для максимально простеньких задач, целиком укладывающихся в CRUD. И тут чувствуется вся убогость этого набора команд.
Нет конечно. Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл.
В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.

_>- использование удобного нетривиального API, реальные команды которого передаются в REST запросах в качестве данных (параметров). Т.е. в этом случае REST уже служит просто очередным сетевым слоем (ниже прикладного), правда достаточно не эффективным. И в этом случае наоборот очевидно излишество базовых методов (в принципе одного POST достаточно для передачи любой прикладной команды).
Это банальный антипаттерн. Никакогог REST тут нету, а есть RPC over HTTP. Его крайним развитием является SOAP, место которого — в аду.

_>В целом меня совсем не удивляет происходящий сейчас переход на gRPC. Меня скорее удивляет почему индустрия не сделала этого намного раньше, потратив десятилетие на REST убожество.
Хм. Пока что не вижу аргументов, кроме какого-то непонимания REST.

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

_>Ну для начала не стоит забывать про то, что в REST у тебя для части данных жёстко определён способ сериализации, причём максимально убогий — urlencoded .
А что у нас в gRPC? Там же внизу тот же HTTP, то есть адресация по прежнему через URL.

_>А далее, даже если мы возьмём MessagePack и HTTP/2 для REST, то это всё равно не позволит нам получить сравнимую эффективность из-за наличия в gRPC такого "типа данных" как stream. Который позволяет отправить множество сообщений в рамках одного запроса (а не проводить весь комплекс установки ip, tcp, http, ssl соединений для каждой маленькой пачки данных).
Не очень понятно, что нам помешает отправить в REST пачку данных в рамках одного запроса или реквеста.
Большинство REST-данных именно так и устроены. Более того — в RPC вы не сможете получить сравнимую с REST эффективность из-за отсутствия conditional get и delta encoding.

_>Эээ что? )
Сказать серверу "данные вплоть до 18.02 у меня уже есть. Если есть что-то новее — то пришлите разницу. Если нет — то достаточно просто 304".

_>Могу привести тебе пример такой задачи. Более того, решаемой прямой сейчас в работающих системах именно таким способом. Например это получение клиентом данных о биржевой торговле (стакан и т.п.) в реальном времени.
Ну, про биржевую торговлю я не специалист. Те клиенты, которыми я пользовался, работают поверх REST. Никакого gRPC. Но я понимаю, что там всё для людей — роботам нужно что-то другое; для чего вебхуки категорически не подойдут.
S>>То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...

_>Типа если клиент с REST ляжет, то это как-то поможет не забыть отреагировать в нужный момент на текущие данные? )))
Типа если REST-клиент ляжет, это никак не повлияет на поведение сервера. А ставить поведение всей системы в зависимость от того, смог ли клиент получить данные немедленно или нет — это путь к катастрофе.

_>Ну вот тебе простейшая (и опять же из вполне реальной практики) задачка. Есть шаговый манипулятор со свободным вращением (но без энкодера). И соответственно у управляющей им схемы есть две команды: move_left() и move_right(). Доступ к этому через RPC очевидно выглядит полностью естественно — прямо как и реальные команды. А вот как по твоему будет выглядеть логичный REST вариант интерфейса? )))
Погодите, у вас где-то за океаном стоит шаговый манипулятор, и вы хотите управлять им через RPC, я правильно понял?
И вас никак-никак не беспокоит то, что вы не имеете представления о его текущем положении?
По-моему, эта схема архитектурно обречена. Чтобы спроектировать нормальное решение, надо начать плясать от задачи, а не от "у нас есть шаговый манипулятор, бутылка виски и два билета на бейсбол. Какой API нам выставить для всего этого?".

_>Ну возможно это мои личные субъективные ощущения (а индустрия возвращается к RPC по каким-то другим причинам), а возможно ты слепой (не видишь аргументов, а они есть). Не знаю.
Мне вот кажется, что индустрия просто так и не перешла на REST. Ну, то есть кто-то продолжал пилить RPC over HTTP, называя его REST — вот эти люди, понятное дело, с большим облегчением переезжают на всякие gRPC и MessagePack.

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

_>Что и? В gPRC это возможно в рамках одного соединения, а в REST нет.
Возможно, хотя и с натяжкой.

_>Так встроено или надо допиливать сервер?
Встроено в протокол. Реализация в сервере — дело добровольное.
_>Ты вот это сейчас серьёзно? ) Ты считаешь, что при запросе коллекции данных никому не придёт в голову указывать в запросе её срез и все будут возвращать только коллекцию целиком? )))
Конечно. Именно так. Давайте посмотрим на ваш "реальный пример" и убедимся, что, к примеру, в https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest не предусмотрено никакого способа запросить "изменения цен с прошлого запроса".
Только коллекция целиком. И так всё и везде.

_>Ой, т.е. оказывается уже целая большая область обнаружилась, где REST сливает RPC?

А кто же у нас вот только что писал:
_>

_> Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл. В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.

_>И вот уже "неожиданно" оказывается что не "во всех случаях"? )))
Ну так это же как раз несложная задача.

_>А если дальше пойдём разбираться, то вообще окажется что всё наоборот... )))
Не, если мы пойдём дальше разбираться, то как раз и окажется, что RPC уместен там, где не нужна надёжность.

_>Да, кстати, у ребят в указанном примере ещё год назад был REST интерфейс (OpenAPI и всё такое)... )))
Во-первых, почему "был"? Вот он и сейчас есть: https://tinkoff.github.io/invest-openapi/rest/
Во-вторых, он никакой не REST. Это легко понять, посмотрев на список глаголов. У них все операции сделаны через POST — это как раз означает, что архитекторы тинькова — недоучки, и про REST не поняли ничего.
Это подтверждает мою гипотезу — на gRPC переходит не вся индустрия, а те, кто не осилил REST.

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

_>Да я смотрю ты и в этой области специалист.
Не надо быть специалистом, чтобы понять, как это будет работать. Во времена моей юности мышки были "продвинутым оборудованием", и часть народу на полном серьёзе утверждала, что в кваку можно играть и с клавиатурой.
Сетевой режим расставил всё по своим местам — мышевозы вытеснили клавишников.
Впрочем, мы же рассуждаем о воображаемой задаче. Вообразить-то можно всё что угодно — и пользователя, которому безразлично, в какую сторону смотреть. И оборудование, где на веб-камеру денег хватило, а на енкодер (или хотя бы оптопары для детектирования нулевого положения) — нет.
Я вот могу вам поверх вашей воображаемой задачи предложить другую, на которой ваше "очевидное" решение тут же сольётся: я хочу написать робота, который каждый час заходит в этот API, делает снимки с шагом в 15 градусов, и склеивает из них панораму. При этом связь, как обычно, ненадёжная, а каждая панорама должна быть корректной и выровненной по углу — я потом склею из неё time-lapse.

Если посмотреть с точки зрения архитектуры, то у вашей задачи и HFT есть одна общая черта: мы пренебрегаем ненадёжностью сети. В одном случае — потому, что мы готовы переплачивать за надёжность сети. В другом — потому что нам наплевать на результат. Ну, как eventual-to-never consistency: даже если у нас какой-то из визитов на страницу и не запишется в лог — ничего страшного.
_>Оу, видеопоток через REST... Это прямо максимально интересно становится.
А что вас удивляет? Сейчас так делают более-менее все. Вот, пару недель назад жена участвовала в конференции удалённо. Аудиовидеостриминг в реальном времени.
Благодаря тому, что это было сделано через REST, мы смогли записать полное видео — причём на второй день, записали и первый и второй дни.
Потому что вот так вот устроен стриминг — это не fire-and-forget протокол вроде UDP или RTP, а честный HTTP, причём именно в стиле REST. То есть там лежит некоторый ресурс, который мы можем "читать", а кто-то одновременно дописывает новые данные в хвост этого ресурса.
_>Эээ что? ) Весь смысл всего это в том, чтобы человек пейзажики смотрел...
Это вам сейчас так кажется. А потом выяснится, что человеку интересно, на север он смотрит, или на юг. И что его раздражает невозможность прицелиться в нужную сторону из-за лагающей обратной связи и теряющихся prev/next.
Даже формы опросников, сделанные в RPC стиле, раздражают до неимоверности (это те, где нельзя сделать back в браузере, а надо непременно жать кнопку "Назад").

_>Какого ещё архитектурного решения? У тебя есть физическая железка с заданными параметрами (условно двумя кнопками влево/вправо и кнопкой включения камеры, возвращающей поток кадров) и надо приделать к ней удалённый доступ.

_>Архитектуру можешь плодить какую хочешь. Но ты уже показал, что в рамках REST подхода ты можешь только слиться с невнятными оправданиями.
Почему же? я прикручу к этой железке датчик нуля, сделаю процедуру инициализации, и выставлю REST-протокол по управлению положением.

_>Это просто инструмент переходного периода. Когда хочется перейти на быстрые современные решения, но при этом надо поддерживать ещё и клиентов с устаревшими подходами...

Посмотрим, посмотрим.

Здравствуйте, night beast, Вы писали:

_>>И я даже не буду говорить о том, что в реализацию gRPC уже встроена автоматически работающая клиентская балансировка (https://github.com/grpc/grpc/blob/master/doc/load-balancing.md). Предположим что этого всего нет и будем говорить только о серверной балансировке. И так, зачем для неё нужна формализация команд?
NB>я же пример приводил -- команды гет в одну сторону, другие в другую.

Да, прошу прощения, что пропустил это тогда, хотя ещё тогда должен был среагировать. Собственно реакция:

А зачем собственно может понадобится подобная сомнительная балансировка?

NB>как ты это будешь в grpc делать?

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

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

_>>Ой, ну к чему эти глупые фантазии))) Двухсторонний канал банально невозможен в REST.
S>Формально — да, у нас любой запрос в REST является "атомарным". Делаем GET, рассчитываем на хидер Content-Length, вычитываем указанное количество байт, и только потом начинаем разбор.
S>Однако мы можем несколько отступить от строгих требований, и в ответ на GET получить поток структурированных фрагментов, которые мы будем разбирать, не дожидаясь окончания передачи.
S>То есть сервер отдаёт столько данных, сколько у него есть, но не закрывает соединение, а продолжает отправлять "сообщения" по мере поступления. Вот вам и "двусторонний" канал.
S>Более того — в случае внезапного обрыва соединения у клиента есть штатный способ запросить данные не с нуля, а с того байта, на котором произошёл обрыв.
S>Технологии COMET больше лет, чем AJAX. Кстати, не расскажете, как gRPC обрабатывает ситуацию обрыва соединения? Как клиенту получить остаток потока с того места, до которого он дочитал в прошлый раз?

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

_>>Ну т.е. чтобы это заработало, это надо написать руками. Так и в gRPC тоже самое. В чём отличие то по твоему? )))
S>Конечно же в обратной совместимости, negotiation и graceful degradation.

Ты думаешь что использование английский слов как-то улучшает твою аргументацию? На самом деле это только показывает твоё слабое владение профессиональной терминологией.

_>>Если же ты хотел именно банальный срез монотонного массива, то там прямо рядом лежит функция https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest с классическими параметрами среза from и to, возвращающая классический кусок массива.
S>
S>Нет, я не хотел ни весь массив, ни монотонный срез.
S>Я хотел получить список элементов, изменённых с определённого момента времени. А вы путаете Range с Delta encoding.
S>Рекомендую прочитать RFC 3229, секцию 4.1, до наступления просветления.

Осталось теперь только понять зачем может понадобится подобное в биржевом API. )))

S>Ну, и с чтением документации у вас некоторые проблемы. Метод https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest возвращает совсем не подмножество данных https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest, а вообще другие данные.

Ты похоже меня каким-то теоретиком считаешь))) В то время как у меня там уже давно функционирует очень прибыльная система. Которая кстати недавно переписывалась (т.е. считай уже второе поколение) с Python на Rust и с REST на gRPC (это ортогонально друг другу, просто так совпало по времени), правда с сохранением всех нейросетевых алгоритмов.

S>Что я ожидаю от delta-encoding применительно к https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest?
S>Пустого массива, если с момента моего последнего запроса не изменилось ничего. Массива из одного элемента, если с момента моего прошлого запроса прыгнул курс доллара (а остальные инструменты остались неизменными), и так далее. Как видим, в теории RPC позволяет такое сделать — но это потребует сразу заложить всё в сигнатуре методов. Я не могу написать сервер, который реализует только часть задокументированного протокола.

И будет этот метод всю свою жизнь использоваться только с передачей даты предыдущего запроса (от которого вычисляется дельта) в виде null. Потому что эта функция используется только для разового получения актуального среза данных. Для истории есть свои методы. А для оперативных данных свои (поток данных инициируемый сервером и там можешь считать что реально изменения присылаются).

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

_>>И теперь вот вопросик, а как тоже самое канонично описать в REST архитектуре? Просто идеологически тут явно должно быть GET, но при этом передавать массив строк в url как-то крайне печально... )))
S>Да ничего печального тут нет. Можно и список запихать в URL — в данном конкретном случае сколько там у нас реально инструментов торгуется на бирже? Тысяча? Полторы? Нет никаких проблем запихать хоть "все инструменты, кроме одного" напрямую в URL. В том числе и в компактном виде — сначала упаковав список в какой-нибудь околобинарный енкодинг, а потом в base64.
S>Потери производительности на "принудительную текстовость" будут пренебрежимо малы по сравнению с сетевыми задержками.
S>Можно реализовать это вторичными способами — например, сделав метод subscribe, который превращает список интересных нам инструментов в один идентификатор подписки, вслед за которым будут выполняться GET /subscriptions/####.

Вот, ты кажется уже начинаешь понимать как оно должно быть (в тинькоф api как раз подписка реализована, но подписка на поток от сервера!). Теперь ещё возможно дойдёшь до того, что непрерывный опрос в цикле — это очевидное зло и нагрузка впустую, и тогда сумеешь описать нормальную систему (выкинув REST), как раз как у тинькова.

_>>Ааа, ну т.е. "в рамках CRUD можно представить всё, что угодно", если это сложные задачи, а вот простые задачи с помощью CRUD плохо представляются... Понятно, понятно...
S>Да прекрасно они представляются при помощи CRUD. Трудности возникают тогда, когда у нас требования response time начинают доминировать над требованиями consistency.
S>Сложная задача — это когда у нас есть развесистая структура предметной области и развесистая логика на серверной стороне.
S>А мы говорим про задачу, ER-схема которой уместится на одном листочке школьной тетрадки.

Я чувствую такими темпами мы дойдём до того, что REST полезен только в узкой области скучных энтерпрайзных игр в базы данных (и то не факт, с учётом распространения всех этих брокеров сообщений, спарков и т.п.), а в остальных областях бесполезен.

_>>А особенно забавно это всё звучит с учётом того факта, что REST по сути является строгим подмножеством RPC.
S>Нет, не является. В REST введены концепции, которых в RPC просто нет, как класса. Нет понятия safety, нет понятия idempotence.

Вот ты смешной

Показываю на пальцах. Берём gRPC. Создаём там функции в полном соответствие с HTTP командами (GET, POST и т.д.). Явно передаём в качестве аргументов (опциональных конечно же) нужные HTTP заголовки. И договариваемся использовать эти функции по правилам REST. Что мы получим в итоге? Правильно, полноценный REST, реализованный поверх gRPC.

А теперь попробуй реализовать обратное. Т.е. создать произвольный gRPC API с помощью REST.

Теперь понятно кто тут является чьим подмножеством? )

_>>Что-то ты сам себе противоречишь. В предыдущем сообщение же сам признал, что для данной задачи REST не особо подходит.
S>REST не особо подходит для задачи, где нужно передавать простые данные с минимальной задержкой, при этом потерями при передаче можно пренебречь.

Не подходит для этой задачи, и ещё для многих других. )))

S>При этом нужно быть очень аккуратным при проверке этих ограничений. К примеру, рассуждения о минимизации задержки бессмысленны, когда у нас клиент расположен в 200мс от сервера. Там накладные расходы на передачу парсинг HTTP-заголовков запроса в REST-подходе составляют единицы миллисекунд. А вот если мы ставим сервер в соседнюю стойку, то разница между 0мс для gRPC stream и 1ms REST request становится существенной.
S>Осторожность здесь важна для того, чтобы не принимать решение для 200мс ping times на основании рассуждений, которые справедливы для 0мс ping time.

У тебя какое-то представление о современных сетях из прошлого века. У меня даже из дома пинг до тинькова 2 мс (и то это округление скорее всего).

_>>Вообще, когда человек отвечает подобным образом на подобную задачу, то это может означать только одно из двух:
_>>1. Он абсолютно не компетентен как инженер (не понимает слов ТЗ и т.п.)
_>>2. Он вполне компетентен и всё понимает, но честный ответ на задачу демонстрирует его неправоту, поэтому он начинает вилять и менять ТЗ.
S>
S>Считать ТЗ божьим словом, высеченным на скрижалях, могут себе позволить только джуны. Даже миддл начинает задаваться вопросом "а зачем мы это делаем?" и подвергать навязанные решения сомнению.

"зачем" решает бизнес! )

_>>Забавно, у нас в приложение по сути являющемся RPC клиентом (причём не gRPC, а вообще самодельном на базе WebSocket) в браузере, кнопка back отлично работает. Может всё дело в кривизне рук? )))
S>Может быть. В принципе, можно и из SOAP изобразить более-менее приличное решение. Правда, там придётся переизобрести с нуля REST, и получить велосипедную его реализацию, не совместимую ни с чем.

Какое ещё "переизобрести REST"? Просто в браузере есть API для полноценного управления историей (т.е. поведением кнопки back) и всё. И кстати к взаимодействию с сервером это вообще ортогонально на самом деле.

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

У gRPC со всем этим получше будет. )))

_>>Да я уже понял, что ты выставишь требование изменения железа по причине того, что оно плохо сочетается с любимой тобой программной архитектурой. Интересно, как тебя на работу принимали с такими подходами? ) Или ты там при приёме скрывал подобные замашки? )))
S>Меня обычно принимают на работу как раз для того, чтобы я предложил архитектурные решения, дающие нужный результат.
S>А не для того, чтобы "выставить в интернет протокол удалённого управления вертелкой камеры".

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

S>Потому, что далеко не всем очевидно, что надо задумываться не только о единственном позитивном сценарии, типа "один пользователь за бесконечно надёжным каналом с бесконечно большой полосой пропускания отправляет редкие команды", но и над всеми остальными сценариями, которые неизбежно возникнут в практической эксплуатации. Например — что делать, когда один пользователь жмёт "вправо", а другой — "влево".

Такие системы (управления) всегда монопользовательские!

S>Мои знания о том, как проектировать вот такие решения, неожиданно неплохо оплачиваются. Чего и вам желаю

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

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

_>Что-то ты бредишь или не знаю чем читал нашу беседу.

Думаешь, чем больше ты хамишь, тем более убедительным выглядишь?

_> Задача была сформулирована мною предельно просто

Задача твоя была призвана сменить тему. А когда тут никто на это не повелся — ты начал хамить.
Я тебе напомню с чего все началось:

Нюанс в том, что в данный момент основным подходом снова становится RPC.

А теперь поясни, как отличия между RPC и REST вылились в обязательную необходимость какого то аппаратного блока.
Это я уж не говорю о том, что сравнивать REST (идеологию) и gRPC(конкретный фреймворк) — не самое разумное занятие. Сравнивать можно либо HTTP+JSON с gRPC, либо REST с RPC.

_>: есть некая конкретная железка с конкретными "кнопками" и надо приделать (любым программным способом, без каких-либо ограничений на протокол) к ней удалённое управление (чтобы грубо говоря нажимать эти кнопки дистанционно).

Без промежуточного сервера на стороне железки? И этот момент ты, конечно, "забыл" уточнить в начале?

Еще раз, если ты с первого раза не понял:
1) Либо на стороне железки нет возможности выбирать протокол, и тогда пример нерелевантен топику от слова "совсем"
2) Либо протокол таки выбирать мы можем, и тогда твои рассказы про необходимость замены аппаратного блока и особенности разработки железок — грубая попытка подмены темы

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.
НС>Тебе уже вопросы конкретные задали, но ты их поскипал. Что произойдет при обрыве соединения в момент посылки Move? Что произойдет если соединение оборвется в момент возврата отклика от сервера. Что будет если соединение с фиговой латентностью?
НС>А то что ты никаких проблем не видишь мы уже поняли.

Ты уже совсем заболтался что ли? ) У пользователя перед глазами видеопоток с камеры! И он отлично видит, встала она уже в нужную ему позицию или ещё нет. )))

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

S>>Нет конечно, это чушь. Именно что понимается хранение состояния сервером.
_>Какая милота. Кстати, не напомнишь, как там звучит 2-ой пункт из требований REST? )))
Вы явно чего-то фундаментального не понимаете про REST. Из того, что RESTful протокол занимается передачей состояния, вовсе не означает, что "всё состояние передаётся в запросе".
Например, когда я пытаюсь выполнить регистрацию на рейс, состояние всех регистраций хранится на сервере.

_>По правильному тут надо читать не "можно обойтись без REST", а "лучше обходиться без REST". )))
Прежде чем давать советы, как и что правильно читать, неплохо было бы разобраться с основами REST.
Ну, возьмём например такой сервис, у которого вообще нет никакого состояния.
Ему на вход подаётся, допустим, небольшая картинка. Скажем, 200*80px. Сервер ставит на неё свой водяной знак.
Можно это трактовать как RPC: "Вот тебе картинка, нарисуй на ней".
А можно — как REST: "Отдай мне картинку с такими параметрами".
Второй подход выигрывает тем, что можно снизить нагрузку от повторных обращений, просто выставив хидер Expiration: Never.

Можно реализовать сервис, который отдаёт десятичные знаки числа Pi. Он тоже полностью stateless.
REST-подход означает, что мы легко привинчиваем к нему Range хидер: сервис просто пропускает сколько-то первых цифр, которые уже есть у клиента, и экономит ему трафик.

_>Как забавно. ) Так что же тебе помешало тогда в предыдущей задачке (которая очевидно является подмножеством этой) применить тот же подход? ) Ну типа очередь заданий виде "поворот налево" и "поворот направо"? )))
А там примерно так и будет; потому что поворот камеры осуществляется не мгновенно. Поэтому когда делается PUT или PATCH, придётся отвечать 202.

_>Т.е. я правильно понимаю, что скажем эта https://www.postgresql.org/docs/current/protocol.html штука является классикой REST? )
Нет. Сам по себе DML является практически классикой REST, потому что как раз и описывает CRUD операции.

_>Так ты интерфейс то опиши... Вот у нас у клиента есть произвольная SQL (+DML+DDL, ну как обычно) строка. Куда её сунуть и как получить результат исполнения в REST стиле...
Вот вы опять подменяете задачу конкретным решением.
Задача у вас в чём? Управлять состоянием БД.
Ну вот был у нас такой доисторический stateful протокол. Разработанный для текстовых терминалов, перед которыми будет сидеть живой пользователь, и набирать все вот эти вот begin transaction.
Если мы поставим такую же задачу перед современным архитектором, то получится протокол ODATA

_>Ну и да, такое будет работать. Но это, как я и говорил изначально, будет дополнительный аппаратный блок и дополнительная прошивка. А с изначальной задачей на заданном железе ты справиться не смог.
Прошивка чего? Там всей доп. стоимости на десять центов.
А вы попробуйте справиться с задачей "написать бота, который склеивает панораму из снимков каждый час, и потом монтирует из этого фильм в mp4".

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

_>Так ты не ответил, какой там 2-ой пункт из требований REST? И как это пересекается с твоим пониманием REST "Именно что понимается хранение состояния сервером"? )))
Я подозреваю, что вы про state.
Ну так нормально и пересекается — я же написал вам пример про рейс.

_>Прикинул вероятность побитового совпадения двух произвольных цветных картинок размером 200*80px и в очередной раз оценил твоё умение проектировать системы. )
А вы каким способом эту вероятность оцениваете? Просто возводите 2 в степень -(16000)?
Тогда да — вам стоит поучиться проектировать системы. Потому что входные данные ни в какой задаче не бывают равновероятными.
Например, если результат запроса стоит в подписи у участника активного форума, то одна и та же картинка может быть запрошена несколько тысяч раз.

_>Да, люди очень хорошо научились раздавать статические файлы.
Почему же статические? Число Pi бесконечно — ни в какой файл его не запишешь.

_>О, т.е. теперь уже оказывается, что можно решить задачку на REST и без дополнительного железа? Или что? )))
Нет, оказывается, что вы по-прежнему не понимаете, как делаются нормальные продуктовые решения.
Датчик нулевого положения привинчивается к камере для того, чтобы на сервере была возможность получать текущее состояние.
Ну, то, которое вы полагали невозможным без дорогостоящего енкодера.
Дальше, поскольку мы понимаем, что камера поворачивается не мгновенно, у нас нет возможности моментально выполнить любой запрос типа "повернись на северо-запад".
Нужен какой-то способ этим управлять — поэтому в протоколе у нас будет два положения: текущее истинное и целевое. Первое меняет сервер, второе — клиент.

В вашем RPC-подходе клиент может успеть запихать в канал 1000 сообщений "направо", особенно если сеть локально взглюкнуло и возникла задержка передачи.
Отменить эти сообщения клиент не может — он будет вынужден ждать, пока камера всё это прокрутит и успокоится, чтобы начать снова управлять положением.
А в REST подходе, даже если я попросил направить на северо-восток, но потом передумал и решил направить на восток, сервер не будет совершать лишних движений.

_>Не слышал про такой протокол, как DML...
https://en.wikipedia.org/wiki/Data_manipulation_language

_>Я правильно понял, что теперь у нас и SQL плохой и устаревший? )))
Для распределённых систем — да. Никто в здравом уме SQL через океан не гоняет, и наружу недоверенным клиентам не выставляет. Вы же не могли проспать переход от client-server к трёхзвенке?

_>Я правильно понял, что этот мертворождённый уродец, является твоим идеалом? )
Нет, там можно ещё улучшить. Но ODATA уже очень даже неплох. Как минимум, лучше большинства RPC поделок.

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

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

vaa>>это "" пустая строка, довольно странное решение.

DE>А что должно быть?

null

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

I>>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
S>Написать баг авторам либы и не переходить пока он не будет починен.
Вот примерно так мы от буста отказались в своё время. Оказалось что быстрее самим написать то, что нам оттуда надо было чем дождаться когда они починят не сломав что нить другое. Своя имплементация ещё и заметно быстрее получилась.

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

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

R>Что тебе мешает в монолите поддерживать минимум связей? Более того, разделение на модули придумали еще когда термин микросервисы не существовал (да и сетей почти не было).

R>Микросервисы решают 2 задачи: делают возможным реализацию приложения, которому не хватает ресурсов одной машины (гугл/фейскнига) и делают возможным разработку приложения, которым занимаются разные команды с разными дедлайнами, задачам и приоритетами (тут достаточно договориться о протоколе обмена данными и времени реализации изменений, а также поддержки легаси — остальное в каждой команде решают независимо, а вот запихать это в один монолит — возникнет неразруливаемый срач с выяснением у кого длиннее).
Самое главное, что решают микросервисы — позволяют писать код на чём угодно. В теории, конечно, можно и в монолите всё распилить на отдельные компоненты, изолированные через C-style ABI (ну или там, скажем, построить всё на основе COM, и писать часть кода на VC++, а часть — на Delphi), но на практике вызвать какую-нибудь питоновую либу из Java приложения — недостижимая фантастика.
Не менее весёлой становится задача, скажем, перевести монолит с одной версии платформы на другую. Вот у нас пара миллионов строк кода, которую нам нужно перевести с Java 1.3 на 1.8.
Там в принципе несложно — тут имя пакета подправить, там класс заменить. И таких мест — несколько тысяч. После этого оно начинает хотя бы собираться, но не факт, что работать. Надо тестировать: часть косяков вылезет в продакшн — например потому, что где-то там что-то подгружается динамически, и в новой java оно работает не так.
А переехать мы хотим потому, что есть какой-то новый компонент, и в нём очень бы кстати пришлась новая либа, которая не работает с жавой ниже 1.8.
И вот либо мы тратим N+1 месяцев на тщательное портирование всего монолита на новую версию (причём скорее всего замораживая весь feature development до его окончания), либо пилим новый компонент за 3x времени из-за отсутствия нужной либы.
А всё потому, что запустить в рамках одного процесса две версии джавы мы не в силах.
То же самое — с версиями питона. То же самое — с версиями дотнета.
Более того, у нас там может стрельнуть какая-нибудь наркомания вроде того, что у нас ядро на С++, хочет вызывать плагины через COM, и вот у нас два плагина, один на дотнете 3.5, второй — на 4.5. Каждый думает "ачотакова, ща я загружу CLR inproc, и мы поедем".

Микросервисы позволяют перетаскивать монолит на новую версию по частям.
Ну, а в совсем больших и запущенных случаях мы можем совмещать код на совершенно разных языках. В итоге, нам не нужно искать "специалиста по датамайнингу на дотнете" или "специалиста по видеокодекам на java".
Достаточно искать специалистов по датамайнингу и видеокодекам, а технологический стек пусть тащат какой хотят. Питон — пусть будет питон. Плюсы — пусть будут плюсы. Вам на гошечке комфортнее писать? Ну, давайте на гошечке напишем.

Вот так выглядит современная вавилонская башня, а вовсе не как дружная семья CLR-совместимых языков, которые все компилируются в .Net (как это себе представляла Редмондская молодёжь 22 года тому).

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

vsb>Лично для меня у Go самая фатальная проблема это система обработки ошибок. Я считаю, что исключения в сто раз лучше, чем то, что сделали в Go.

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

Здравствуйте, kaa.python, Вы писали:

vsb>>Подход с явной обработкой выходит боком практически всегда. Ошибку либо тупо прокидывают вверх, теряя стектрейс, либо игнорируют, либо пытаются обрабатывать на месте (очень часто с багами, т.к. этот сценарий никогда не тестируют).

KP>В случае с Го ошибка будет обработана на месте, т.к. линтеры. Любой нормальный Го проект невероятно густо ими обвешен. В худшем случае это будет запись в логе в духе "не шмогла я", но это даст возможность легко проанализировать ситуацию и понять как поправить. Да и то такой худший случай как-то еще должен пройти ревью и попасть в мастер, что не так что бы и просто. Я бы сказал что подход Go в подавляющем большинстве случаев приводит к рабочей обработке ошибок.

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

KP>Я обычно пишу на C++ и Go. Ошибки в C++ из за отсутствия обработки исключений обычно более болезненные чем излишне примитивная обработка ошибки в Го. Просто наблюдения

С++ специфический язык. В нём вечно заморачиваются всякими exception-safe кодами. На Java про такое 99% и не слышала. Просто пишешь и пишешь. Shared state особо нет. Поэтому никаких проблем от отсутствия обработки исключения тут нет. В любом фреймворке сверху крутится try-catch, который отдаст 500 ошибку и в лог нагадит, что в общем-то вполне адекватно для обработки по умолчанию.

Здравствуйте, Anton Batenev, Вы писали:

S>> AB>А зачем? Для ниши go монобинарь удобнее (в деплое и поддержке).
S>> Насрать вообщето деплою и поддержке.
AB>Для ниши go — нет. Но мне сложно будет тебе объяснить почему, т.к. у тебя отсутствует релевантный опыт.
У меня всё отсутствует, да. Даже компустера нет, с калькулятора пишу, ага.
Писал я на этом вашем го. Деплою то что на го написано. Один из моих экспортеров prometheus community себе забрало. На go.
Но у меня опыта нет, иначе быть не может.


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

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

vsb>Ошибку либо тупо прокидывают вверх, теряя стектрейс

Никакой стектрейс никуда не теряется он хранится в ошибке. С стектрейсами в гошке как раз всё ok

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

CC>Ещё раз, при деплое куда лучше всё что надо иметь в себе, и ни от кого не зависеть.

или как альтернатива разворачивать свой докер образ

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

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

Ну при всем при том, большинство программистов вряд ли понимают, как устроен внутри float. Чем строка-то хуже?

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

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

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

Pzz>В результате, они сломали мой любимий плагин hg-git, который превращает mercurial в git, но с пользовательским интерфейсом mercurial'а, гораздо более гуманным, чем у git'а, и сломали проприетериальный (я правильно сказал?) драйвер от принтеров kyocera, который теперь не печатает, а о чем-то вечно думает, на 100% загружая доставшееся ему ядро процессора).

Как и следовало ожидать:
1. Довольно странная тулза, которой пользуются два с половиной человека и ты.
2. Проприетарный драйвер, у которого нет исходников и на обновление которого забили программисты этого драйвера.

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

Pzz>>Поменяли системную инсталляцию Питона, и старые скрипты на Питоне загнулись.
S>Очевидно что не все.

Ну внешний, киосеровский, скрипт загнулся. hg-git, который приходит, как стандартный федоровский пакет, тоже загнулся. Так что, скорее все, чем не все.

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

I>> Алё — на этапе разработки ты и представить не можешь, что куда кому взбредет в голову задеплоить. Как ты собираешься проанализировать тысячу-другую возможных комбинаций?
S>Достаточно нескольких (2-5) популярных дистрибутивов поддерживать. Всё остальное — "мы не поддерживаем данный дистрибутив но готовы помочь за допплату"

Ты сам то понял что сказал? Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.

I>>1. кто куда чего может задеплоить
S>В рекомендованные вами дистрибутивы. Почемуто считается нормальным указываать версию мака и виндов для которых приложение работает. Но с линупсом надо обязательно вообще всё!!11.

Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?

I>>2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей?
S>Вот это и есть — "закостеневание". Это когда "нетнет, обновляться нинада, уже и так хорошо, а вдруг там монстры??7"

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

I>>Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии.
S>Автор общается, отвечает — ждём. А пока работаем со старой версией.

Похоже, ты уже начал кое что понимать.

I>>А потом заходишь ты в гитхаб либы, и видишь, что эта проблема булькает уже три последних года.
S>Два варианта:
S>1. Сменить библиотеку.

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

S>2. Форкнуть и пофиксить.

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

S>Почему так? Потому что де-факто эта либа уже не поддерживается никем.

Наоборот.

I>>Похоже, что ты не различаешь "новые известные" и "новые неизвестные". Первые — в баклоге. А вот остальные булькают то тут то там и возможно не скоро попадут в баклог.
S>Я про новые неизвестные и пишу. Нашол такой — в багтрекер его.

У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?

I>>Это какие то общие слова вида "хорошее лучше плохого".
S>В противовес твоему "старое лучше свежего" звучат более логично, не находишь ли?

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

I>>Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку.
S>Ты и твоя команда это будут делать. Ты и твоя команда. В рабочем порядке во время запланированного обновления используемых либ на этапе тестирования свежего перед принятием решения "обновляться можно уже сейчас или ещо подождать?".

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

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

CC>>>А не дороговато ли выйдет?
НС>>Нет. Для того контейнеры и придумали, чтобы не было дороговато.
S>А ты считал стоимость сопровождения?

Кого, контейнеров? И что подразумевается под их сопровождением?

S> Стоимость специалиста по кубам, нопример?

При чем тут куб? Куб решает намного больше задач, чем контейнеры.

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

vsb>Никогда у меня не было проблем с исключениями.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

S>> Да куча экспортеров статистики под prometheus/influxdb на ём, да и вообще почти весь этот стек мониторинга на ём.

НС>Т.е. "aws тотже".
Не распарсил что ты имеешь в виду.

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

S>Да ну откуда? Контейнеры же из слоёв; как я понял — слои повторно используются.
S>Поэтому если у тебя на железке 30 контейнеров с аппликухами построены на одном и том же дистрибутиве, и в 20 используется питон, а в 10 — go, то физически на диске будет лежать 1 питон и 1 го.
S>Если кому-то потребовался питон 2.7, а не 3.1, то появится 1 экземпляр питона 2.7, при этом он никак не помешает тем 20 аппликухам, которым нужен питон 3.1.

Ты сам это тестил, проверял, что так оно и есть? Учитывая, что докер-это жуткое глюкалово, не удивлюсь, если это только заявлено, но так это не работает должным образом. Вот у меня на локалхосте это не работает: собираемые локально, подтягиваемые извне контейнеры, все из которых создаются на основе одного и того же базового образа из центрального registry, в течении недели-двух отжирают несколько десятков GB. Регулярно приходится делать rm -fr /var/lib/docker

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

S>>Если бизнес скажет тебе вставить затычку в пятую точку — так и сделаешь?
S>>Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала и требует вырастить руки на жопе. Это так работает?
V_>Это значит, что неопытный рекрутер нанял бесконечно отсталого, бывшего профессионала (?), который даже не понимает, что от него хотят.
А опытный рекрутер наймёт сразу того у кого руки из жопы и кто готов мужеложествовать если БИЗНЕСУ НАДО?

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


V_>>>Я за этим не слежу, у всех разные требования к либам. Чтобы все оптимизировать до одного слайса, у нас есть много других, более актуальных дел. Префекционизм любой ценой — зло
S>>Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
C>Учитывая, что дистрибутивы Линукса пишут жопорукие, то да.
Кто бы сомневался что виноватыми останутся дистрибутивы линупс, Шеридан, тайное правительство, но только не сам.


C>Ни одному из них доверять вообще нельзя без того, чтобы 10 раз протестировать на staging с постепенным сдвигом трафика на production.
А где не так? Ну?
Например, твой код. Он вообще без стейжа и тестов работает?


C>Вот из-за этой реальности и приходится использовать Docker/k8s. Если бы дистрибутивы не писали полные идиоты, то может быть такое и возможно было бы.
Да-да. Идиоты пишут дистрибутивы. Я это уже понял. Ой, постой, они же и Docker/k8s написали. И в идиотские дистрибутивы включили! 0_0
Или это не те идиоты? А какие тогда — те?
Я правильно понимаю что идиоты у тебя все вокруг кроме тебя и авторов софта который тебе нравится?

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

S>>>Контейнеры, их необходимость и популярность-это деградация именно культуры разработки ПО.
S>>Именно про это я и пишу. Против этого я тут и выступаю.
CC>Ты ещё наксколько я помню и против monobinary выступал, которые не имеют никакого отношения к контейнерам.
Монолит всё носит в себе. Что с одной стороны конечно удобно (можно тяп-ляп и отдать готовое)
А с другой стороны забодаешься потом эту помойку обновлять. Вместо обновления одной либы с уязвимостью на новую версию (и таким образом зачинив весь использующий её софт) придётся надеяться что автор монолита обновит таки свой монолит и можно будет его безбоязненно запускать.
Ну и конечно же для подобных авторов монолитов совершенно наплевать на диски заказчиков/потребителей. Ну типа не лох чай, ещо один диск купит.

CC>И да, кусок говна, который из себя распаковывает кучу хлама в tmp и оттуда втихаря юзает — не monobinary
Абсолютно верно.

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

S>>>Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
C>>Учитывая, что дистрибутивы Линукса пишут жопорукие, то да.
S>Кто бы сомневался что виноватыми останутся дистрибутивы линупс, Шеридан, тайное правительство, но только не сам.
Именно так. Виноваты те, кто не заботиться о надёжности.

C>>Ни одному из них доверять вообще нельзя без того, чтобы 10 раз протестировать на staging с постепенным сдвигом трафика на production.
S>А где не так? Ну?
S>Например, твой код. Он вообще без стейжа и тестов работает?
Он написан так, что не ломает соседний код. А вот дистропейсатели такого не осилили. В результате обновление какого-нибудь TeX может сломать Java (реальная история, кстати).

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

CI/CD? Неее... не слышали. Херак, херак и заливаем пакеты на зеркала!

C>>Вот из-за этой реальности и приходится использовать Docker/k8s. Если бы дистрибутивы не писали полные идиоты, то может быть такое и возможно было бы.
S>Да-да. Идиоты пишут дистрибутивы. Я это уже понял. Ой, постой, они же и Docker/k8s написали. И в идиотские дистрибутивы включили! 0_0
Нет, Докер написали реалисты, которые вынуждены были жить с ...творением... дистропейсателей. А k8s написал Гугл по результатам борьбы с сотнями тысяч серверов.

S>Или это не те идиоты? А какие тогда — те?
Не идиоты.

S>Я правильно понимаю что идиоты у тебя все вокруг кроме тебя и авторов софта который тебе нравится?
Кроме тех, кто заботится о надёжности софта. А не работе "на авось". Если в моей инфраструктуре что-то работает, то оно будет работать всегда и надёжно.

Я могу взять коммит трёхлетней давности, достать его из репозитория, и собрать изображения, которые будут до бита идентичны тем, что были 3 года назад. И потом повторить любые вычисления для сравнения результатов между новым и старым кодом, например. Мы таким образом находили ошибки в оптимизациях gcc.

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

НС>>Ему это все уже объясняли. На что был получен ответ, что бизнес должен идти в жопу со своими потребностями пока программисты обновляют все либы в проекте. Так что не про то ты рассказываешь.
S>Если бизнес скажет тебе вставить затычку в пятую точку — так и сделаешь?

Занялся демагогией?

S>Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала

С чего ты взял что ты профессионал? Сам так решил? То что ты тут пишешь — уровень любителя.

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

S>>>Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала
НС>>С чего ты взял что ты профессионал? Сам так решил? То что ты тут пишешь — уровень любителя.
S>Я тут при чом?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот есть у нас модуль обучения, написан на Питоне (модуль это не dll, это набор скриптов, общающихся с внешним миром через консоль и файлы и запускающий при этом десяток разных приложений), и команда, умеющая в машинное обучение и Питон. Рядом другая команда, умеющая в CV и C++, и модуль CV на C++. И третья команда, умеющая в облачный бэк и их Платформа, написанная на дотнете или жабе. И еще пяток сторонних сервисов, написанных на Go, С++, Питоне, жаве.
НС>Теперь это все нам нужно собрать в работающий продукт, причем в разумные сроки. Твои действия?
У вас выбора нет, у вас уже есть куча мала и её хоть както надо запустить.
Я же про ситуации когда выбор (ещё) есть.

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

S>>>Цитирую: "В Go есть ООП, причём достаточно крутой за счёт структурной типизации."
C>>Есть. Нет "наследования классов" и мастурбирования на "контроль доступа".
S>Ну, такой себе ООП. Самую мякотку и выкинули.
Наследование классов — оказалось противопоказано и в классических ООП, так как создаёт слишком сильную связность. А детальный контроль доступа просто не нужен, достаточно разделения между публичным интерфейсом и приватным для пакета.

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

НС>>Теперь это все нам нужно собрать в работающий продукт, причем в разумные сроки. Твои действия?
S>У вас выбора нет, у вас уже есть куча мала и её хоть както надо запустить.

Это не только у нас, это чуть более чем во всех крупных проектах так.

S>Я же про ситуации когда выбор (ещё) есть.

Не увидел этого в твоем заявлении:

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

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

НС>>Могу
S>Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно?

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

S>Что с эволюцией делать будем?

Ты часто автоматизируешь что то, связанное с эволюцией живых организмов? Мне вот ни разу не джоводилось.

S>OO is Xenophobic — вообще фантастический аргумент

И что с ним не так? Здравый аргумент, и это именно то что мы наблюдаем на практике. Чуть менее чем все кроссплатформенные интерфейсы — не ОО, начиная от dll и заканчивая новомодными REST и gRPC. А все попытки сделать ОО (СОМ, SOAP, CORBA) — в итоге померли или в процессе.

S>В общем, автор очень хочет очернить ООП, явно видно.

Не, скорее ты принял ООП за аксиому и не способен сползти с этих рельс.

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

S>Цитирую: "В Go есть ООП, причём достаточно крутой за счёт структурной типизации."

Верно. Тебе просто надо понять, что ООП вовсе не ограничивается классической реализацией в языках типа С++ или Дельфи. В JS, к примеру, тоже ОО есть.

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

S>Расскажу только, что у него astra linux smolensk.

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

Здравствуйте, Константин Б., Вы писали:

КБ>Такой же "факт" как и "теряется стектрейс" или "пытаются обрабатывать ошибки на месте (с багами)". Собственно ты даже не скрываешь что говоришь о каких-то других языках и проецируешь проблемы этих языков на го.

Приведи кошерный пример кодов возврата на го с парой-тройкой уровней вложенности, обсудим.

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

C>>Наследование классов — оказалось противопоказано и в классических ООП, так как создаёт слишком сильную связность. А детальный контроль доступа просто не нужен, достаточно разделения между публичным интерфейсом и приватным для пакета.
S>Чем protected то не угодил?
Тем, что оно работает только для наследования классов (реализаций). А это уже однозначное зло.

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

C>Почему же? Оно "набирает" номер другой стороны.

ну типа мы набираем номер другой стороны и ждем когда нас соединят, получается что dial это только первая часть процесса
плюс у меня еще ассоциации с signalling в VoIP появляются

C>Это практически единственный пример, где оно не работает. Но если очень хочется — берём и вызываем clock_gettime напрямую.

мне кажется можно придумать еще, но главное конечно, это то что теряется аспект документирования кода и интерфейсов
скажем если я вижу где-то в интерфейсе duration и это системное время, либо наоборот монотонное, я что-то сразу понимаю про то как это все должно работать, а тут нет, мелочь конечно, но неприятно

C>Ну они могли бы ввести тип "type Path string", но смысл? Массив байт неудобен из-за того, что нельзя гарантировать иммутабельность.

жить с этим конечно можно, но опять же, вот есть у меня ф-я, которая преобразует путь в каноничный (в Go такой ф-ии почему-то нет, но представим что есть)
так вот, ф-я получает на вход путь в виде строки? при этом она не делает то что можно подумать (преобразует строку используя только входные данные), она лезет в ФС и делает что-то сложное, использует системный вызов, который может делать какой-то ввод-вывод и тд, но ф-я выглядит так, словно она просто преобразует строку

в общем, мое мнение — strong types это хорошо, в плюсах к этому уже давно пришли, там уже принято вводить именованные типы вместо фундаментальных, там где это имеет смысл

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

_>>Нюанс в том, что в данный момент основным подходом снова становится RPC. Правда теперь это уже RPC поверх HTTP/2 (gRPC), но это не суть (тут https играет роль не сильно большую, чем tcp, ip, ethernet). )))
S>Интересно, с чем это связано. Что именно компенсирует недостатки RPC по сравнению с REST?
Конкретно с gRPC — полноценная двусторонняя коммуникация.

Ну и в целом, REST весьма неудобен как подход, в целом. Слишком много гибкости.

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

S>man онтогенез
No manual entry for онтогенез

Надо доставить какой-то пакет?

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

_>>Ну для начала не стоит забывать про то, что в REST у тебя для части данных жёстко определён способ сериализации, причём максимально убогий — urlencoded .
S>А что у нас в gRPC? Там же внизу тот же HTTP, то есть адресация по прежнему через URL.

Tак там будет один URL (скорее всего просто в виде домена) даже для всех функций, не говоря уже о всех ресурсах. )))

_>>А далее, даже если мы возьмём MessagePack и HTTP/2 для REST, то это всё равно не позволит нам получить сравнимую эффективность из-за наличия в gRPC такого "типа данных" как stream. Который позволяет отправить множество сообщений в рамках одного запроса (а не проводить весь комплекс установки ip, tcp, http, ssl соединений для каждой маленькой пачки данных).
S>Не очень понятно, что нам помешает отправить в REST пачку данных в рамках одного запроса или реквеста.

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

S>Большинство REST-данных именно так и устроены. Более того — в RPC вы не сможете получить сравнимую с REST эффективность из-за отсутствия conditional get и delta encoding.

))) Обычно на эту тему рисуют такие картинки (кстати, там кажется тестировали даже на вашем родном .net'е) с разницей раз в 10:

	Диаграммка тестов

_>>Эээ что? )
S>Сказать серверу "данные вплоть до 18.02 у меня уже есть. Если есть что-то новее — то пришлите разницу. Если нет — то достаточно просто 304".

И что мешает сделать тоже самое с gRPC? )

_>>Могу привести тебе пример такой задачи. Более того, решаемой прямой сейчас в работающих системах именно таким способом. Например это получение клиентом данных о биржевой торговле (стакан и т.п.) в реальном времени.
S>Ну, про биржевую торговлю я не специалист. Те клиенты, которыми я пользовался, работают поверх REST. Никакого gRPC. Но я понимаю, что там всё для людей — роботам нужно что-то другое; для чего вебхуки категорически не подойдут.

Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )

S>>>То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...
_>>Типа если клиент с REST ляжет, то это как-то поможет не забыть отреагировать в нужный момент на текущие данные? )))
S>Типа если REST-клиент ляжет, это никак не повлияет на поведение сервера. А ставить поведение всей системы в зависимость от того, смог ли клиент получить данные немедленно или нет — это путь к катастрофе.

Ну так а если это условие задачи (в биржевой торговле так и есть), то что тогда? )))

_>>Ну вот тебе простейшая (и опять же из вполне реальной практики) задачка. Есть шаговый манипулятор со свободным вращением (но без энкодера). И соответственно у управляющей им схемы есть две команды: move_left() и move_right(). Доступ к этому через RPC очевидно выглядит полностью естественно — прямо как и реальные команды. А вот как по твоему будет выглядеть логичный REST вариант интерфейса? )))
S>Погодите, у вас где-то за океаном стоит шаговый манипулятор, и вы хотите управлять им через RPC, я правильно понял?

Ну да)

S>И вас никак-никак не беспокоит то, что вы не имеете представления о его текущем положении?

Я же писал, что экондера нет. Да и не нужен он, т.к. на устройстве камера, поток от которой параллельно тоже идёт к пользователю (и тот глазами по картинке легко определяет нужное ему положение). Кстати, тут подумалось, что в рамках gRPC можно и поток данных от камеры сделать не параллельным где-то рядом, а прямо в рамках того же API (как stream кадров от сервера).

S>По-моему, эта схема архитектурно обречена. Чтобы спроектировать нормальное решение, надо начать плясать от задачи, а не от "у нас есть шаговый манипулятор, бутылка виски и два билета на бейсбол. Какой API нам выставить для всего этого?".

Я правильно понимаю, что данный поток слов надо воспринимать как слив по данному примеру? )))

_>>Ну возможно это мои личные субъективные ощущения (а индустрия возвращается к RPC по каким-то другим причинам), а возможно ты слепой (не видишь аргументов, а они есть). Не знаю.
S>Мне вот кажется, что индустрия просто так и не перешла на REST. Ну, то есть кто-то продолжал пилить RPC over HTTP, называя его REST — вот эти люди, понятное дело, с большим облегчением переезжают на всякие gRPC и MessagePack.

С учётом наличия такой https://github.com/grpc-ecosystem/grpc-gateway штуки, мне кажется что выбор о базовой реализации должен быть однозначным. ))) Хотя конечно же по настоящему модные возможности (типа двунаправленных потоков) там отсутствуют — ну это цена за желание поддержки легаси (REST).

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

_>То, что на момент отправки первого сообщения, данных для следующих сообщений пока ещё нет.
И?

_>))) Обычно на эту тему рисуют такие картинки (кстати, там кажется тестировали даже на вашем родном .net'е) с разницей раз в 10:
_>

	Диаграммка тестов
	_>Image: 3526a19782d163fb2d4b39b0ed2fcd3b.png

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

_>И что мешает сделать тоже самое с gRPC? )
То, что в него не встроены такие вещи. Вам придётся вносить всё это в сигнатуру метода, ломая обратную совместимость с клиентами, которые не знают про delta encoding.
А в REST это встроено из коробки. Поэтому можно допиливать сервер, не переживая за то, что часть клиентов не умеют такие вещи.
С учётом разнообразных хидеров аналогом одного REST-ендпоинта будут несколько десятков сигнатур RPC-методов. Чего, естественно, никто не делает.
Вот вам, к примеру, delta encoding даже в голову не пришёл — значит, если дать вам спроектировать сервис на основе gRPC, вы ничего подобного в него не заложите.

_>Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )
Ну я и говорю — для роботов REST может и не подойти.
_>Ну так а если это условие задачи (в биржевой торговле так и есть), то что тогда? )))
Тогда биржа просто забивает на то, что клиент может лечь. Это — его проблемы. Так ведь? Нет задачи "гарантированно известить обо всех событиях".

_>Я же писал, что экондера нет. Да и не нужен он, т.к. на устройстве камера, поток от которой параллельно тоже идёт к пользователю (и тот глазами по картинке легко определяет нужное ему положение).
Угу. С задержкой в 500мс, да?
Простите, эта схема — неработоспособна.
_>Кстати, тут подумалось, что в рамках gRPC можно и поток данных от камеры сделать не параллельным где-то рядом, а прямо в рамках того же API (как stream кадров от сервера).
А то. Можно. Но это — патологически неустойчивый вариант. Пользоваться им будет крайне неудобно. В разы неудобнее, чем через REST.
В то время, как REST архитектура (не протокол, а архитектура) позволит им пользоваться даже без человека на приёмном конце.
_>Я правильно понимаю, что данный поток слов надо воспринимать как слив по данному примеру? )))
Можно и так воспринимать. Но правильнее будет, если вы примете как слив саму формулировку архитектурного решения, т.к. оно вряд ли решит задачу конечного потребителя.

_>С учётом наличия такой https://github.com/grpc-ecosystem/grpc-gateway штуки, мне кажется что выбор о базовой реализации должен быть однозначным. ))) Хотя конечно же по настоящему модные возможности (типа двунаправленных потоков) там отсутствуют — ну это цена за желание поддержки легаси (REST).
Пока что выглядит как попытка совместить недостатки обоих подходов.

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

S>А в REST это встроено из коробки.
Ничерта в REST не встроено. Он просто даёт по морде HTTP запросом — и вперёд с песней реализовывать. В результате, 99 из 100 REST-серверов не будут нормально поддерживать чуть менее, чем весь HTTP.

S>С учётом разнообразных хидеров аналогом одного REST-ендпоинта будут несколько десятков сигнатур RPC-методов.
Не будут. Делаем нужные параметры запроса явным параметром и всё. Для примера, если что-то типа DownloadFile, то в запрос добавляем опциональные поля типа Range и прочих. В качестве бонуса, не нужно заниматься разбором формата Range.

В результате, на практике GRPC уделывает REST по скорости и надёжности разработки.

Здравствуйте, Cyberax, Вы писали:
C>Ничерта в REST не встроено. Он просто даёт по морде HTTP запросом — и вперёд с песней реализовывать. В результате, 99 из 100 REST-серверов не будут нормально поддерживать чуть менее, чем весь HTTP.
Вы так говорите, как будто это плохо.
А на практике это позволяет делать graceful degradation. Например, мы можем поставить прокси в любом месте соединения между клиентом и сервером (хоть прямой прокси на стороне клиента, хоть реверс прокси на стороне сервера), и получить оптимизацию conditional get, не написав ни строчки кода ни там ни там.
Более того — именно так и делается в 99 из 100 промышленных API, которые отдаются через CDN.

S>>С учётом разнообразных хидеров аналогом одного REST-ендпоинта будут несколько десятков сигнатур RPC-методов.
C>Не будут. Делаем нужные параметры запроса явным параметром и всё. Для примера, если что-то типа DownloadFile, то в запрос добавляем опциональные поля типа Range и прочих. В качестве бонуса, не нужно заниматься разбором формата Range.
Покажите мне реальный (g)RPC API в котором есть опциональные параметры типа Range и прочих.
C>В результате, на практике GRPC уделывает REST по скорости и надёжности разработки.
Ну... Может быть. У меня нет практики работы с gRPC, поэтому я (пока) поверю вам на слово.

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

C>>Ничерта в REST не встроено. Он просто даёт по морде HTTP запросом — и вперёд с песней реализовывать. В результате, 99 из 100 REST-серверов не будут нормально поддерживать чуть менее, чем весь HTTP.
S>Вы так говорите, как будто это плохо.
Да, это плохо. Все ограничения и способности API должны быть описаны в его схеме. По факту в REST это совсем не так.

Например, имеем вот это API: https://docs.docker.com/engine/api/v1.41/#operation/ContainerArchiveInfo — "взять архив файловой системы".

Внимание, вопрос! Как это API будет взаимодействовать с Range?

S>А на практике это позволяет делать graceful degradation. Например, мы можем поставить прокси в любом месте соединения между клиентом и сервером (хоть прямой прокси на стороне клиента, хоть реверс прокси на стороне сервера), и получить оптимизацию conditional get, не написав ни строчки кода ни там ни там.
S>Более того — именно так и делается в 99 из 100 промышленных API, которые отдаются через CDN.
Не видел пока вообще ни одного API, где был бы conditional get. Более того, я даже не видел клиентов, которые его бы поддерживали.

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

C>>Не будут. Делаем нужные параметры запроса явным параметром и всё. Для примера, если что-то типа DownloadFile, то в запрос добавляем опциональные поля типа Range и прочих. В качестве бонуса, не нужно заниматься разбором формата Range.
S> Покажите мне реальный (g)RPC API в котором есть опциональные параметры типа Range и прочих.
То есть? Это будет просто параметр в API.

Типа:

service FileService {
  rpc DownloadData(in DownloadDataRequest) returns (stream DataChunk);
}

message DownloadDataRequest {
   message ChunkRange {
      uint64 offset = 1;
      uint64 size = 2;
   }
   string file_id = 1;
   repeated ChunkRange chunks = 2;
}

message DataChunk {
   uint64 chunk_index = 1;
   uint64 offset = 2;
   uint64 size = 3;
   bytes data = 4;
}

По API сразу понятно что и как использовать. Не надо гадать: "А поддерживает ли API-сервер Range?"

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

S>А что вас удивляет? Сейчас так делают более-менее все. Вот, пару недель назад жена участвовала в конференции удалённо. Аудиовидеостриминг в реальном времени.
S>Благодаря тому, что это было сделано через REST, мы смогли записать полное видео — причём на второй день, записали и первый и второй дни.
S>Потому что вот так вот устроен стриминг — это не fire-and-forget протокол вроде UDP или RTP, а честный HTTP, причём именно в стиле REST. То есть там лежит некоторый ресурс, который мы можем "читать", а кто-то одновременно дописывает новые данные в хвост этого ресурса.

Господи, да что же ты такое несешь *facepalm*.

Здравствуйте, alex_public, Вы писали:
_>Ой, ну к чему эти глупые фантазии))) Двухсторонний канал банально невозможен в REST.
Формально — да, у нас любой запрос в REST является "атомарным". Делаем GET, рассчитываем на хидер Content-Length, вычитываем указанное количество байт, и только потом начинаем разбор.
Однако мы можем несколько отступить от строгих требований, и в ответ на GET получить поток структурированных фрагментов, которые мы будем разбирать, не дожидаясь окончания передачи.
То есть сервер отдаёт столько данных, сколько у него есть, но не закрывает соединение, а продолжает отправлять "сообщения" по мере поступления. Вот вам и "двусторонний" канал.
Более того — в случае внезапного обрыва соединения у клиента есть штатный способ запросить данные не с нуля, а с того байта, на котором произошёл обрыв.
Технологии COMET больше лет, чем AJAX. Кстати, не расскажете, как gRPC обрабатывает ситуацию обрыва соединения? Как клиенту получить остаток потока с того места, до которого он дочитал в прошлый раз?

_>Ну т.е. чтобы это заработало, это надо написать руками. Так и в gRPC тоже самое. В чём отличие то по твоему? )))
Конечно же в обратной совместимости, negotiation и graceful degradation.

_>Ну для начала здесь у нас как раз каноничный срез коллекции. Просто видимо ты запутался и не заметил, что тут у нас коллекцией является не массив с монотонным индексом (типа времени), а словарь (по всем инструментам). И соответственно срез описывается не интервалом "от и до", а полным перечислением ключей.

_>Если же ты хотел именно банальный срез монотонного массива, то там прямо рядом лежит функция https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest с классическими параметрами среза from и to, возвращающая классический кусок массива.

Нет, я не хотел ни весь массив, ни монотонный срез.
Я хотел получить список элементов, изменённых с определённого момента времени. А вы путаете Range с Delta encoding.
Рекомендую прочитать RFC 3229, секцию 4.1, до наступления просветления.

Ну, и с чтением документации у вас некоторые проблемы. Метод https://tinkoff.github.io/investAPI/marketdata/#getcandlesrequest возвращает совсем не подмножество данных https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest, а вообще другие данные.
Что я ожидаю от delta-encoding применительно к https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest?
Пустого массива, если с момента моего последнего запроса не изменилось ничего. Массива из одного элемента, если с момента моего прошлого запроса прыгнул курс доллара (а остальные инструменты остались неизменными), и так далее. Как видим, в теории RPC позволяет такое сделать — но это потребует сразу заложить всё в сигнатуре методов. Я не могу написать сервер, который реализует только часть задокументированного протокола.
Я не могу написать клиента, который договаривается с сервером в стиле "если умеешь — то отдай дельту; если не умеешь — отдай весь список".
Точнее, могу, но мне нужно обладать дьявольской предусмотрительностью. Нужно заранее спроектировать такую возможность и заложить её в сигнатуры. Нужно заранее спроектировать метод договорённостей, когда клиент запрашивает у сервера список тех методов, которые поддерживаются сервером, а сервер отвечает, типа "умею conditinal get, но не умею в ranges" и так далее.
_>И теперь вот вопросик, а как тоже самое канонично описать в REST архитектуре? Просто идеологически тут явно должно быть GET, но при этом передавать массив строк в url как-то крайне печально... )))
Да ничего печального тут нет. Можно и список запихать в URL — в данном конкретном случае сколько там у нас реально инструментов торгуется на бирже? Тысяча? Полторы? Нет никаких проблем запихать хоть "все инструменты, кроме одного" напрямую в URL. В том числе и в компактном виде — сначала упаковав список в какой-нибудь околобинарный енкодинг, а потом в base64.
Потери производительности на "принудительную текстовость" будут пренебрежимо малы по сравнению с сетевыми задержками.
Можно реализовать это вторичными способами — например, сделав метод subscribe, который превращает список интересных нам инструментов в один идентификатор подписки, вслед за которым будут выполняться GET /subscriptions/####.

_>Ааа, ну т.е. "в рамках CRUD можно представить всё, что угодно", если это сложные задачи, а вот простые задачи с помощью CRUD плохо представляются... Понятно, понятно...
Да прекрасно они представляются при помощи CRUD. Трудности возникают тогда, когда у нас требования response time начинают доминировать над требованиями consistency.
Сложная задача — это когда у нас есть развесистая структура предметной области и развесистая логика на серверной стороне.
А мы говорим про задачу, ER-схема которой уместится на одном листочке школьной тетрадки.

_>Так надёжность или сложность? ) Я уже что-то запутался... )))
И надёжность, и сложность.

_>А особенно забавно это всё звучит с учётом того факта, что REST по сути является строгим подмножеством RPC.
Нет, не является. В REST введены концепции, которых в RPC просто нет, как класса. Нет понятия safety, нет понятия idempotence.

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


_>Что-то ты сам себе противоречишь. В предыдущем сообщение же сам признал, что для данной задачи REST не особо подходит.
REST не особо подходит для задачи, где нужно передавать простые данные с минимальной задержкой, при этом потерями при передаче можно пренебречь.
При этом нужно быть очень аккуратным при проверке этих ограничений. К примеру, рассуждения о минимизации задержки бессмысленны, когда у нас клиент расположен в 200мс от сервера. Там накладные расходы на передачу парсинг HTTP-заголовков запроса в REST-подходе составляют единицы миллисекунд. А вот если мы ставим сервер в соседнюю стойку, то разница между 0мс для gRPC stream и 1ms REST request становится существенной.
Осторожность здесь важна для того, чтобы не принимать решение для 200мс ping times на основании рассуждений, которые справедливы для 0мс ping time.

_>Не обязательно в том же дата-центре. Но точно в каком-то дата-центре (а не на домашнем компьютере).
А вы думаете, что датацентр в Новосибирске будет сильно ближе к серверам NYSE по сравнению с домашним компьютером в Новосибирске?
Я вас разочарую: физику не обманешь. Тысяча километров — это тысяча километров, и тридцать хопов — это тридцать хопов.

_>У меня тут один старый сайтик есть, сохраняемый из ностальгических соображений. Он полностью статический. И теперь я кажется начинаю понимать, что он на самом деле сделан по архитектуре REST! Ну у него там есть разные URL'ы, к ним можно послать GET запросы и получить данные...
Отлично. Я вижу, у вас наступает просветление. Ещё немного, и вы узнаете, что Филдинг изобрёл REST как раз при проектировании HTTP.
То есть всё именно так — весь HTTP построен по идеологии REST, а вовсе не наоборот.
Просто сервер, который раздаёт по HTTP файловый контент, реализует REST "из коробки". Благодаря чему прекрасно работают такие решения, как CDN, forward & reverse proxy, а также зеркала сайтов.
А когда мы через HTTP выставляем не файлы, а приложения, то нужно немножечко постараться, чтобы не испортить прекрасную REST архитектуру своими корявыми руками (как это сделали, к примеру, авторы https://tinkoff.github.io/invest-openapi

_>Вообще, когда человек отвечает подобным образом на подобную задачу, то это может означать только одно из двух:
_>1. Он абсолютно не компетентен как инженер (не понимает слов ТЗ и т.п.)
_>2. Он вполне компетентен и всё понимает, но честный ответ на задачу демонстрирует его неправоту, поэтому он начинает вилять и менять ТЗ.

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

_>Забавно, у нас в приложение по сути являющемся RPC клиентом (причём не gRPC, а вообще самодельном на базе WebSocket) в браузере, кнопка back отлично работает. Может всё дело в кривизне рук? )))
Может быть. В принципе, можно и из SOAP изобразить более-менее приличное решение. Правда, там придётся переизобрести с нуля REST, и получить велосипедную его реализацию, не совместимую ни с чем.
Но лучше сразу проектировать приложение с учётом особенностей физической реальности — в частности, ненадёжности коммуникаций и ограниченности полосы пропускания.

_>Да я уже понял, что ты выставишь требование изменения железа по причине того, что оно плохо сочетается с любимой тобой программной архитектурой. Интересно, как тебя на работу принимали с такими подходами? ) Или ты там при приёме скрывал подобные замашки? )))
Меня обычно принимают на работу как раз для того, чтобы я предложил архитектурные решения, дающие нужный результат.
А не для того, чтобы "выставить в интернет протокол удалённого управления вертелкой камеры".
Потому, что далеко не всем очевидно, что надо задумываться не только о единственном позитивном сценарии, типа "один пользователь за бесконечно надёжным каналом с бесконечно большой полосой пропускания отправляет редкие команды", но и над всеми остальными сценариями, которые неизбежно возникнут в практической эксплуатации. Например — что делать, когда один пользователь жмёт "вправо", а другой — "влево".

Мои знания о том, как проектировать вот такие решения, неожиданно неплохо оплачиваются. Чего и вам желаю

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

NB>>то есть будешь колхозить, о чем и речь.
C>Так что там колхозить-то? gRPC можно балансировать классически: https://towardsdev.com/grpc-request-routing-header-based-aws-alb-9934c1b4c67e — в этом примере балансирование на основе заголовка, но можно и по префиксу имени метода.

C>Но я бы явно разделил два endpoint'а.

вопрос не в том, можно или не можно это сделать.
вопрос в том что каждый будет это делать по-своему (или вообще не делать а потом, когда понадобится, судорожно все менять)
в отличие от РЕСТ, где это уже описано.

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

C>Так и в REST оно тоже не "само" делается. Кто-то должен настроить маршрутизацию в зависимости от пути, причём правильно, чтобы это было прозрачно для клиентов.

не в зависимости от пути а в зависимости от метода запроса, семантика которых (методов) четко прописана.

Здравствуйте, night beast, Вы писали:

C>>Так и в REST оно тоже не "само" делается. Кто-то должен настроить маршрутизацию в зависимости от пути, причём правильно, чтобы это было прозрачно для клиентов.
NB>не в зависимости от пути а в зависимости от метода запроса, семантика которых (методов) четко прописана.
Да, в REST это более чётко прописано.

Но тем не менее, в REST нет способа указать гарантии целостности, например. Так что какой-то код может не работать, если GET после PUT будет перенаправляться на кластер, который не обеспечивает read-after-write. Всё равно нужно по обстоятельствам действовать, ровно как и в gRPC.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Вот зачем писать такой длинный текст, чтобы продемонстрировать подобную глупость? То, что ты описал — это даже не близко двухсторонний канал. Двухсторонний, это когда в рамках одного соединения и клиент и сервер могут в любой момент (в том числе даже и совпадающие) инициировать отсылку сообщения на противоположную сторону.
НС>https://en.wikipedia.org/wiki/WebSocket

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

НС>Формально это другой протокол, но по факту очень близок к HTTP и совместим с ним.

Абсолютно не близок и не совместим (не считая возможности использования инфраструктуры http для себя). Ну и главное непонятно каким боком ты хочешь подсунуть WebSocket к REST?

_>>Показываю на пальцах. Берём gRPC. Создаём там функции в полном соответствие с HTTP командами (GET, POST и т.д.). Явно передаём в качестве аргументов (опциональных конечно же) нужные HTTP заголовки. И договариваемся использовать эти функции по правилам REST. Что мы получим в итоге? Правильно, полноценный REST, реализованный поверх gRPC.
НС>Да. И именно так взрослые дядьки и делают. Но тут есть одна проблема. gRPC намного жестче контролирует схему. С одной стороны, это плюс, так как страхует нас от части ошибок. Но с другой стороны — минус — так как вопрос обратной совместимости, очень больной даже в REST, в gRPC становится просто адом. Поэтому, кстати, ведущие собаководы советуют использовать gRPC только для внутрикластерных коммуникаций.

О ужас! Интересно и какой же тогда магией такие ОС как Windows (в которых с формализацией API всё не менее жёстко) могут спокойно развиваться, сохраняя при этом обратную совместимости десятилетиями? ) Видимо где-то в индустрии есть некие скрытые сакральные знания, которые утеряны разработчиками всяких говносервисов... )))

НС>Но даже и в этом случае есть засады. Например, gRPC херит все бенефиты от микросервисной архитектуры, так как бенефиты эти завязаны на крайне слабую связность сервисов между собой через REST протоколы. Как только уровень связности повышается за счет жесткости и специфичности протоколов — в полный рост встают ровно те проблемы, от которых микросервисы должны позволить уйти.

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

_>>Теперь понятно кто тут является чьим подмножеством? )
НС>Почему для тебя это так важно?

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

_>>Задача звучит так: есть готовая железка и ты должен запрограммировать для неё удалённый доступ. Ты уже продемонстрировал, что не смог справиться с этой задачей.
НС>Больше выглядит что не справился ты. Посылать удаленному устройству вот прям команды, которые шлют ему по UDB или чем он там подрублен — это смелое решение. Что будет, к примеру, происходить при сбое прохождения пакетов ты явно не задумывался.

Очевидно ничего не будет. На сервере просто ничего (сообщение то не дойдёт). А у клиента будет код ошибки, о котором при желание можно сообщить пользователю.

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

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

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

Здравствуйте, alex_public, Вы писали:
_>И мой оппонент откровенно слился при решений этой простейшей задачки. Причём слился он очевидно потому, что у него REST головного мозга, а данная задача не очень канонично ложится на эту архитектуру. Но естественно он не мог этого признать и начал тупо вилять, рассказывая о том что надо просто взять другую железку и вот для неё то он уж напишет как надо...
Если хотите — да, я признаю, что в рамках задачи, где применить REST невозможно, невозможно применять REST и придётся жрать, что дают.

Но в рамках пользовательской задачи (а не ограничений, введённых безголовыми проектировщиками железки) REST как минимум не хуже RPC, а в ряде сценариев — лучше.

Если хотите, я приведу вам жизненные примеры.
Вот у меня много лет была сигнализация редкой модели томагавка — 9100. Её рукожопые авторы решили сделать управление в стиле RPC. У 9010 оно в стиле REST: запуск — одна кнопка, стоп — другая. Обе кнопки идемпотентны.
А у 9100 долгое нажатие на кнопку означает "запуск, если заглушен, или стоп, если запущен".
Вот я проклинал её тысячи раз. Сломал два брелка в приступе благодарности к авторам.
Потому, что при плохой связи (а она плохая более-менее всегда; обещанные 400м работают только в чистом поле без ЭМ-источников) эта штука упорно глючила. Плюс дребезг контактов, из-за которого выдержать нужные 3 секунды адски тяжело. В итоге простая вроде вещь занимала по несколько минут — то она потеряет сигнал "туда", и машина не заводится, то потеряет апдейт "обратно" — и я глушу заведённую машину.

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

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

_>>И мой оппонент откровенно слился при решений этой простейшей задачки. Причём слился он очевидно потому, что у него REST головного мозга, а данная задача не очень канонично ложится на эту архитектуру. Но естественно он не мог этого признать и начал тупо вилять, рассказывая о том что надо просто взять другую железку и вот для неё то он уж напишет как надо...
S>Если хотите — да, я признаю, что в рамках задачи, где применить REST невозможно, невозможно применять REST и придётся жрать, что дают.

Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.

S>Но в рамках пользовательской задачи (а не ограничений, введённых безголовыми проектировщиками железки) REST как минимум не хуже RPC, а в ряде сценариев — лучше.

Ещё раз повторюсь, настоящий инженер должен уметь решать задачу в рамках данному ему ТЗ, а не вставать в позу, если ему не нравится доступное железо.

P.S. И кстати с учётом текущей геополитической обстановки, этот навык становится особо востребованным...

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

_>Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.
Это не REST, а RPC.
_>P.S. И кстати с учётом текущей геополитической обстановки, этот навык становится особо востребованным...
То есть вы думаете, что оптопары в РФ будут недоступны? Пессимистичненьно...

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

_>>Я знал (поэтому собственно и привёл этот пример изначально), что тебе это покажется не каноничным. ))) Но кстати интересно, какое из формальных требований REST ты видишь тут нарушенным (и чтобы при этом оно переставало быть нарушенном при наличие экодера)?
S>Representational State Transfer. Для REST главное — передача состояния, а не команд.

Да, это главное. Только надо понимать в каком смысле здесь говорится о передаче состояния. А именно, здесь подразумевается отказ от хранения состояния сервером — всё нужное приходит в запросе.

А если у нас такая задача, что в ней просто нет состояния в принципе?

Кстати, могу тебе ещё один вполне реальный пример привести. Серверу передаются некий скрипт, который он должен выполнить (и возможно прислать какие-то реакции, причём возможно не сразу, — зависит от самого скрипта). У меня вот тут под боком реально передвигается некая штука (и исполняет сложные команды)...

О, тут ещё подумалось... А ведь взаимодействие со всеми базами данных тоже же укладывается в этот сценарий (просто там в роли скрипта SQL и т.п. будут). Как насчёт показать преимущества REST в такой классической задаче? ))) В том смысле что реализовать не доступ к конкретной табличке (собственно это и есть функциональность 90% современных говносервисов в сети), а реализовать в стиле REST универсальный интерфейс доступа к БД, позволяющий выполнить произвольный SQL (для примера) запрос.

А то ты же говорил, что "Во всех случаях, АФАИР, RPC проиграл." и "В рамках CRUD можно представить всё, что угодно."...

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

И это будет абсолютно бесполезная и неудобная для пользователя функция. Потому что если ты будешь показывать ему это значение (а иначе зачем оно тогда?), то он привыкнет что грубо говоря 0 — это направление на север, а 180 — это на юг. А после следующего выключения энергии эти значения станут уже другими.

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

В общем похоже что гениальным архитекторам пока что ещё рано думать о железе...

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Нет, задачка была ответом на тезис собеседника о том, что CRUD (читай REST) подход идеален для абсолютно всех видов задач.
НС>Это где он такое написал?

Нет конечно. Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл.
В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.

Я же говорю, ты как обычно влезаешь, даже не поняв куда.

НС>>>Это я уж не говорю о том, что сравнивать REST (идеологию) и gRPC(конкретный фреймворк) — не самое разумное занятие. Сравнивать можно либо HTTP+JSON с gRPC, либо REST с RPC.
_>>gRPC — это конкретный фреймворк, который набирает в данное время большую популярность.
НС>Ага, и при этом, как правильно заметил Cyberax, взрослые дядьки все равно проектируют для него API в REST стиле.

Т.к. REST — это по сути подмножество RPC, то очевидно что вполне естественная возможность. Правда в тех gRPC интерфейсах, что видел я, чаще всего применялся тип stream, что очевидно является уже выходом из REST подмножества.

_>>Протокол выбирать можно. А необходимость замены железа заявил как раз мой собеседник.
НС>Где он такое написал?

_>Архитектуру можешь плодить какую хочешь. Но ты уже показал, что в рамках REST подхода ты можешь только слиться с невнятными оправданиями.
Почему же? я прикручу к этой железке датчик нуля, сделаю процедуру инициализации, и выставлю REST-протокол по управлению положением.

_>>Похоже ты тут демонстрируешь просто эталонный уровень "я не в теме". )))
НС>Ага, и Антон тоже не в теме. В теме только ты. О чем, собственно, я и написал в предыдущем сообщении.

Не, он то как раз полностью адекватно общается и всё понимает. А вот ты очевидно влез не читая.

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

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

_>>>Подвох в том, что ни в каких текущих реализациях REST это невозможно.
S>>Хм. Я вроде описал способ, которым это делается.

_>Ну что за детских сад? Вот давай ты попробуешь реализовать в стиле REST например тот же самый потоковый протокол Тинькова информации с биржи. Т.е. вот мы подключаемся; подписываемся на информацию о 5 акциях; нам идёт в ответ непрерывный поток этой информации; далее в какой-то момент мы хотим ещё и о какой-то 6-ой акции получать информацию и изменяем свою подписку; и после этого получаем уже поток с информацией о 6 акциях. И всё это конечно в рамках одного соединения. Ну и как ты это сделаешь?
Сделаю POST, в тело которого запишу список 5 акций. Для простоты — в line-delimited JSON. В ответ нам начинает ехать поток обновлений в какой-то кодировке.
Для простоты — line-delimited JSON.
Поток никогда не закрывается. Ни туда, ни обратно. Всё.
Тут, конечно, нарушены некоторые принципы REST, но в целом всё работает
Более того — я ж не обязан делать именно так. Я вполне могу отправить и фиксированный список акций, просто получив в ответ бесконечный поток.

_>>>Восстанавливаешь соединение и снова подписываешься на нужные данные.
S>>Падажжите. Ну так в моей подписке был провал неизвестной длительности.

_>И? Эти данные уже давно стухли.
Ну как это "стухли"?
Вот у меня есть 500 инструментов. Обновляются по разному. Кто-то раз в час, кто-то раз в секунду. Связь на 10 секунд пропала. Мне теперь надо перевычитать цены для всех 500? Изменилось-то за это время может быть 40 позиций. Опять же — как мне убедиться, что между моментами "я прочитал все цены" и "я начал ловить поток изменений" не было потерянных изменений?

_>Так я вроде приводил графики (причём даже не свои, а какие-то дотнетные), но ты сказал что нарисовать всё что угодно можно...
Это потому, что непонятно, какая задача решалась. Я вот показываю примеры, в которых при неустойчивой связи RPC будет гораздо хуже по трафику, чем REST.

_>Так он же стухла уже. ))) Как весь предыдущий стрим собственно — важно только текущее значение и всё.
А что такое "текущее значение"? Вот у меня была последняя цена инструмента 99.40. Он обновляется редко. Я заново подписался на поток, десять минут жду — нету изменений. Какую цену мне предполагать? 99.40? А может там как раз изменение пролетало, пока я моргнул?

_>И снова детский сад? Вот как будто бы ты не знаешь как решается данный вопрос. Что есть две стандартные стратегии: или текущее соединение блокирует все новые или же любое новое соединение выкидывает предыдущее. И в разных задачах используется или один или второй подход.
Здорово. То есть теперь мы не можем посмотреть одну и ту же камеру с двух компьютеров.
Смотрите, как быстро вы закапываете свой продукт Меня всегда изумляли ситуации, когда люди намеренно делают продукт хуже, вместо того, чтобы немножко подумать.
Ну, как сони, у которой половина продуктов не могут одновременно заряжаться и работать

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

_>>>И снова детский сад? Вот как будто бы ты не знаешь как решается данный вопрос. Что есть две стандартные стратегии: или текущее соединение блокирует все новые или же любое новое соединение выкидывает предыдущее. И в разных задачах используется или один или второй подход.
S>>Здорово. То есть теперь мы не можем посмотреть одну и ту же камеру с двух компьютеров.

_>Не смотреть камеру, а иметь доступ к интерфейсу управления. Ты вот видел когда-нибудь, чтобы например к одному дрону можно было подключиться с двух контроллеров? Может это тоже недостаток продукта? )))

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

Здравствуйте, alex_public, Вы писали:
_>О, я тут заметил что как-то пропустил твоё старое сообщение (я вообще через уведомления в почте читаю этот форум).
Ну, это типичные издержки RPC-style коммуникации на основе "пересылки оповещений о событиях".
Гораздо надёжнее — REST-подход: https://rsdn.org/Users/Private/MyRsdn.aspx?go=answers
Заходите по этой ссылке, видите список всех ответов на ваши сообщения.
Заботливый браузер (даже если это Links) подсвечивает чёрненьким те из них, которые вы ещё не читали

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

_>Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )

А вот и фидбек про реальный пример подъехал: https://rsdn.org/forum/life/8279445.1

Автор: Real 3L0
Дата: 19.05.22

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

Вот, кстати, что на счет Go?

Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?

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

H>Моё резюме: берите го, если вам позарез нужны горутины. В остальных случаях не рекомендую. Да и в том же C++ тоже есть корутины, только с более мудрёным синтаксисом, явной передачей контекста и т. д., короче в го корутины реально удобнее.

Ну, на самом деле, Go как раз позиционируется именно как язык, в котором нет и никогда не будет всех этих крутых и совершенно непостижимых фич, которыми столь славен C++.

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

S>>Вот, кстати, что на счет Go?
S>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
O>Хреновая поддержка динамических библиотек. Ее фактически нет.

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

S>>>Вот, кстати, что на счет Go?
S>>>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
O>>Хреновая поддержка динамических библиотек. Ее фактически нет.
Pzz>Ее нет в том смысле, что невозможно написать динамическую библиотеку на Go. Но динамические библиотеки, написанные на других языках, с сишными соглашениями о вызовах, из Go без проблем можно использовать.
Да даже написать вроде можно, но толку с нее мало — она не может взаимодействовать с другими библиотеками как го-шная библиотеке.
В плюсах нет никаких проблем дергать другие библиотеки написанные на плюсах за классы. Надо только проявлять некоторую осторожность, но для плюсовика — осторожность — норма жизни Неосторожные плюсовики, как неосторожные саперы — рано выбывают из профессии.