Go, java, c# ?

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

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

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

Вот мое IMHO по поводу языков для веб сервисов/микросервисов (по возрастанию сложности и эффективности):

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

Go или node.js. Java слишком тяжеловесная. Насчёт C# не знаю. Python стоит рассмотреть.

T>Go, java, c# ?
PHP

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

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

Ну в 7 ке обещают Native AOT

https://github.com/dotnet/runtime/issues/61231

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

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

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

T>> c# ?
R>А его ты где хостить собрался? IMHO, современный сервер = Linux. Насколько .NET Core готов к микросервисам?

Вот это как раз у него самое-самое применение. С GUI там тяжело было, а веб-сервера и микросервисы это первым делом в core прорабатывали.

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

T>Go, java, c# ?
Если вопрос такой стоит, то выбирайте язык, который лучше всего знаете.
С т.з. гибкости, кол-ва доступных библиотек, фреймворков, развитости инфраструктуры, етс, то конечно java.

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

vsb>Go или node.js. Java слишком тяжеловесная. Насчёт C# не знаю. Python стоит рассмотреть.
Java она разная. При желании всё хорошо упаковывается, тут вот пишут, что docker image можно уложить в 50мб.

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

T>Go, java, c# ?

А ты знаешь какой-нибудь из этих языков?

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

T>Go, java, c# ?

Поскольку мы на RSDN, то C#.

У меня микросервисы в виде амазоновских лямбд на C# вполне себе работают.

Здравствуйте, 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, потому что практически вся его современность это сахар к асинхронности, сахар к ООП, который там не пойми зачем и немного паттерн-мэтчинга. Асинхронность скорее вредит простоте и поддерживаемости проекта, хотя безусловно может быть полезна для экономии вычислительных ресурсов.

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

T>Go, java, c# ?
Весь смысл микросервисов — в том, что нет одного языка, навязанного монолитом.
Выбирайте тот язык, на котором вам комфортно писать.
Может быть, даже несколько — для каждого микросервиса решаем вопрос отдельно.
Если решение было принято неудачно — ничего страшного; в микросервисе не так много кода, чтобы было жалко его выбросить и переписать на более другом языке.

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

vsb>>Go или node.js. Java слишком тяжеловесная. Насчёт C# не знаю. Python стоит рассмотреть.
·>Java она разная. При желании всё хорошо упаковывается, тут вот пишут, что docker image можно уложить в 50мб.

С точки зрения общепринятого использования Java это Spring Boot. И дело тут даже не в docker image, хотя в том числе и в нём, а в долгом запуске (проблемы со всякими лямбдами) и неумеренном потреблении памяти (от 500 MB на каждый сервис можно сразу закладывать).

В теории — да, можно написать без библиотек всё, сделать GraalVM-ом, но так никто не пишет. А будут писать так, как умеют. А на go — пишут.

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

T>Go, java, c# ?

Попробовать это https://vibed.org/
или rust

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

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

Это из продающего микросервисного рекламного буклета, реальность немного печальней. Микросервисная система маложизнеспособна без нижележащей платформы, обеспечивающей мониторинг, логгирование, трассировку, service discovery, отказоустойчивость. А это приличный объем кода, который никто портировать на n языков не будет.

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

R>>Go вполне себе вариант.
Z>Чем? Простотой билда докер имиджа?
В java есть jib. Пару строчек в mvn/gradle и всё собирается как надо — Очень быстро и эффективно по слоям.

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

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

vsb>>>Go или node.js. Java слишком тяжеловесная. Насчёт C# не знаю. Python стоит рассмотреть.
vsb>·>Java она разная. При желании всё хорошо упаковывается, тут вот пишут, что docker image можно уложить в 50мб.
vsb>С точки зрения общепринятого использования Java это Spring Boot. И дело тут даже не в docker image, хотя в том числе и в нём, а в долгом запуске (проблемы со всякими лямбдами) и неумеренном потреблении памяти (от 500 MB на каждый сервис можно сразу закладывать).
Даже в spring приложение секунд за 5 стартует. Как правило всякие соединения с инфрой, прогрузки кешей и т.п. занимает большую часть времени. Если хочется минимизировать, можно поглядеть на какой-нибудь micronaut — но это уже premature optimisation начинать с такого.

vsb>В теории — да, можно написать без библиотек всё, сделать GraalVM-ом, но так никто не пишет. А будут писать так, как умеют. А на go — пишут.
Кому надо — пишут. Просто мало кому нужно. Добавить планку RAM — банально дешевле, чем искать go-программистов.

Здравствуйте, scf, Вы писали:
scf>Это из продающего микросервисного рекламного буклета, реальность немного печальней. Микросервисная система маложизнеспособна без нижележащей платформы, обеспечивающей мониторинг, логгирование, трассировку, service discovery, отказоустойчивость. А это приличный объем кода, который никто портировать на n языков не будет.
Всё это есть и на Go, и на TS/JS, и на C#.

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

R>

JS (Node.js) — как Python, только сильно современнее, динамичнее развивается и есть статическая типизация в виде TypeScript.
Это не микросервис будет, а говносервис. Ноду придумали для фронтендеров, которым лень изучать другой язык и которые "я художник я так вижу". Такое себе, короче.

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

·>Java она разная. При желании всё хорошо упаковывается, тут вот пишут, что docker image можно уложить в 50мб.

В памяти или на диске?