Информация об изменениях

Сообщение Re[2]: Какой язык стоит выбрать для написания микросервисов от 29.05.2022 14:25

Изменено 30.05.2022 10:10 Ziaw

Re[2]: Какой язык стоит выбрать для написания микросервисов
Здравствуйте, Reset, Вы писали:

R>Развертывание на хостинг подразумевает также выкладывание туда всего JRE с соответствующими требованиями по памяти для Java. В общем это не микросервис.

R>А его ты где хостить собрался? IMHO, современный сервер = Linux. Насколько .NET Core готов к микросервисам? Насколько ты к нему готов? И каковы там требования к месту на диске и памяти (думаю, аналогично Java).

Микросервис это про SRP. JVM и .net занимают место слое образа, это очень дешево. Инфраструктурный слой для http или grpc может быть очень непрожорливым. Остальное — дело логики, а логика на этих платформах не факт, что съест ресурсов больше других при прочих равных.

R>Go вполне себе вариант.


Чем? Простотой билда докер имиджа? Это похоже на выбор пхп потому, что залил по фтп и все работает.

Выставить что-то через http или grpc в Go не сильно проще (нет такой значимости, задача решается один раз и навсегда). На уровне докер имиджей это черный ящик с торчащим портом наружу, разницы никакой. Остается уровень кода бизнеслогики.

R>Python — тормозной и примитивный. Осилит каждый (даже если не хочет).


R>JS (Node.js) — как Python, только сильно современнее, динамичнее развивается и есть статическая типизация в виде TypeScript.


R>GoLang — быстрый и лишь слегка сложнее, чем Python, уже даже умеет Generic'и. Однако, много рутинного кода, самая дурацкая схема обработки ошибок. Осилит любой желающий. Профессионалу быстро надоест (компенсируется либо баблом, либо баблом и карьерным ростом).


R>Rust — быстрый как C++, проще C++, возможностей больше, чем у C++, гораздо удобнее C++. Рутинного кода мало, обработка ошибок через Result<Type,ErrorType> (а-ля std::expected). Осилит любой профессионал. Мутная ситуация с поддержкой долгоживущего кода (edition меняется каждые 3 года и непонятно, что делать со старыми модулями в случае изменения их кода, опыт еще не накоплен).


У питона при всей его тормознутости куча очень оптимизированных библиотек. Js против этого может выставить наверное только наличие TypeScript, потому что практически вся его современность это сахар к асинхронности, сахар к ООП, который там не пойми зачем и немного паттерн-мэтчинга. Асинхронность скорее вредит простоте и поддерживаемости проекта, хотя безусловно может быть полезна для экономии вычислительных ресурсов.
Re[2]: Какой язык стоит выбрать для написания микросервисов
Здравствуйте, Reset, Вы писали:

R>Развертывание на хостинг подразумевает также выкладывание туда всего JRE с соответствующими требованиями по памяти для Java. В общем это не микросервис.

R>А его ты где хостить собрался? IMHO, современный сервер = Linux. Насколько .NET Core готов к микросервисам? Насколько ты к нему готов? И каковы там требования к месту на диске и памяти (думаю, аналогично Java).

Микросервис это про SRP. JVM и .net занимают место в слое образа, это очень дешево. Инфраструктурный слой для http или grpc может быть очень непрожорливым. Остальное — дело логики, а логика на этих платформах не факт, что съест ресурсов больше других при прочих равных.

R>Go вполне себе вариант.


Чем? Простотой билда докер имиджа? Это похоже на выбор пхп потому, что залил по фтп и все работает.

Выставить что-то через http или grpc в Go не сильно проще (нет такой значимости, задача решается один раз и навсегда). На уровне докер имиджей это черный ящик с торчащим портом наружу, разницы никакой. Остается уровень кода бизнеслогики.

R>Python — тормозной и примитивный. Осилит каждый (даже если не хочет).


R>JS (Node.js) — как Python, только сильно современнее, динамичнее развивается и есть статическая типизация в виде TypeScript.


R>GoLang — быстрый и лишь слегка сложнее, чем Python, уже даже умеет Generic'и. Однако, много рутинного кода, самая дурацкая схема обработки ошибок. Осилит любой желающий. Профессионалу быстро надоест (компенсируется либо баблом, либо баблом и карьерным ростом).


R>Rust — быстрый как C++, проще C++, возможностей больше, чем у C++, гораздо удобнее C++. Рутинного кода мало, обработка ошибок через Result<Type,ErrorType> (а-ля std::expected). Осилит любой профессионал. Мутная ситуация с поддержкой долгоживущего кода (edition меняется каждые 3 года и непонятно, что делать со старыми модулями в случае изменения их кода, опыт еще не накоплен).


У питона при всей его тормознутости куча очень оптимизированных библиотек. Js против этого может выставить наверное только наличие TypeScript, потому что практически вся его современность это сахар к асинхронности, сахар к ООП, который там не пойми зачем и немного паттерн-мэтчинга. Асинхронность скорее вредит простоте и поддерживаемости проекта, хотя безусловно может быть полезна для экономии вычислительных ресурсов.