Akka, как и Play — реально хорошие вещи.
Но у меня стояла другая задача. Я хотел проверить гипотезу о том, что на go решение этой задачи потребует меньше усилий, чем на java.
Зачем мне это надо? Потому что мне, как владельцу IT компании, важно не пропустить технологическую волну. Не оставить свою команду работать с устаревшими, неэффективными технологиями и не уступить рынок другим, более шустрым игрокам.
За последние 14 лет ни один из новых языков не дал существенного прироста в производительности. Go оказался первым.
Отсутствие альтернатив во все времена приводило к монополии. Наличие конкурентов/альтернатив вынуждает авторов библиотек совершенствовать свои продукты.
Вы привели еще один плюс наличия альтернатив. Только он не имеет отношения к продуктивности разработчика здесь и сейчас.
А если взять профессионала, то тот выберет java, так как на ней лучше писать долгоживущие проекты?
А если взять профессионала, тот изучит проект и будет выбирать инструмент исходя из требований.
Что касается объектов, то нет. Мы как раз оптимизировали здесь всё, что только можно было. В куче почти ничего не создаётся. Пулы есть.
Возможные причины такой разницы:
1) GC в go пока хуже, чем в java. До версии 1.5 был вообще ужасен. Но всё еще заметно хуже.
2) Разная нагрузка на сервер. Наш получает от каждого из 2500 клиентов примерно 50 сообщений в секунду. Обратно отсылает примерно 750. Плюс имеет очень много межпоточных коммуникаций.
3) Разные требования к серверу, обусловленные устройством самой игры. Если у нас влючить gc, появлется едва заметное дрожание кораблика раз в несколько секунд. Оно трудноуловимо, но создает ощущение, что с игрой что-то не так.
Т.е. в конторах пишущих игры ААА класса сидят дурачки, которые не знают, о том что программист на Go производительнее программиста на Java?!
Нет. Там сидят большие сложившиеся команды, которые много лет пишут на java и имеяют массу наработок, которые переиспользуются в новых проектах. Для них стоимость перехода на другой язык огромна.
в разразе Вашей задачи Вы пишущий на Go произовдительнее себя же пишущего на Java
Если говорить совем строго, то да. Именно так. Но я рискну расширить это утверждение до следующего «в разразе моей задачи человек с 18летним опытом программирования на java и нулевым опытом на Go, пишущий на Go произовдительнее себя же пишущего на Java»
Если уж Вы пытаетесь продвинуть мысль того, что go производительнее java в разрезе вашей задачи
Вы неправильно поняли. В разрезе моей задачи производительнее не go, а программист, пишущий на go.
Он справится с такой задачей быстрее, даже если ранее имел опыт программирования на java и не имел на go.
Ну странно наличие вариантов рассматривать как минус.
Наличие вариантов имеет свои минусы (порог вхождения) и плюсы (можно подобрать наиболее оптимальный).
Если говорить о продуктивности разработки, то наличие ровно одного хорошего способа сделать что-то будет плюсом, так как сэкономит время.
Верю с трудом, особенно в долгосрочной перспективе, и тем более если есть опыт подобных проектов на Java
Здесь сложно что-то возразить. У меня оно было так. Но каков в этом результате вес самого языка, моего проекта и моих личных предпочтений мне сказать трудно. Если есть опыт разработки таких проектов на java и если вас не раздражают VisualVM или YourKit, то, возможно, у вас будет другой результат.
Единственное, на чем я настаиваю — если взять двух новичков и один станет изучать java + экосистему, а второй go, то проект, подобный моему, быстрее получится у второго при прочих равных.
> Проблема с запуском профилировщика удаленно в Java совершенно надумана.
Тут вы правы. Я неверно расставил акценты. На самом деле надо было сказать о простоте и удобстве работы со штатным профилировщиком go. По мощности он превосходит VisualVM и сравним с YourKit. По удобсвту работы — лучшее, что я видел вообще. Экономит много времени.
> написать относительно несложную программу для нагрузочного тестирования
Я её и имел ввиду. Только она не могла быть совсем уж несложной. Нужно было эмулировать все кейсы, чтобы убедиться, что дикие утечки памяти не возникнут, скажем, при телепортации или еще в каком неожиданном месте.
> в Го вы все равно можете упереться в сборщик мусора
Да. Его пришлось отключить вовсе. Точнее перевести в ручной режим. Сначала код был переписан так, чтобы минимизировать использование кучи. Потом автоматический gc был отключен и заменен на код, который запускает его вручную, если свободной памяти на сервере осталось немного. Перед таким ручным запуском все клиенты принудительно ставятся на паузу. Происходит это редко и для игрока такое поведение много луше частых небольших лагов.
> Выбросили существующий код и проверенную временем JVM ради «модного» языка из-за каких-то странных доводов.
Ради опыта. Я знал сколько времени занимает решение подобной задачи на java. Я подозревал, что на go потребуется меньше. Я убедился, что да, меньше. Раза в два. И теперь я буду решать такие задачи на go и экономить свое время.
Этим вот опытом и поделился.
glide её использует
Просто он позволяет не хранить сторонние пакеты в своей системе контроля версий.
Каждый член команды может при помощи glide поместить в свою директорию vendor нужные версии сторонних пакетов.
Если от него перестали приходить пакеты, его коннект убивается сервером (примерно, через секунду)
Думаю, наши игры очень разные. Моя больше всего похожа на agar.io/slither.io.
Там всё очень быстро происходит. 15 секунд — неприемлемо огромный интервал
Если там просто пустые соединения, то разницы бы не было.
Если сервер имеет сложную логику и «тянет» мало клиентов, то вывести его на нужный уровень производительности в go займет существенно меньше времени, чем выполнение той же задачи в java.
(Хотя, разумется, это возможно и в java и вообще на любом языке)
Ваша мысль выглядит примерно так «Нельзя удалять гланды автогеном? Конечно, можно! Просто надо делать это через задний проход!»
Я нигде не сказал, что в яве нет профайлера.
Я сравнивал производительность инструментов (java + какой-то профайлер) vs (go + встроенный профайлер)
Go в несколько раз выиграл в моём случае. Работать было быстро, удобно и приятно.
Как раз про это я и написал.
Чтобы сделать это на java мне надо было:
1) Удосужиться поискать информацию (VisualVM? YourKit? Java Mission Control, который был добавлен, начиная с java 7 и, как тут заметили, платный).
2) Попробовать каждый из них.
Вы видели, например, VisualVM? По сравнению с инструментами, предлагаемыми go, это — прошлый век.
3) Далее, я бы обнаружил, что проблемы есть не только в моём коде, но и в серверной библиотеке.
Что взять? Jetty, Netty, а может VertX или Play?
Опять масса проб и ошибок.
Мысль не в том, что на java нельзя сделать сервер быстрее.
Мысль в том, что на go для этого потребуется намного меньше времени.
Но у меня стояла другая задача. Я хотел проверить гипотезу о том, что на go решение этой задачи потребует меньше усилий, чем на java.
Зачем мне это надо? Потому что мне, как владельцу IT компании, важно не пропустить технологическую волну. Не оставить свою команду работать с устаревшими, неэффективными технологиями и не уступить рынок другим, более шустрым игрокам.
За последние 14 лет ни один из новых языков не дал существенного прироста в производительности. Go оказался первым.
Вы привели еще один плюс наличия альтернатив. Только он не имеет отношения к продуктивности разработчика здесь и сейчас.
А если взять профессионала, тот изучит проект и будет выбирать инструмент исходя из требований.
В go они существенно меньше для этой задачи.
Возможные причины такой разницы:
1) GC в go пока хуже, чем в java. До версии 1.5 был вообще ужасен. Но всё еще заметно хуже.
2) Разная нагрузка на сервер. Наш получает от каждого из 2500 клиентов примерно 50 сообщений в секунду. Обратно отсылает примерно 750. Плюс имеет очень много межпоточных коммуникаций.
3) Разные требования к серверу, обусловленные устройством самой игры. Если у нас влючить gc, появлется едва заметное дрожание кораблика раз в несколько секунд. Оно трудноуловимо, но создает ощущение, что с игрой что-то не так.
Шутка не в том, что java будто бы медленнее. Шутка в том, что решение моей задачи занимает у программиста go намного меньше времени.
Нет. Там сидят большие сложившиеся команды, которые много лет пишут на java и имеяют массу наработок, которые переиспользуются в новых проектах. Для них стоимость перехода на другой язык огромна.
Если говорить совем строго, то да. Именно так. Но я рискну расширить это утверждение до следующего «в разразе моей задачи человек с 18летним опытом программирования на java и нулевым опытом на Go, пишущий на Go произовдительнее себя же пишущего на Java»
Вы неправильно поняли. В разрезе моей задачи производительнее не go, а программист, пишущий на go.
Он справится с такой задачей быстрее, даже если ранее имел опыт программирования на java и не имел на go.
Наличие вариантов имеет свои минусы (порог вхождения) и плюсы (можно подобрать наиболее оптимальный).
Если говорить о продуктивности разработки, то наличие ровно одного хорошего способа сделать что-то будет плюсом, так как сэкономит время.
Здесь сложно что-то возразить. У меня оно было так. Но каков в этом результате вес самого языка, моего проекта и моих личных предпочтений мне сказать трудно. Если есть опыт разработки таких проектов на java и если вас не раздражают VisualVM или YourKit, то, возможно, у вас будет другой результат.
Единственное, на чем я настаиваю — если взять двух новичков и один станет изучать java + экосистему, а второй go, то проект, подобный моему, быстрее получится у второго при прочих равных.
Или VertX или Play или много чего еще.
> Проблема с запуском профилировщика удаленно в Java совершенно надумана.
Тут вы правы. Я неверно расставил акценты. На самом деле надо было сказать о простоте и удобстве работы со штатным профилировщиком go. По мощности он превосходит VisualVM и сравним с YourKit. По удобсвту работы — лучшее, что я видел вообще. Экономит много времени.
> написать относительно несложную программу для нагрузочного тестирования
Я её и имел ввиду. Только она не могла быть совсем уж несложной. Нужно было эмулировать все кейсы, чтобы убедиться, что дикие утечки памяти не возникнут, скажем, при телепортации или еще в каком неожиданном месте.
> в Го вы все равно можете упереться в сборщик мусора
Да. Его пришлось отключить вовсе. Точнее перевести в ручной режим. Сначала код был переписан так, чтобы минимизировать использование кучи. Потом автоматический gc был отключен и заменен на код, который запускает его вручную, если свободной памяти на сервере осталось немного. Перед таким ручным запуском все клиенты принудительно ставятся на паузу. Происходит это редко и для игрока такое поведение много луше частых небольших лагов.
> Выбросили существующий код и проверенную временем JVM ради «модного» языка из-за каких-то странных доводов.
Ради опыта. Я знал сколько времени занимает решение подобной задачи на java. Я подозревал, что на go потребуется меньше. Я убедился, что да, меньше. Раза в два. И теперь я буду решать такие задачи на go и экономить свое время.
Этим вот опытом и поделился.
Просто он позволяет не хранить сторонние пакеты в своей системе контроля версий.
Каждый член команды может при помощи glide поместить в свою директорию vendor нужные версии сторонних пакетов.
Думаю, наши игры очень разные. Моя больше всего похожа на agar.io/slither.io.
Там всё очень быстро происходит. 15 секунд — неприемлемо огромный интервал
Если сервер имеет сложную логику и «тянет» мало клиентов, то вывести его на нужный уровень производительности в go займет существенно меньше времени, чем выполнение той же задачи в java.
(Хотя, разумется, это возможно и в java и вообще на любом языке)
Что касается инструментов, то лучшие инструменты остаются лучшими, несмотря на то, что я или вы умеете работать и с плохими.
Я нигде не сказал, что в яве нет профайлера.
Я сравнивал производительность инструментов (java + какой-то профайлер) vs (go + встроенный профайлер)
Go в несколько раз выиграл в моём случае. Работать было быстро, удобно и приятно.
Чтобы сделать это на java мне надо было:
1) Удосужиться поискать информацию (VisualVM? YourKit? Java Mission Control, который был добавлен, начиная с java 7 и, как тут заметили, платный).
2) Попробовать каждый из них.
Вы видели, например, VisualVM? По сравнению с инструментами, предлагаемыми go, это — прошлый век.
3) Далее, я бы обнаружил, что проблемы есть не только в моём коде, но и в серверной библиотеке.
Что взять? Jetty, Netty, а может VertX или Play?
Опять масса проб и ошибок.
Мысль не в том, что на java нельзя сделать сервер быстрее.
Мысль в том, что на go для этого потребуется намного меньше времени.