Size: a a a

2020 June 22

ИМ

Илья Макеев... in ctodailychat
На симфе с апи платформой только осторожно её надо уметь готовить
источник

ИМ

Илья Макеев... in ctodailychat
А так все щелчком пальцев делается, с доктриной вообще проблем не будет, эластик стоит самому реализовывать если надо
источник

M

Mike in ctodailychat
Mike
А с RN не так было несколько лет назад? Да и сейчас?
Просто выбирая кроссплатформенное решение нужно быть всегда готовым к тому, что придется писать что-то платформозависимое, если это решение вообще такое позволяет:)
источник

AS

Alexandr Subbotin in ctodailychat
Сергей Аксёнов
Всем привет! Если вам хочется попрокрастинировать этим солнечным утром по московскому времени - вот какую тему хочу вбросить.

На вопрос "какой язык/фреймворк выбрать для монолитного REST API бэкенда нового проекта", который мне задают регулярно, я сам всегда отвечаю - те, где у тебя/твоей команды уже есть максимум компетенций. А недавно так получилось, что я этот вопрос задал себе. И поняв, что владею в достаточной степени несколькими стеками, и овладеваю новыми тоже достаточно быстро и эффективно - на верхние позиции выходят критерии типа:

- зрелость и беспроблемность (вероятность словить какие-то неразрешимые глюки или ограничения в языке/фреймворке, см. Flutter)
- доступность и стоимость инженеров (гоферов пылесосят с рынка)
- перспективы в ближайшие 5 лет (точно не Perl)
- экосистема библиотек/пакетов (leftpad)
- аффилированность с FAANG и другим крупняком (Go всегда будет языком для Google, а потом для остальных, Rust явно сильно затачивается под Mozilla Foundation)

И как-то получилось, что на первом месте незаметно оказались PHP и Symfony (либо Slim для менее развесистых проектов).

На второе аккуратно ставлю Kotlin/Spring с мыслью, что нехватку нативных библиотек всегда можно восполнить Java-наследием, и опасением конкурировать за инженеров с мобильной разработкой.

На третье - Python/Django, но уже с мыслью о конкуренции с рынком ML/data analysis.

Не готов рассматривать Java (рынок рабочей силы в основном состоит из инженеров кровавого энтерпрайза, которые плохо приспосабливаются к режиму стартапа), Go (людей мало и они дорогие, язык не заточен под REST-парадигму и большие монолиты), Typescript (там наведённый ад от экосистемы фронтенда), Ruby (мало людей, мало новых проектов, много легаси), .NET (сильная привязка к экосистеме Windows).

Какие ещё идеи, или поспорьте со мной, может быть?
> мало людей, мало новых проектов, много легаси)

А если сейчас людей в команде хватает, важны ли первые 2 пункта? Ну и про легаси непонятно
источник

SS

Slava Savitskiy in ctodailychat
Илья Макеев
На симфе с апи платформой только осторожно её надо уметь готовить
так это же про любую технологию :)
источник

СА

Сергей Аксёнов... in ctodailychat
Mike
А с RN не так было несколько лет назад? Да и сейчас?
Не погружался в это глубоко, но по крайней мере сейчас такого ада там не наблюдается, по ощущениям. Впрочем, это не вполне релевантно, обсуждение больше про бэкенд)
источник

СА

Сергей Аксёнов... in ctodailychat
Παύλος ☃️ Σ
Kotlin/Spring уже по определению Java-наследие, Kotlin/Ktor ещё может быть нет (и то только в теории)
Spring очень под REST заточен, насчёт Ktor нет уверенности, хотя в этом направлении не очень его трогал, только один очень реактивный сервис на вебсокетах.
источник

СА

Сергей Аксёнов... in ctodailychat
Παύλος ☃️ Σ
Kotlin/Spring уже по определению Java-наследие, Kotlin/Ktor ещё может быть нет (и то только в теории)
У нас есть уже минимум два сервиса на Spring, где нет ни одной строки на Java)
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
Сергей Аксёнов
У нас есть уже минимум два сервиса на Spring, где нет ни одной строки на Java)
Вашей строчки на Java
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
Но под капотом там всё та же Java
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
Это не хорошо/плохо, просто это тот же Java стек, просто другой язык
источник

СА

Сергей Аксёнов... in ctodailychat
Παύλος ☃️ Σ
Вашей строчки на Java
Это я готов терпеть, пока оно не вылезает из под капота) И даже какие-то Java-библиотеки подключать.
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
Сергей Аксёнов
Это я готов терпеть, пока оно не вылезает из под капота) И даже какие-то Java-библиотеки подключать.
Абстракция протечет
источник

СА

Сергей Аксёнов... in ctodailychat
Παύλος ☃️ Σ
Это не хорошо/плохо, просто это тот же Java стек, просто другой язык
Это JVM-стек, я бы сказал.
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
Сергей Аксёнов
Это JVM-стек, я бы сказал.
Да, можно так
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
И у вас на WebFlux? С корутинами?
источник

СА

Сергей Аксёнов... in ctodailychat
Παύλος ☃️ Σ
Абстракция протечет
Абстракции всегда протекают( Но Kotlin, как я понимаю, и задумывался с возможностью миграции с Java и параллельной работы двух кодбаз.

Да, на WebFlux с корутинами.
источник

ΠΣ

Παύλος ☃️ Σ... in ctodailychat
Сергей Аксёнов
Абстракции всегда протекают( Но Kotlin, как я понимаю, и задумывался с возможностью миграции с Java и параллельной работы двух кодбаз.

Да, на WebFlux с корутинами.
MPP и Native сильно позже появились, изначально JVM/JS
источник

Y

Yaroslav in ctodailychat
Сергей Аксёнов
У нас есть уже минимум два сервиса на Spring, где нет ни одной строки на Java)
У меня куча сервисов только с main и без кода
источник

E

Eugene in ctodailychat
Сергей Аксёнов
Всем привет! Если вам хочется попрокрастинировать этим солнечным утром по московскому времени - вот какую тему хочу вбросить.

На вопрос "какой язык/фреймворк выбрать для монолитного REST API бэкенда нового проекта", который мне задают регулярно, я сам всегда отвечаю - те, где у тебя/твоей команды уже есть максимум компетенций. А недавно так получилось, что я этот вопрос задал себе. И поняв, что владею в достаточной степени несколькими стеками, и овладеваю новыми тоже достаточно быстро и эффективно - на верхние позиции выходят критерии типа:

- зрелость и беспроблемность (вероятность словить какие-то неразрешимые глюки или ограничения в языке/фреймворке, см. Flutter)
- доступность и стоимость инженеров (гоферов пылесосят с рынка)
- перспективы в ближайшие 5 лет (точно не Perl)
- экосистема библиотек/пакетов (leftpad)
- аффилированность с FAANG и другим крупняком (Go всегда будет языком для Google, а потом для остальных, Rust явно сильно затачивается под Mozilla Foundation)

И как-то получилось, что на первом месте незаметно оказались PHP и Symfony (либо Slim для менее развесистых проектов).

На второе аккуратно ставлю Kotlin/Spring с мыслью, что нехватку нативных библиотек всегда можно восполнить Java-наследием, и опасением конкурировать за инженеров с мобильной разработкой.

На третье - Python/Django, но уже с мыслью о конкуренции с рынком ML/data analysis.

Не готов рассматривать Java (рынок рабочей силы в основном состоит из инженеров кровавого энтерпрайза, которые плохо приспосабливаются к режиму стартапа), Go (людей мало и они дорогие, язык не заточен под REST-парадигму и большие монолиты), Typescript (там наведённый ад от экосистемы фронтенда), Ruby (мало людей, мало новых проектов, много легаси), .NET (сильная привязка к экосистеме Windows).

Какие ещё идеи, или поспорьте со мной, может быть?
Slim скорее всего потом вырастет обратно в симфони

Я думал сейчас для новых проектов берут лару
источник