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

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

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

НС>Включил дурачка?
Это неотключаемая фича. Так что не включал

T>Go, java, c# ?

Тот, на котором микросервисы будут общаться. Как пример — это это HTTP + JSON, то основной язык (source of truth) будет язык схемы для этого JSON, если это Microsoft COM — тогда Microsoft IDL, и так далее.

А уж на чем реализовывать, значения не имеет. Хоть на node.js.

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

·>С т.з. гибкости, кол-ва доступных библиотек, фреймворков, развитости инфраструктуры, етс, то конечно java.

Да, java. Но на golang легковеснее и меньше букв. Хотя я на жаве писал микросервисы, а на golang- нет.

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

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

I>>C#, Java, Go требуют гораздо бОльшего времени на освоение платформы. Соответсвенно, для простых задач это будет работать против тебя.
S>JS тоже требует время. И тоже немалого.
S> Специалисты получают примерно одинаково на любом языке. А вот джуниоры наговнят на любом языке.
S> Я бы выбрал C# c Native AOT http://rsdn.org/forum/flame.comp/8286600.1

Автор: Serginio1
Дата: 29.05.22

S>Легковесный, но со сборщиком мусора

17МБ приветмир, легковесно, однако!

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

S>>>>Люди примут решения, стек, язык из того что предложишь ты, как профессионал. Так как тебя наняли для этого.
I>>>Ну да, спросили шеридана — он предложил баш/с++/перл. Как думаею, сколько времени ты будешь искать замену, когда уволится кто нибудь из этой команды?
S>>Сразу же мимо.
S>>Нет. Я профессионал. Я никогда не выбираю из личных предпочтений для проектов работодателя. Это своё я могу на чом угодно, а там я выберу наиболее подходящий для задачи стек, причом так, чтобы хотя бы несколько человек в нём понимало и умело.
I>Вот ты и объяснил разницу — своё можешь на чем хошь писать. А как только добавляем сюда бизнес, то появляются ограничения. И ты даже пример привел этого ограничения "что бы несколько человек понимало и умело"
I>На самом деле все сложнее — продукт придется мейнтейнить, развивать, скажем, лет пять, десять или даже больше. И тут всякие кейсы "стартовали на баше/С++/перле" дают геморрой до тех пор, пока не перепишешь на что вменяемое.
Только вы тут топите за то что программисты — рабы и решения цэе (сто? как их там?) должен принимать единолично.

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

S>Только вы тут топите за то что программисты — рабы

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

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

S>>Только вы тут топите за то что программисты — рабы
НС>Это только в твоей голове есть такие бредни. Программисты точно так же вольны выбирать компании, использующие желаемый технологический стек. А рабами предлагаешь их сделать ты, намертво связав программистов и конкретный проект.
Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас. Дайте мне компутер и XXX денег каждый месяц" а его раз и взяли.

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

S>Только вы тут топите за то что программисты — рабы и решения цэе (сто? как их там?) должен принимать единолично.

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

Скажем, для небольшой конторы плодить стеки нет смысла, а может даже контрпродуктивно. Выбрали один стек и стартуют все на нем пока СТО не даст добро на что другое.
А тебя послушать так надо программистов да одминов спрашивать.

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

S>Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас. Дайте мне компутер и XXX денег каждый месяц" а его раз и взяли.

Именно так и происходит. Только еще собеседование добавляется, что бы проверить на сколько кандидат владеет конкретным стеком и какие у него коммуникационные способности

Очень важно предоставить возможность менять проекты, это позволяет удерживать работников, пока они накапливают опыт в определенной области.
Если же наплодить кучку подразделений дотнет, джава, итд, то получается так — хочет товарищ поменять проект, опаньки, а там другой стек. Как правило, это является существенным препятствием и далеко не все программисты/менеджеры решаются на такой шаг.

Зависит от уровня и должности вопрошающего.

— для молодого разработчика, который хочет быть в тренде — выбрать самый модный, почитав хабар
— для мидла/мидла+ — что хорошо знает, либо какой новый язык хочет попробовать в деле, либо то, что больше котируется на рынке труда
— для крепкого сеньора/архитектора: тот, который лучше впишется в текущую систему и систему разработки в компании в целом
— для главы разработки/начальник отдела/CTO — тот, на котором больше всего есть разработчиков в наличии в штате, а также которых проще и дешевле нанять с рынка, а плюс, на экосистему которого уже тратятся деньги (IDE, оплата фреймворков, обучениях/курсы/тематические конференции для разработчиков и прочее)
— для пет-проджекта: попробовать несколько языков и сравнить

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

S>Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас.

Примерно так, да. И именно поэтому в вакансиях пишут про тот самый стек.

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

S>>Только вы тут топите за то что программисты — рабы и решения цэе (сто? как их там?) должен принимать единолично.
Как же не единолично, раз остальных спрашивать не надо?

I>Совсем необязательно единолично. Может делегировать. Но штука в том что программист в выборе стека ровно ничего что добавит к той информации, что и так есть у CTO или солюшн архитектора.
Я встречал таких, которые в теме, но не все такие.

I>Скажем, для небольшой конторы плодить стеки нет смысла, а может даже контрпродуктивно. Выбрали один стек и стартуют все на нем пока СТО не даст добро на что другое.
А потом ноду пропихивают в бакенд.

I>А тебя послушать так надо программистов да одминов спрашивать.
Именно так. И только после этого делать выбор.

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

S>>Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас. Дайте мне компутер и XXX денег каждый месяц" а его раз и взяли.
I>Именно так и происходит. Только еще собеседование добавляется, что бы проверить на сколько кандидат владеет конкретным стеком и какие у него коммуникационные способности
Угу. И бюджет бездонный и работы овер100500.

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

I>Если же наплодить кучку подразделений дотнет, джава, итд, то получается так — хочет товарищ поменять проект, опаньки, а там другой стек. Как правило, это является существенным препятствием и далеко не все программисты/менеджеры решаются на такой шаг.
И что если другой стек? Какие-то сложности?

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

S>>Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас.
НС>Примерно так, да. И именно поэтому в вакансиях пишут про тот самый стек.
Ах, по вакансии. Яснопонятно.

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

I>>Именно так и происходит. Только еще собеседование добавляется, что бы проверить на сколько кандидат владеет конкретным стеком и какие у него коммуникационные способности
S>Угу. И бюджет бездонный и работы овер100500.

Бюджеты всегда ограничены. Потому и нет кейса "пиши на чом хошь".

I>>Очень важно предоставить возможность менять проекты, это позволяет удерживать работников, пока они накапливают опыт в определенной области.
S>Очень важно накапливать опыт в разных областях, чтобы плесенью не покрыться.

Смена технологического стека мало что меняет, на самом деле. Гораздо бОльшее влияние даст смена предпметной области или даже поля деятельности.

Скажем, если ты решил идти в архитекторы, то далеко не факт, что попрыгав по стекам ты достигнешь эту цель быстрее.

I>>Если же наплодить кучку подразделений дотнет, джава, итд, то получается так — хочет товарищ поменять проект, опаньки, а там другой стек. Как правило, это является существенным препятствием и далеко не все программисты/менеджеры решаются на такой шаг.
S>И что если другой стек? Какие-то сложности?

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

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

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

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

I>>А тебя послушать так надо программистов да одминов спрашивать.
S>Именно так. И только после этого делать выбор.
Это не работает чуть менее чем везде.

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

I>>Совсем необязательно единолично. Может делегировать. Но штука в том что программист в выборе стека ровно ничего что добавит к той информации, что и так есть у CTO или солюшн архитектора.
S>Я встречал таких, которые в теме, но не все такие.

Мало встречал значит.

I>>Скажем, для небольшой конторы плодить стеки нет смысла, а может даже контрпродуктивно. Выбрали один стек и стартуют все на нем пока СТО не даст добро на что другое.
S>А потом ноду пропихивают в бакенд.

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

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

I>>Как так вышло, что у тебя есть именно эта команда?

НС>У тебя есть именно та команда, которая есть. Куда интереснее почему ты решил, что ее нету, и почему ее нельзя нанять, если уж нету.

Сначала у меня никакой команды нет. А раз так, значит надо нанимать. С этим ты согласен?
Вопрос — кого нанимать что бы это было эффективно?

НС>Кривая вхождения — это для разработчика. А для компании нет никакой кривой, есть только стоимость специалиста в зависимости от платформы. Стоимость Java или C# разработчика существенно выше чем рубиста или питониста?

Кривая вхождения влияет на всю экономику проекта и конторы. Скажем, когда контора готовит своих людей, что сейчас норма, эта кривая вхождения влияет на объемы и срок инвестирования.
Не все ведь задачи одной сложности. бОльшая часть задач они достаточно простые. В силу кривой вхождения польза от мидла на ноде и мидла на дотнете/джаве сильно разная. Чудес не бывает. А раз так, то имеет смысл брать мидлов на ноде. Вот тебе и разница.

Более того, проекты на ноде позволяют очень гибко комплектовать команды, и использовать другие подходы к разработке. Например, full stack на джава-дотнете это профанация, если за ним не стоит 10-20 лет опыта. Или это будет фронт, который посредственно знать бакенд, или наоборот. А вот на ноде в силу изоморфизма всё решительно иначе.

I>>Скажем, у нас кучка студенческих проектов

НС>Т.е. альтернатива "дорогим" жабе и шарпу — студенты? Ок, так понятно.

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

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

НС>>У тебя есть именно та команда, которая есть. Куда интереснее почему ты решил, что ее нету, и почему ее нельзя нанять, если уж нету.
I>Сначала у меня никакой команды нет.

Стартап шоле?

I>А раз так, значит надо нанимать. С этим ты согласен?

Если нет — надо нанимать. Но обычно есть.

I>Вопрос — кого нанимать что бы это было эффективно?

Именно. Поэтому крайне странно уповать на сложность освоения стека с нуля. Нанимать на новый проект нулевых людей — безумству храбрых.

НС>>Кривая вхождения — это для разработчика. А для компании нет никакой кривой, есть только стоимость специалиста в зависимости от платформы. Стоимость Java или C# разработчика существенно выше чем рубиста или питониста?
I>Кривая вхождения влияет на всю экономику проекта и конторы. Скажем, когда контора готовит своих людей, что сейчас норма

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

I>Не все ведь задачи одной сложности. бОльшая часть задач они достаточно простые.

Опять же, слишком смелое утверждение. У меня на текущем проекте, к примеру, простых задач очень мало. Настолько, что всех джунов пришлось убрать, а новым разработчикам для вхождения в проект даже на пару-тройку месяцев наскрести задач вызывает затруднение. Так что не обобщай.

I>В силу кривой вхождения польза от мидла на ноде и мидла на дотнете/джаве сильно разная.

Это утверждение нуждается в доказательствах. Вот микросервисы — тут да, ради этого и придумывалось. А вот чтобы на ноде задачи одинаковой сложности решались проще — это очень спорно. Принцип использования мидлов в сложных проектах один — им создается относительно изолированная среда, где все сложные задачи тем или иным способом (способов много, от специальных фреймворков до решений типа istio) решены за кадром. И я пока не вижу ни одного преимущества ноды в разрезе способностей выносить сложную специфику за кадр. Просветишь?

I>Более того, проекты на ноде позволяют очень гибко комплектовать команды, и использовать другие подходы к разработке.

Например?

I> Например, full stack на джава-дотнете это профанация, если за ним не стоит 10-20 лет опыта. Или это будет фронт, который посредственно знать бакенд, или наоборот. А вот на ноде в силу изоморфизма всё решительно иначе.

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

I>>>Скажем, у нас кучка студенческих проектов
НС>>Т.е. альтернатива "дорогим" жабе и шарпу — студенты? Ок, так понятно.
I>Это иллюстрация, как кривая вхождения влияет на разработку проекта.

Фиговая иллюстрация.

I> Так выходит,что дотнетчиков и джавистов учить достаточно долго.

Еще раз. Неважно сколько их учить, важна разница в зарплате уже наученных. Я большой разницы между спецами одного уровня, использующими джаву, дотнет или ноду не вижу. И нет, ничего хорошего от попыток использования ноды без бэкендеров, специализирующихся на ноде не выйдет. Видел epic fails на эту тему много раз (и это, кстати, касается не только ноды, попытки создания бэка на дотнете или джаве без специфического опыта команды заканчиваются тем же самым). Под чертой — стоимость спеца определяется на 90% его опытом в конкретной предметной области и слабо зависит от используемого им стека (а для principal developer и выше вообще практически не зависит).

I>Не так долго, как С++ разработчиков, но всё равно долго. А раз так, то применять таких специалистов для простых задач мягко говоря нерационально.

Нанимать отдельных студентов под простые задачи тоже, мягко говоря, не всегда рационально.

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

S>>>Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас.
НС>>Примерно так, да. И именно поэтому в вакансиях пишут про тот самый стек.
S>Ах, по вакансии. Яснопонятно.

Что то ты все позорнее и позорнее сливаешься.