Питон - это легаси от которого мы постепенно отказываемся.
"Для разработки новых сервисов используем следующую идеологию. Если знаем, что сервис получится большим, с большим количеством логики (более 1-1,5 тысяч строчек кода), то мы используем C#. Если знаем, что сервис будет маленький (на несколько сотен строчек кода), используем Golang."
Обычно придерживаемся вышеописанной политики.
Про языки холиварить не очень хочу, у каждого языка есть свои плюсы и минусы :)
Так же стоит учесть, что при наличии большой кодовой базы, переход на новые версии дотнета не безболезненный, мы не очень просто переползали на .net 5, словили пачку неочевидных и неприятных багов(
На GO тяжело писать большие сервисы, хочется навернуть бодренького ООП, с которым в GO вообще не очень.
Если проект изначально пишется в архитектуре только микросервисов с хорошим горизонтальным масштабированием - GO ок. Насколько я знаю, бекенд некоторых мобильных игр my.games написан на GO.
Однако же, если у вас есть много нетривиальной бизнес-логики, то, лучше взять что-то ООП-шное - будет намного проще чем увлекательно разгребать лапшу микросервисов.
В целом - да, а так же некоторый дополнительный функционал вроде обмена трафиком между клиентами минуя основные сервера(почти p2p, но не совсем) или логики балансировки.
Небольшое уточнение, в статье под Jabber подразумевается ejabberd)
Если бы мы сейчас начали писать проект, то, возможно, выбрали бы другую технологию.
Но на данный момент ejabberd нас устраивает. Отлично держит нагрузки, легко масштабируется, проблемы с безопасностью починили( конечно, будут ещё рано или поздно :) ). Мотивации менять технологию на "более модную" и тратить на это огромное количество ресурсов не вижу.
Цены бы ему не было, если бы не редкие трудноуловимые баги, ради которых приходится бегло изучать Erlang(
На одном из прошлых проектов пробовали писать бекенд "на плюсах".
Нагрузки держит огромные, но скорость разработки и количество возникаемых багов оставляют желать лучшего.
Поэтому используется более удобные языки, которые позволяют быстрее разрабатывать и "более терпимы" к ошибкам программистов(сервер не падает с сегфолотом на каждый чих :) ).
Проблема размера сетевого трафика для метагейм бекенда не стоит остро, каждый пользователь шлёт не так уж и много информации. Трафик, естественно, шифрируется и пережимается.
+ Допустима не очень быстрая скорость ответа. Например, если у вас секунда прошла с момента выстрела в игре до момента его отображения на экране - это долго и заметно.
А если секунда прошла с момента покупки предмета в магазине до того момента как он отобразиться в игре - это вполне приемлимо)
Для взаимодействия с "дедиками" скорость ответа уже критична важна, но у нас так же не возникало проблем с размером трафика.
Питон - это легаси от которого мы постепенно отказываемся.
"Для разработки новых сервисов используем следующую идеологию. Если знаем, что сервис получится большим, с большим количеством логики (более 1-1,5 тысяч строчек кода), то мы используем C#. Если знаем, что сервис будет маленький (на несколько сотен строчек кода), используем Golang."
Обычно придерживаемся вышеописанной политики.
Про языки холиварить не очень хочу, у каждого языка есть свои плюсы и минусы :)
Так же стоит учесть, что при наличии большой кодовой базы, переход на новые версии дотнета не безболезненный, мы не очень просто переползали на .net 5, словили пачку неочевидных и неприятных багов(
Шарпы, Java, например.
https://dotnet.github.io/orleans/ - например, один из самых модных фреймворков в геймдеве, мы так же его используем на новых проектах.
*моё субъективно мнение*
На GO тяжело писать большие сервисы, хочется навернуть бодренького ООП, с которым в GO вообще не очень.
Если проект изначально пишется в архитектуре только микросервисов с хорошим горизонтальным масштабированием - GO ок.
Насколько я знаю, бекенд некоторых мобильных игр my.games написан на GO.
Однако же, если у вас есть много нетривиальной бизнес-логики, то, лучше взять что-то ООП-шное - будет намного проще чем увлекательно разгребать лапшу микросервисов.
В целом - да, а так же некоторый дополнительный функционал вроде обмена трафиком между клиентами минуя основные сервера(почти p2p, но не совсем) или логики балансировки.
Небольшое уточнение, в статье под Jabber подразумевается ejabberd)
Если бы мы сейчас начали писать проект, то, возможно, выбрали бы другую технологию.
Но на данный момент ejabberd нас устраивает. Отлично держит нагрузки, легко масштабируется, проблемы с безопасностью починили( конечно, будут ещё рано или поздно :) ). Мотивации менять технологию на "более модную" и тратить на это огромное количество ресурсов не вижу.
Цены бы ему не было, если бы не редкие трудноуловимые баги, ради которых приходится бегло изучать Erlang(
На одном из прошлых проектов пробовали писать бекенд "на плюсах".
Нагрузки держит огромные, но скорость разработки и количество возникаемых багов оставляют желать лучшего.
Поэтому используется более удобные языки, которые позволяют быстрее разрабатывать и "более терпимы" к ошибкам программистов(сервер не падает с сегфолотом на каждый чих :) ).
Разницу в перфе легко компенсировать железом
Привет, я автор статьи)
Проблема размера сетевого трафика для метагейм бекенда не стоит остро, каждый пользователь шлёт не так уж и много информации.
Трафик, естественно, шифрируется и пережимается.
+ Допустима не очень быстрая скорость ответа.
Например, если у вас секунда прошла с момента выстрела в игре до момента его отображения на экране - это долго и заметно.
А если секунда прошла с момента покупки предмета в магазине до того момента как он отобразиться в игре - это вполне приемлимо)
Для взаимодействия с "дедиками" скорость ответа уже критична важна, но у нас так же не возникало проблем с размером трафика.