Если ты имеешь ввиду, что бэкенд и фронт пишутся обычно на разных языках в веб сервисах, то я это классифицирую как 2 проекта, а не один. И считаю, что это оправдано абсолютно.
Я рассуждаю именно про использование многоязычия в одной области.
Ясно, что нет решения из серии one size fits all. Но все же должны быть какие-то практики, которые позволяют ответить на вопрос: на сколько оправдано добавление той или иной технологии в проект?
За много лет пока придерживаюсь стратегии минимизации набора технологий в рамках проекта. Потому всегда интересно как эти решения принимаются у других.
Переход с 3 на 5 был реально тяжелый. Но это потому, что они там совсем все перепилили. А вот с 5 на 6 - вообще незаметен.
Моя практика показывает, что "многоязычие" в проекте скорее минус чем плюс. Потому что код мало просто написать. Его еще надо развивать и поддерживать. И основная работа строиться именно на этом поле.
Уверен что есть ситуации, когда многоязычие работает, как описано в "умных книжках", но я пока не видел такого на практике нигде, кроме как в огромных проектах. Даже не проектах, а экосистемах типа амазона или гугла.
Просто для статистики. Вы пишите бэкенд в основном на c#, но местами используете python и go. Почему все не пилить на c#? Есть ли какой-то профит от мультитехнологичности? Или это, как часто бывает, "проснулся с утра и решил, а холибыиненапитоне"?
DotNet особенно в последнее время прям очень даже хорош... начиная с версии 6, так ваще прям огонь. Микросервисы пишутся на раз два. Никакой Go рядом не стоял. И это я не говорю про то, что по-сравнению с Go или Python сам язык в разы приятнее.
На мой взгляд весьма тяжелая технология для такой простой части архитектуры :) Конечно же ни к чему не призываю, просто делюсь мнением.
В данном решении больше всего смущает именно необходимость поддержки этого дела на Erlang. На мой вкус оно того не стоит. Можно реализовать брокер сообщений хоть на C#, хоть на Go. В зависимости от того во что команда больше умеет. Для столь узкого круга задач - самое то.
Как показывает практика - в геймдеве кастомные решения во многом работают лучше чем "все что вы принесли из прошлого опыта из-за пределов геймдева".
Я правильно понимаю, что этот сервис нужен чтоб решать задачу доставки сообщений от клиента к серверу и пушей от сервера в клиент? Не в рамках боевки, а в рамках метаигры, конечно.
Если ты имеешь ввиду, что бэкенд и фронт пишутся обычно на разных языках в веб сервисах, то я это классифицирую как 2 проекта, а не один. И считаю, что это оправдано абсолютно.
Я рассуждаю именно про использование многоязычия в одной области.
Ясно, что нет решения из серии one size fits all. Но все же должны быть какие-то практики, которые позволяют ответить на вопрос: на сколько оправдано добавление той или иной технологии в проект?
За много лет пока придерживаюсь стратегии минимизации набора технологий в рамках проекта. Потому всегда интересно как эти решения принимаются у других.
Не холивара ради, а просто собираю мнения.
Переход с 3 на 5 был реально тяжелый. Но это потому, что они там совсем все перепилили. А вот с 5 на 6 - вообще незаметен.
Моя практика показывает, что "многоязычие" в проекте скорее минус чем плюс. Потому что код мало просто написать. Его еще надо развивать и поддерживать. И основная работа строиться именно на этом поле.
Уверен что есть ситуации, когда многоязычие работает, как описано в "умных книжках", но я пока не видел такого на практике нигде, кроме как в огромных проектах. Даже не проектах, а экосистемах типа амазона или гугла.
Просто для статистики. Вы пишите бэкенд в основном на c#, но местами используете python и go. Почему все не пилить на c#? Есть ли какой-то профит от мультитехнологичности? Или это, как часто бывает, "проснулся с утра и решил, а холибыиненапитоне"?
DotNet особенно в последнее время прям очень даже хорош... начиная с версии 6, так ваще прям огонь. Микросервисы пишутся на раз два. Никакой Go рядом не стоял. И это я не говорю про то, что по-сравнению с Go или Python сам язык в разы приятнее.
На мой взгляд весьма тяжелая технология для такой простой части архитектуры :) Конечно же ни к чему не призываю, просто делюсь мнением.
В данном решении больше всего смущает именно необходимость поддержки этого дела на Erlang. На мой вкус оно того не стоит. Можно реализовать брокер сообщений хоть на C#, хоть на Go. В зависимости от того во что команда больше умеет. Для столь узкого круга задач - самое то.
Как показывает практика - в геймдеве кастомные решения во многом работают лучше чем "все что вы принесли из прошлого опыта из-за пределов геймдева".
Я правильно понимаю, что этот сервис нужен чтоб решать задачу доставки сообщений от клиента к серверу и пушей от сервера в клиент? Не в рамках боевки, а в рамках метаигры, конечно.
Я все понимаю, но... Jabber??? Серьезно? Зачем?