Какой язык стоит выбрать для написания микросервисов - Компьютерные священные войны

I>С++ники такие же люди, как и другие разработчики, а потому им свойственно делать ошибки "у нас всё быстро, незачем и думать"

Отлично сказано.
Очень часто можно услышать "язык XXX — медленный, поэтому давайте напишем вот эту часть на С/С++ и добавим bindings в виртуальную машину языка XXX, оно тут же станет быстрым". И что обидно, такие деятели в самом деле реализуют всякие куски на С, тащат внутрь виртуальной машины, рушат машину, стреляют по памяти, и портят жизнь еще кучей методов.

Берешь потом, читаешь этот ужас, пишешь красивый нативный код безо всякого С, и, ВНЕЗАПНО, оно оказывается даже быстрее, чем та поделка на С.
Почему? Да потому что низкоуровневый язык — ни разу не гарантия быстрого кода. Часто даже наоборот.

S>Хорошо, code first плохо,

Code first как раз хорошо. Спасает от многих ошибок, и от необходимости мириться с "генерированным кодом".

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

А вот это — АдЪ и ИзраильЪ.

S>Я так понимаю, что в данном случае xml подобный язык это вариация code first или нет?

XML-подобный язык — это DSL. Язык схемы. Как правило, не Turing Full, хотя зачастую делают следующий шаг и приделывают уже turing full язык, типа Питона, для генерации оных XML-ей, ибо вручную их писать становится сложно). См. "configuration complexity clock".

S>О чем речь, о каких обработчиках и для чего?

Современные программы представляют из себя некий main loop процесса:

receive
message1(param1): [обработать message1, отправить ответ в процесс param1]
message2(param2, param3): [отправить message1(param3) в процесс param2]

Если посмотреть на эту конструкцию внимательно, то мы здесь увидим... ту самую схему! Которую можно попросту сгенерировать:

<interface name="myprogram">
<call name="message1">
<argument name="param1" type="process_id">

Это — code first подход. Из него можно генерировать схему (как, скажем, можно генерировать схему из аннотаций ORM).

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

S>>Хорошо, code first плохо,
SD>Code first как раз хорошо. Спасает от многих ошибок, и от необходимости мириться с "генерированным кодом".
S>> схема генерируется простеньким DSL (типа xml подобного языка на коленке)
SD>А вот это — АдЪ и ИзраильЪ.
S>>Я так понимаю, что в данном случае xml подобный язык это вариация code first или нет?
SD>XML-подобный язык — это DSL. Язык схемы. Как правило, не Turing Full, хотя зачастую делают следующий шаг и приделывают уже turing full язык, типа Питона, для генерации оных XML-ей, ибо вручную их писать становится сложно). См. "configuration complexity clock".

Пишем на осн. языке xml-подобный язык для схемы. И вроде у нас code first, все должно быть хорошо. Т.е. в основе
язык, например, c#, на котором написан наш xml-подобный dsl, который генерирует схему, но это... плохо.

И опять же -- one level of indirection и т.п. хорошие штуки... Т.е. если code first -- грамотный подход, то почему тогда
dsl -- плохо? Ведь это промежуточное звено, one level of indirection. Спец. люди без погружения в осн. язык могут решать
проблемы на dsl. Генерируем dsl, кот. генерирует схему.

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

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

S>>> Ты пробовал?
vaa>>Так точно!
S>Ну вот редиска ты!
S>Я так понимаю, что за компиляцию в Native отвечает DNNE
S>https://github.com/AaronRobinsonMSFT/DNNE
S>https://github.com/AaronRobinsonMSFT/DNNE/blob/master/src/msbuild/DNNE.props

S>Вот и верь тебе после этого!

хз, я делал все по инструкции. publish -c release --selfcontained --runtime linux-x64
и даже как будто угадал с размером:

Scenario    ReadyToRun    NativeAOT
Compile CoreLib    4182 ms    3512 ms
Compile HelloWorld    185 ms    49 ms
Configuration    Size
ReadyToRun    34.8 MB
NativeAOT    17.6 MB

что я сделал не так?

S>Пишем на осн. языке xml-подобный язык для схемы.

Зачем?

S> И вроде у нас code first, все должно быть хорошо. Т.е. в основе

Сode-first — это когда вы просто пишете код. Реализацию. На реальном языке. Пример, скажем, на Erlang:

-module(myservice).
-export([get/1, put/2]).

-spec get(Key :: string()) -> term().
get(Key) ->
    binary_to_term(file:read("/tmp/" ++ Key)).

-spec put(Key :: string(), Value :: term()) -> ok | {error, term()}.
put(Key, Value) ->
    file:write("/tmp/" + Key, term_to_binary(Value)).

Из этого кода с помощью reflection достаются спеки функций get и put. Если их нужно использовать на другом языке, на этом самом _другом_ языке можно создать proxy, который будет выглядеть "как родной" для этого языка.

Если ну ОЧЕНЬ хочется, конечно, можно из этого кода сгенерировать схему а-ля protobuf/thrift/MicrosoftCOM/CORBA/прочий_вариант_ASN1. Только зачем? Это не упростит задачу ни для кого. Удобнее читать на родном языке.

S>И опять же -- one level of indirection и т.п. хорошие штуки...

Не совсем понял, one level of indirection, это хорошо или плохо? Зачем он нужен человеку? Компилятору — пожалуйста. Примерно как файл после препроцессора, он, в общем-то, может создаваться, но программисту его (обычно) читать не надо, это чисто промежуточная стадия между исходником и следующим этапом компиляции.

S>dsl -- плохо? Ведь это промежуточное звено, one level of indirection. Спец. люди без погружения в осн. язык могут решать
S>проблемы на dsl. Генерируем dsl, кот. генерирует схему.

Конечно, плохо. Почему-то очень много программистов (и еще больше, гм, "архитекторов") считают, что вот они-то точно создадут DSL, который будет легче понимать. И который мы заставим наших кастомеров выучить, потому что мы думаем, что они тупее нас, и не смогут освоить широко распространенные и куда более популярные языки программирования. А потом идет следующая ошибка — этот DSL становится source of truth, фреймворком, который затем подминает вас основной язык. И вы начинаете "программировать" на этом DSL. Из которого затем получается (как правило) не идиоматичный код на целевом языке программирования. Или, еще хуже, получается DSL, который в теории должен быть "эсперанто" для всех языков (привет, Thrift), но по факту выходит, что кроме одного-единственного языка (здравствуй, С++) этот DSL нормально не транслируется.

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

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

S>>Про ситуацию где разрабы вынуждены брать в руки говно никто не говорит. Посочувствую, но и только ибо выбора у них нет.
F>Чего? При чем тут твое говно? Почему не может быть два шикарных продукта от двух поставщиков на разных, опять же шикарных, версиях либ?
Может быть, почему нет? Два несвязанных продукта.
Но ты увёл разговор в сторону. Всё как всегда. Все пытаются срулить с обсуждения и то на личности уходят, то в детали зарываются.

F>>>Зачем повторять? Это же никого не интересует.

S>>Да потому что вы не слышите.
F>Выделил.
Поэтому и не слышите.

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

I>>>Хороших примеров ты не видел, но утверждаешь, что их нету. Это специфика твоей работы — ковбойские интервенции. Там где все хорошо, тебя туда не зовут.
S>>Но опыта у меня нет, ага.
I>http://rsdn.org/forum/flame.comp/5791789.1
I>Вот этот твой код говорит о том, что ты пишешь как вечный студент. Не думаю, что ситуация изменилась за 8 лет.
ЧСХ, там рядом ссылка на проект целиком, но ты дал ссылку именно какую дал.

I>>>Не нашлось, что очевидно. Что там у тебя? "Уууу, тормоза, уууу, говнокод". Что конкретное есть? А то я тормоза и говнокод чаще всего видел/вижу в джаве и С++.
S>>А я в жаве и ноде. Реже в питоне.
I>Я ж говорю — ты вещаешь как мастер из сервиса. В суппорте много нода потому, что его вообще много где используетя, а не потому, что он кривой.
Нода — лишняя деталь, понижающая надёжность системы (проекта, сервисов) просто потому что она есть. Если можно обойтись без неёё — лучше это сделать.

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

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

I>>Именно. Хороший фронтенд невозможно сделать без правильного бакенда. И вот здесь лучше всего справляется Нода. Идеально — когда хотя бы часть бакенда пишут сами фронтенды так, как им нужно.
SD>Вот это сильное заявление. "Месье знает тольк в извращениях" (С)
SD>Делать бэкенд на нод.жс звучит как проклятие для сколь-нибудь масштабных проектов.
Щас и тебя обосрут.

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

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

I>>>Жалобы на тормоза были и будут во все времена, хоть на С++, хоть на Ноде, хоть на чем угодно.
S>>Соглашусь но скажу только чем низкоуровнее язык тем меньше будет жалоб.
I>Ога. Тормоза большей частью берутся не от языка, а от ошибок в разработке, вынужденных, и невынужденных.
Плюс к этому и язык.

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

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

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

I>>>Решение уже найдено — бакендов на фронт не пускать. Дешевле дать ноду фронтендам, и ограничить их архитектурно, например, module federation + edge service.
S>>Опять бабло.
I>Именно. Такое решение оказалось наибоее жизнеспособным.
Говноспособным.

I>>>И с дотнетом был тоже самое, и с джавой, и с питоном.
S>>И все ржут до сих пор? На чом же тогда писать если куда ни плюнь — все ржут до сих пор?
I>Ржут до сих пор с веба на с++
А я ржу с того как вы следуете моде и мнению других. Своего мнения нет, не было и не будет.
Почему веб на плюсах нельзя? Религия?

I>Взгляни на себя http://rsdn.org/forum/flame.comp/5791789.1
Там рядом ссылка на гитхаб но ты именно эту притащил. Чем она тебе выгодна?

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

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

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

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

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

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

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

S>>А если проект вырастет за пределы "склеить пару строк"? Что тогда? Стек поменяют или начнут игры с совой и глобусом? Учитывая тот факт что "а от стек выбран, команда есть, проект пилится, балобаблобабло" — очевидно что сове не повезло.

SD>Классика же, самоподдерживающееся пророчество.
SD>На основе прошлой статистики известно, что 90% новых проектов пойдут в мусорку. Поэтому технология не имеет значение — лишь бы быстрее (time to market). А раз так, то зачем думать о будущем — пилить надо. Что, в свою очередь, может косвенно вести к провалу проекта (из-за немасштабирующейся технологии). Какой будет сделан вывод? Правильно, все тот же, 90% проектов пойдут в мусорку...
И выплывшие — такое же говно но им повезло.
В результате все в говне по уши и почему то считают что так и надо. Более того — требуют от других такого же говна и любое инакомыслие в штыки. Почему? Потому что так принято.

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

S>>Рядом ссылка не репозиторий. Развлекайтесь раз вам весело ))
F>Ты уже овер 15 лет нас тут развлекаешь.
Ну я же вижу что вам нравится

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

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

I>>>А в продакшне значит хост можно хламить, да?

S>>А в продакшене `apt install lib1 lib2 lib3 myproject`, следом настройка и запуск.
I>

И как ты будешь совмещать компоненты, которые написаны на разных версиях джавы/дотнета/С++/питона ?
Воооот! Я об этом и пишу! Это и пытаюсь донести что не надо так! Обновляйтесь вовремя, вместе с целевым дистрибутивом! Настройте взаимодействие между командами! Требуйте такого-же поведения от окружающих!

Ну и к слову...
Жава — легко. Она их коробки в /opt отдельно ставится в отдельный каталог, мимо общепринятого /usr. Так что достаточно просто PATH сменить.
Дотнет из коробки, сам умеет несколько своих версий. В этом он аокачественнее жавы. Да и вообще — покачественнее заметно.
Плюсы... Что не так с плюсами? Собрано с старой стандартной библиотекой? Или что?
С питоном сложнее чем с первыми двумя но можно пойти по пути жавы.

А правильное решение — обновляться вовремя.

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

НС>Image: eboknJp.png
НС>Все что нужно знать про полезность твоего кода.
А, у тебя качество кода измеряется в лайках? У тебя правда с головой ок? Ты точно программист?

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

I>>Штука в том, что фронт меняется очень часто, и все время растет в сложности по ряду причин.

P>Меняется, это заметно. Я в вебе полный теоретик и не знаю, с чем оно связано.
P><Режим КСВ>
P>Когда-то личный кабинет банка летал со свистом на нетбука с Атомом. А сегодня не спеша открывается на новом i5, причем проц загружен на 100%.
P><Режим КСВ>

Рискну предположить, что в старом варианте страница была легкая и рендерилась на сервере (server-side rendering, SSR), а в новом — рендерится на клиенте (client-side rendering, CSR), да еще и сделана на каком-нибудь достаточно тяжелом фреймворке.

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

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

S>>Про потоки слышал? Пока один одни данные ждёт — ко второму ещо клиент приходит.
P>Слышал. В C# асинхронщину вообще завезли. Задачу создал, запустил, и т. д. Но как асинхронщина поможет, если я обратился к, назовем это так, главному компьютеру, и мне нужно дождаться результата. А все остальное уже выполнено. А служба, отвечающая за связь с Главным Компьютером, не умеет в многопоточность. Пример, кстати, реальный. Эту службу потом заменили, но несколько лет она работала.
Никак не могу понять при чом тут твой код...

S>>Исключения — нештатное, форсмажор. Чтото пошло совершенно не так.
P>И что? Память освобождать не нужно? В случае нештатного поведения требуется сделать что-то, чтобы программа не упала и выдала внятное сообщение об ошибке. Если это сервер, записать в лог и вернуться в исходное состояние.
Нужно думать как исправить ошибку и выпустить релиз без неё а не про память.

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

S>>Перегибаешь.
P>Нет. Но все равно, в КСВ можно.
А ну раз КСВ то и вна послать можно так чтоли?

S>>И у меня был. Неделю искал. ЧСХ, с умным указателем связано было. Что именно — не помню — лет пять прошло.
P>Небось auto_ptr в функцию передавал?
Говорю же — не помню.

P>Вот, а сборщик мусора помогает как раз в таких случаях. Заметь, я не утверждаю, что он решает проблемы. Он только инструмент. Но в случае серверов очень помогает.
S>>Создал — объект пожил — удалил.
P>Но если делать так, как ты предлагаешь, то объект не всегда будет удален.
Ну если накосячил в коде то не всегда, да.

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

S>>Контейнеры это в первую очередь когда две команды не осилили взаимодействие между собой и поприкрутили к своим проектам разные версии библиотеки. Не обновлять же! есть же изоляция!
SD>Можно, конечно, и так это описать.
Так это в первую голову и есть.

SD>По сути же контейнеры, равно как и микросервисы, решают ту же задачу сосуществования разных технологических стеков путем, да, дублирования оных стеков начиная с какого-то уровня (зависит от того, как сделан контейнер — виртуалки могут даже ядро ОС разное предоставлять, тогда как легковесные ядро будут делить).
Спасибо, кэп. Что бы мы без вас делали?

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

	От:	SkyDance
	Дата:	07.06.22 23:41
	Оценка:

	От:	SkyDance
	Дата:	07.06.22 23:52
	Оценка:	1 (1)

	От:	Sharov
	Дата:	08.06.22 00:01
	Оценка:

	От:	vaa
	Дата:	08.06.22 02:38
	Оценка:

	От:	SkyDance
	Дата:	08.06.22 03:47
	Оценка:	1 (1)