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


S>>Ну уж простую задачу можно на чом угодно нарисовать. Да хоть на баш, хоть на плюсах, хоть на перле. Всяко лучше чем нода. И возни меньше. А так как исчезает один компонент из системы — то и надёжнее.
scf>Не нужно недооценивать ноду. Популярный простой язык, есть библиотеки буквально для всего, можно писать исполняемые .js файлы, запускается и работает быстро. Одно время использовал её вместо питона для скриптов, очень хорошие впечатления.
Недооценивать может и не стоит, но точно так-же не стоит на нёй писать если есть выбор.

vsb>С точки зрения общепринятого использования Java это Spring Boot.

Общепринятое использование, миллионы мух, да, да... Как же мой софт живет-то без спрингбута, ойвэй!

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

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

Так и вижу, как автоматизацию(веб приложение) какой услуги ктото будет писать на баше

Во первых, тебе сначала надо будет собрать команду. И на этом этапе баш/плюсы/пёрл отваливаются по разным причинам
1. перл уже давно экзотика, людей на нём считай что нет.
2. на плюсах веб-приложения пишет еще меньшее количество людей.
3. баш и веб приложения — очень смешно, людей около нуля

Реальные альтернативы:
— руби
— питон
— C# — дико дорого
— Java — дико дорого
— Go — дико дорого

При этом нода позволяет одной командой поддерживать и несложный бакенд, и несложный фронт.

В целом, возни будет меньше всего именно на ноде, т.к. эта платформа развивается именно в этом направлении.

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

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

Далеко не во всех популярных базовых образах bash есть. В alpine, к примеру, sh. А в некоторых шелла вообще нет. Так что это тоже дополнительный компонент.

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

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

"... на чом угодно" — включает в себя перечисленное тобой тоже.

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

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

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

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

S>"... на чом угодно" — включает в себя перечисленное тобой тоже.

Кейс "на чом угодно" нужно исключить уже ради того, что бы у тебя был предсказуемый набор людей, иначе в команду придется добавить рекрутёра. То есть, стек технологий выбирается задолго до старта разработки и там точно не будет ни баша, ни С++, ни Перл. Скорее всего, и Руби. А вот у Питона как то так выходит, жээс выигрывает с большим отрывом, а C#/Java слишком дороги по дефолту.

Т.е. сейчас мейнстрим в таких проектах именно нода, в силу экономически причин.

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

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

I>То есть, чисто экономические основания. В таком случае команда фулстеков комплектуется как обойма, ну или как пожарная команда — все умеют всё. Это дает существенную гибкость и при этом обходится намного дешевле смешаной команды команды с джава-дотнет(нужное вписать) бакендом.

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

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

НС>>Далеко не во всех популярных базовых образах bash есть. В alpine, к примеру, sh. А в некоторых шелла вообще нет. Так что это тоже дополнительный компонент.
S>Тебе тоже непонятно значение фразы "...на чом угодно... Да хоть на..."?

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

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

I>>>Так и вижу, как автоматизацию(веб приложение) какой услуги ктото будет писать на баше
S>>"... на чом угодно" — включает в себя перечисленное тобой тоже.
I>Кейс "на чом угодно" нужно исключить уже ради того, что бы у тебя был предсказуемый набор людей, иначе в команду придется добавить рекрутёра.
И тут мимо. Этот кейс как раз помогает найти людей, способных написать качественный код.

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

I>>То есть, чисто экономические основания. В таком случае команда фулстеков комплектуется как обойма, ну или как пожарная команда — все умеют всё. Это дает существенную гибкость и при этом обходится намного дешевле смешаной команды команды с джава-дотнет(нужное вписать) бакендом.

Ф>Миллиард правок уже за 3 года существования кода на js легко превратят его в минное поле — абсолютно негодное для сопровождения. На том же шарпе лично я ковырялся в проектах, которым больше 10 лет.

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

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

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

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

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

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

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

Успокойся. Старт проекта на баше-перле-плюсах с большой вероятностью даст тот же говнокод. Дополнительно к этому будет еще и этап переписывания на другой стек.

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

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

НС>>Далеко не во всех популярных базовых образах bash есть. В alpine, к примеру, sh. А в некоторых шелла вообще нет. Так что это тоже дополнительный компонент.
S>Тебе тоже непонятно значение фразы "...на чом угодно... Да хоть на..."?

А если ничаво нет?

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

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

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

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

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

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

Я про интеграционный код, который должен быть в каждом микросервисе

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

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

Кто должен думать про деньги?

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

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

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

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

НС>Кто должен думать про деньги?

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

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

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

Пока ты будешь искать людей конкуренты выпустят продукт.