Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Node.js vs Java for multiplayer games

Всем привет.
Есть желание сделать игру мультиплеер. В духе agariogame.club, slither.io и т.д.
К своему удивлению нашел очень много исходников мультиплеер сервера написано именно на Node.js.
Я изначально планировал написать сервер на Java, потому возник вопрос.

Какие «за и против» вы могли бы выделить при выборе языке для игровой разработки сервера (мультиплеер)? Node.js либо Java?
Так же хотел бы заметить, игру я планирую портировать на браузер и на мобильный.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Кто-то хотел бы заглубиться в однородные координаты? В Киеве такая тусовка намечается 9 ноября «Гомогенні координати в програмуванні» Лектор описал цель так: «Код стає крихітним, алгоритми зрозумілими, програми літають, колишні костилі і велосипеди шиплять, плюються сіркою і тануть на сонці»
Или все же считаете, что тема в Украине еще не актуальна? Ждем пока эта волна будет ползти к ним из Кремниевой Долины)

Короче, решайте сами. А я вас приглашаю. Тема для Middle-Senior — www.facebook.com/...​2029514/?active_tab=about

перепрошую за некропостінг

«Гомогенні координати» вони ж «афінні координати/перетворення» освітлюються у книжках по комп графіці у найперших розділах, бо це така основа і азбука, що нема ради.
Тому «актуальність теми для України» рівнозначна тому, якби сказати «актуальність використання мила для миття рук в Україні».

Бери джаву и актор фреймворк Akka. Раскуривать достаточно много, за то супер производительность и можно держать высокую нагрузку. Да и вообще концепты которые выучишь в Akka очень полезны будут.

Уж лучше go с горутинами. Go идеально подходит для сервера многопользовательской игры по следующим причинам:
— простая и эффективная работы с сетью. Не нужно никаких мозгодробильных epoll’ов с лапшой из калбэков на конечных автоматах;
— один сервер может с легкостью держать десятки или даже сотни тысяч клиентов. При этом каждый клиент обрабатывается простым линейным кодом в отдельном наборе горутин, а не притянутыми за уши акторам с многослойными бесполезными абстракциями, затрудняющими понимание кода;
— Задержки gc в последних версиях go не превышают 0.1 мс, в то время, как в java они достигают нескольких сотен миллисекунд. С такими задержками в java можно писать лишь сервера для пошаговых стратегий.

Я бы брал vert.x для этого. Полностью асинхронный, легко маштабируется, можно писать с коллбеками, можно использовать rx нотацию. Я сделал на нем этом фреймворке пару проектов игровых — просто сказка. Три сервера (4GB RAM, 20GB hdd, intel icore5 CPU) с кластером hazelcast- держат 2K websocket подлючений в секунду (с обработкой бизнеслогики) И это при том, что саму java машину ниразу не тюнил.

Если это pet project и пишете в свое удовольствие — выбирайте то что больше нравится или хочется изучить.
Если идея быстро сделать и зарабатывать — пишите на том, что лучше знаете, сэкономите время на изучении.

Имхо js не очень годится для подобных вещей ввиду своей одно-поточности и низкокачественности 3rdparty библиотек. Много поточность там пилится конечно, но через дикие костыли. Надо брать или Java или Go, или аналоги. Хотите динамическую типизацию на Java? Возьмите Groovy.

ps: еще можно попробовать crystal-lang.org, если верить их сайту, то он быстрее всех )

pps: советую посмотреть как устроены вообще игровые сервера,

вот например исходники lineage 2
java: bitbucket.org/…​com/l2jserver/?at=develop

go: github.com/mikesaidani/l2go

а вот wow
github.com/mangoszero/server

JS конечно однопоточен, но о асинхронности мы не слышали, не ? Мда ....

Мда, кто то не понимает разницы между асинхронностью и многопоточностью. И почему первый не может даже пытаться конкурировать со вторым. Опять же, асинхронность возможна и в многопоточном приложении, с чем java прекрасно справляется. На js быстрей себе отстрелить ноги, чем что-то собрать что выдержит нагрузку)

Вспоминается в этом контексте пример пей пала :)
www.paypal-engineering.com/...​/11/22/node-js-at-paypal

Вполне себе конкурирует и даже бьет один из основных стандартов фреймворков для java разработки.

если судить по статье — что на node у людей меньше кода чем на java, меньше latency на 35% чем со спрингом и два раза выше throuput. © Ваш капитан

Де пруф що стаття об’єктивна?

ты что упоротый?

Вот тебе еще пруф, что node.js рулит — asp.net core был сделан по подобию ноды от начала до конца — middleware паттерн для компонентной архитектуры веб сервера, даже библиотеку для сетевого i\o взяли, туже что использует node.js короче node.js 1 в 1 был, кроме того что умел в многопоточность и статическую типизацию из коробки.
а обогнал asp.net core по скорости ноду — потому, что там 80% .net core сейчас это unmanaged код, работа с указателями — чистый С сервер под капотом.

у node.js есть на текущий момент куда больше преимуществ чем у .net core для продакшина.
Многопоточность java/c# играет роль в абсолютном меньшинстве случаев в тех задачах, в которых они конкурируют с нодой, последнее контексте ноды решается кластеризацией и скейлингом на уровне процессов — куда элегантней чем задрочки в java/c# с конкурентным кодом на уровне потоков в рамках одного процесса, эта конкуретная многопотчоность одна не из последних причин почему, нода с одним потоком легче выдает в бенчах показатели лучше чем у неискуственно накрученных серверов написанных на java/C#.

нода с одним потоком легче выдает в бенчах показатели лучше чем у неискуственно накрученных серверов написанных на java/C#.

Як то кажуть — знайди тут свою ноду: www.techempower.com/benchmarks

www.techempower.com/...​16&hw=ph&test=db&l=hra073

Запустите по instancy ноды ядро или %сколько там у jvm сервера воркеров на прием% будет такое же как и с netty.

На графіку нода в середині

Топ нода в 2 раза гірша від топ джави наприклад. І це тільки шттп стек. Якщо додати звичайну типову ковбасу коду, то нода просяде набагато сильніше (думаю 10х десь в реальних апках). Бо колбекі колбеків особливо незаоптимайзиш.
Ну і бібліотечний js ад ніхто не відміняв, а скільки там печалькі в типовій апці знає кожен.

Ну і бібліотечний js ад ніхто не відміняв, а скільки там печалькі в типовій апці знає кожен.

типа в java апках боли меньше.

Бо колбекі колбеків особливо незаоптимайзиш.

точно, не то что конкурентный код на многопоточной java — все как по маслу, top performers одни сплошные.

Я вообще не js разработчик и не пишу на node и никогда не писал — с вами мне не особо интересно общаться, слишком много отсылов в какие-то демагогии и попытках задеть меня.

Тоді чому виступаєте в ролі фан боя ноде джс? Тролите?

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

А ви мене одразу хворим назвали.

Больным не называл — уточнил в своем ли уме, если спрашиваете про предоставление пруфа на пруф.

на node написано достаточно сложных high load проектов ни один pay pal — понятно дело что сама технология не решающий фактор, но если вы обратили внимание и читали ветку, в которой я сделал риплай, кто-то решил что node вообще не для чего не годен.

переписують гівно мамонта

это вы так про Spring?

типа в java апках боли меньше.

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

не то что конкурентный код на многопоточной java

Ну, власне, в JIT купа оптимізацій для багатопоточного коду, типу BiasedLocking, EliminateLocks і сотні інших.

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

Ну это ок если в продакшин диплоить одни библиотеки, но код навороченный сверху над этими либами все будет так же иметь дело с традиционными проблемами java, которые там уже живут в среднему куда больше 10 лет.

Ну, власне, в JIT купа оптимізацій для багатопоточного коду, типу BiasedLocking, EliminateLocks і сотні інших.

к чему это? конкуретное программирование на java теперь сопоставимо с масштабируемостью, безопасностью и скоростью неконкуретного?

с традиционными проблемами java, которые там уже живут в среднему куда больше 10 лет.

10 років на джава, але щось не в курсі про ці проблеми. Про що мова?

к чему это?

До того, що типова ковбаса на js всеодно буде повільніша ніж на джава, тим паче тепер, коли овер 70% коду в типовому проекті це код з опен-сорсних ліб.

Бенчмарк вище — це по суті тест однієї ліби — http протоколу. І в nodejs я думаю це одна з найбільш швидких ліб.

10 років на джава, але щось не в курсі про ці проблеми. Про що мова?

Устаревший нелаконичный языковой API. Медленно развивающийся язык — в среднем сорцы на java будут занимать куда больше и иметь бесполезного кода тоже больше чем на любом другом статически типизированном языке или managed плафторме в наше время, не говоря уже про скриптовую динамическую ноду. Проблемы миграции на новые версии и обратная совместимость — поправьте меня но тут даже работа с js либами и node апдейтами, куда более удобней организована с куда лучшей совместимостью с куда более major апдейтами api чем java имела когда либо(например переход на ES 6). Куча ограничений jvm/комплиятора — работа с примитивами, отсуствие работы со стеком, непонятные generics, отсуствие делегатов, отсутствие возможностей писать unmanaged код и т.д. Интеграция с нативным кодом и расширениями для ноды и для java пожалуйста будет за первой. Очень ограниченные возможности оптимизации аллокаций, как следствие постоянные разговоры про GC в чувствиетлеьных к latency и stw паузам сценариях — как последствие тюнинг GC который пожалуй куда более нетривиальней работы с указателями, хотя тут у ноды не лучше будет. Ресурсоемкость как при разработке так и в рантайме, node можно споконой разрабатывать и дебажить в текстовом редакторе с подсветкой и все дела. У вас либо коммерческая idea либо eclipse(как стандарт далеко не самой эталанной ide на рынке) и желательно 32 gb что бы не лагало на больших проекта, в контейнере node будет куда проще диплоить и ранить чем java уже почти наверняка. я думаю этот список можно продолжать очень долго.

До того, що типова ковбаса на js всеодно буде повільніша ніж на джава, тим паче тепер, коли овер 70% коду в типовому проекті це код з опен-сорсних ліб.

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

Всі перечислені проблеми або вже вирішені, або ніколи не існували. Сорі, нема часу розписувати по кожному пункту.

Про перформанс, вже навіть не смішно. Я вам показав конкретні бенчмарки. Джава в топі. Поступається лише c/c++, що логічно.

Всі перечислені проблеми або вже вирішені, або ніколи не існували. Сорі, нема часу розписувати по кожному пункту.

Ясно-понятно.

Поступається лише c/c++, що логічно.

Практически в любой нише есть более оптимальный и удобный язык или технология и более быстрый чем java — (go, C#, rust) и т.д., а не только C). Я не говорю уже о достаточном количестве ниш куда java со своим jit/jvm даже не может соваться, в отличии от других даже managed языков, которые развиваться куда быстрее.
(Надеюсь за этим не последует холивар со стороны Java адептов) . Ничего против не имею технологии — но на рынке смотриться уже не привлекательно технология

Запустите по instancy ноды ядро или %сколько там у jvm сервера воркеров на прием% будет такое же как и с netty.

Якщо чесно так і не зрозумів, що ви намагались сказати.
Вважаєте, що бенчмарки не коректні? Там є код на гітхабі. Можете прочекати.

github.com/...​/JavaScript/nodejs/app.js

Я предполагал, что node такие показатели имеет потому, что в режиме одного потока принимает события от сокетов, в отличии от java. Но похоже что нет. Видимо какие-то библиотеки работают в java шустрее таки чем node.

Вестимо JIT + статическая типизация (java / c#) работает быстрее JIT’а и динамической (node + js), что в принципе ожидаемо.

там надо еще правильно UV_THREAD_POOL_SIZE подать — вообще в ноде написать что-то что будет работать правильно и быстро — достаточно сложно — есть много специфических моментов

Тут стоит отметить, что они используют node для вьюх. Да и такие примеры как paypal в данном контексте не очень, так как им ничего не мешает организовать микросервисы, и писать каждый сервис на чем угодно, хоть на go, хоть на js, хоть на scala. Изначальный вопрос был на чем писать игровой сервер, который дробить на множество мини сервисов не очень целесообразно. И писать сервер который не сможет больше чем в один цпу, не очень дальновидно. Смысл делать сервер ради максимально онлайна в пару десятков человек?

И писать сервер который не сможет больше чем в один цпу, не очень дальновидно

Как я понимаю без особых проблем может и межпроцессная коммуникация там покрыта из коробки в ноде в режиме кластера.
nodejs.org/...​l#cluster_event_message_1

В целом в этом контексте можно поинтересоваться у автора сабжа. Если бы это была нерешаемая проблема, как вы ее подаете, с таким жесткм ограничением, то кто-то бы врядли писал на ноде игровые сервера.

Я видел приложения которых бекенд написан на bash, с очередями и прочими ништяками, нерешаемых проблем не бывает. Но это не значит, что нет путей проще и эффективней.

У ноды есть только одно неоспоримое преимущество, это низкий порог входа. Это пхп нашего времени)

Это же много обсуждалось пару лет назад — news.ycombinator.com/item?id=9464851

На жабе есть уже готовые сервера для игр, смартфокс например. Взять что-то готовое как ты понимаешь легче и быстрее, чем писать своё. Выбор-же ноды для игр обусловлен чаще всего технодрочерством молодняка: стильно, модно, молодежно.

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

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

да и писать на нем в разы дешевле чем на строготипизированных языках
Згоден, якщо мова йде про рівень складності «Hello World» або «гостьова книга». Якщо проект складніший, то статична типізація починає сильно спрощувати життя розробникам. І якщо пишеться проект, з рівнем складності як для CMS, великого інтернет-магазина, чи складної гри, то чистий JavaScript сильно ускладнюється і відповідно стає все дорожчим...

Строгу типізацію можна порівняти з написанням тестів — без них писати проект легше, але «не довго».

если нормально писать, то не велика разница

Писать проект легче и быстрее без тестов? Seriously? Правильно написанные тесты (не False-positive) резко уменьшают время на поиск багов и на добавление новых фич (мы сразу увидим, что пошло не так, если что-то пошло не так).

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

Спорно.
Если фича изолирована — ей только новые ЮТ понадобятся.
Если фича в что-то интегрируется, то не представляю себе, зачем переписывать все старые ЮТ: большинство будут новые, частично обновлены старые. Те, что обновлены не будут, и говорят «хазяин, на нашем поле всё хорошо».

Время девелопмента тупо увеличиваеться пропорционально покрытию.
Хм. Время девелопмента состоит из кучи-кучи действий(КО). Можно сказать, что «время девелопмента пропорционально количеству модулей» и начать писать всё в одном, бо создание нового модуля, хоть сколько занимает секунд, всё равно суть «дополнительное время». Но никто ж в здравом уме так не скажет, бо пару секунд на создание модуля и потом куча-куча дополнительнх часов на «разобраться в этой каше».

Потому в целом согласен, что «тупо увеличивается пропорционально», но не согласен с тем, что это нормальная оценка рациональности применения.

Если фича изолирована — ей только новые ЮТ понадобятся.

Изолированные фичи это 1 из 10 в реальном мире.
Если фича в что-то интегрируется, то не представляю себе, зачем переписывать все старые ЮТ: большинство будут новые, частично обновлены старые. Те, что обновлены не будут, и говорят «хазяин, на нашем поле всё хорошо».
все старые ЮТ нет, но пересекающие функциональность фиксить — да. Причем многие разработчики на этом этапе ложат болт (особенно на изначально не свои, комплексные ЮТ), и делают чтобы тупо компилировалось.
Причем многие разработчики на этом этапе ложат болт
многие говнокодеры и прочие криворукие имбецилы

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

и мокающие пол приложения чтобы какуюто фигню оттестить
печаль какая :(

что же это за юнит тесты такие?

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

Реальные посоны сразу комитят, а там тестировщик разберется. Тесты для слабаков. У реальных посонов код сразу идеален и не ломает ни одной старой фичи

«Реальные посоны» в этом случае это простые «клепачи кода». Дядя Боб негодует.

надо было добавить тег «сарказм»? :)

Балшит какойто чесное слово. Добавление новой фичи — переписывание всех югит тестов.
оооо как все запущено...

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

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

я имел в виду что не велика разница между строгой и динамической типизацией)

Щось накрутили. Строга чи статична? Чи і те, і інше з Вашої точки зору «must be»?

Я написав про статичну типізацію, бо користуюсь саме статичною типізацією у TypeScript. Ви вважаєте що коли кажуть «строга типізація» це є далеким від «статичної типізації»?

Добре, але хто не розуміє що це різні поняття? Питання було про «далекість».

Ну це вже жонглювання. Я Вас запитав, на чому власне ви акцентуєте: на статичності, на строгості, чи на обох. Ви чомусь вводите зараз термін «далекість», що ясності не додає.

А чем строгая типизация удорожает разработку? int вместо let — какая разница?

Строгая типизация ОБЛЕГЧАЕТ разработку. Когда ты видишь переменную в любом месте кода, IDE подсказывает, что оно ходит как утка, плавает как утка, крякает как утка, даже если названо «вислоухий тараканчик».

Но когда эта хрень на этапе компиляции начинает ипать мозги, когда на этапе исполнения будет чёткое соответствие — тут да, мелкие накладные расходы. Но это никак не относится к теории, скорее недоработки языков, а потом костыли под эти недоработки, зачем-то именующиеся «синтаксический сахар».

Но когда эта хрень на этапе компиляции начинает ипать мозги

У TypeScript ця фаза зведена до мінімуму, бо IDE прямо під час написання коду підказує ті помилки, що будуть показуватись й під час компіляції/транспіляції.

Щоправда, VS Code (редактор трохи простіший за IDE) показує помилки лише для відкритих файлів. Якщо програміст не відкладав «на потім» виправлення помилок, тобто якщо вони не накопичувались, то виправлення їх займе максимум 5-10 хв. Частіше — такі помилки виправляються зразу, й не доходять до компіляції.

А якщо ще згадати, що сама компіляція займає пару секунд, це можна назвати «непомітним мізером», хоча може так є лише у TypeScript.

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

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

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

Як для JavaScript, TypeScript таки майже панацея.
Ще один вагомий аргумент на його користь: TypeScript — official language at Google

Following my keynote at ng-conf 2017 that seemed to indicate that Typescript is now an official language at Google

TypeScript не является «официальным» языком в Гугле. См developers.google.com/closure/compiler

it compiles from JavaScript to better JavaScript
чомусь згадується старий анекдот: «чего только эти русские не придумают, лишь бы дороги не строить» :)

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

что ж они его в ангуляр свой не запихнули по дефолту, очередная умирающая непопулярная технология от гугла?

Most of the documentation has been written for TypeScript developers and has not yet been translated to JavaScript. Please bear with us. Meanwhile, we’ve provide links to the TypeScript chapters where JavaScript versions are unavailable.
Но в целом намек понятен, раз писал не google значит не официальная. спасибо, посмеялся.

Closure Compiler отлично работает с Angular1. Я пока не слышал про реальные проекты на Angular2.

Очень жаль. тем временем Google уже выпустил в продакшин Angular 4.

TypeScript — official language at Google
Да... а когда-то гугл толкал свой Dart...
Вот помню как-то тогда пробовал в него (в Dart) вкурить — так и не вкурил как его юзать. В общем поделом ему (дарту), ибо тайпскрипт реально кошернее его)

Тратится много времени на описание тех вещех которых можно не описывать

Например? Написать int/void/double вместо function — экономия символов.

Видимо речь про мапу листов мап, или другие вложенные типы

Ну влом каждый раз каждый параметер метода, каждую переменную описывать.

Так им же все равно имена давать надо. Или вы одним пальцем набираете — лишние пара символов очень замедляют?

Вон в хаскеле дают одно, максимум двух буквенное название переменных.

хаскелисты писатели, хаскелисты не читатели?

то есть


/**
* @name {String} name of user from OAuth
* Returns if user already exists
*/
function checkUser(name) {
....
}
не ок, а

function checkUser(String name) {
...
}
уже ок?

я скорее о
function checkUser(users) {
}
вс
checkUser(HashMap<String,ArrayList<HashMap<String,Gender>>> users)

а, ясно. извините.
и как тут строгая типизация уменьшает количество текста?
как по мне — просто из чисто-декларативной области JSDoc перекочевывает в код в виде описания структур, разве нет?

и как тут строгая типизация уменьшает количество текста?

Строгая типизация увеличивает количество текста. Однако облегчает читаемость.
как по мне — просто из чисто-декларативной области JSDoc перекочевывает в код в виде описания структур, разве нет?

док пишут далеко не всегда и не везде, и уж темболее не везде поддерживают.

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

ооо, сначала про юнит-тесты, теперь тут использование классов вместо интерфейсов... Похоже кто-то тут любитель поговнокодить?
Комплимент принят.
п.с. такие сложные вложенные структуры, обычно, имеет смысл делать через доп. VO-шки

Расшифруйте что такое VO-шки.

Коментар порушує правила спільноти і видалений модераторами.

Ну да, а еще фектори для него. адаптер, стратегию, и реджестри.
А потом любители джаваскрипт/го пишут на доу что в джаве нельзя без 100500 фекториСинглтонов.

не, ну миллионная вложенность конечно же лучше. И да, слова выучил отлично )

Не могу найти, где-то были примеры hello world программистов с разным количеством опыта.
После 10-15 лет опыта идет снова возврат к print «Hello world» :)

Хелло ворлд — плохой пример. Нужна какаято реальноя задача.
Помню задачу типа веб страница, что из базы вытягивает данные за какоете время и возвращает юзеру тупой csv.
Сколько времени\строк кода бек энда такое займет на вашей технологии ?
Помню один очень серьезный джава синьйор потратил 2 недели времни с овертаймами(!), и наплодил около сoтни(!) классов.

Энтерпрайз эдишн

Сколько времени\строк кода бек энда такое займет на вашей технологии ?
а тут от программиста зависит, тот же самый потратит теже 2 недели с овертаймами

Он явно это на спор делал, признайтесь :)

Вот это, скорее всего.

Только там не совсем print :)

Похоже, но не совсем то. Но смысл передан)

писать на нем в разы дешевле чем на строготипизированных языках
Вот людям делать нечего, сидят и придумывают свои TypeScript’ы дорогущие

Ибо ынтырпрайзу тоже фронтенд нужен, и там таки тайпскрипт лучше джс

«Написано на Node.js» — це дуже не точне визначення. А взагалі-то, як на мене, без TypeScript писати складну логіку для ігор на JavaScript буде дорого коштувати (в плані написання, а особливо — підтримки)...

писать на Ноде в ТайпСкрипт — полный идиотизм. возьмите тогда vert.x + kotlin

Бессмысленный вопрос, поскольку Go уделал и Node.js, и Java, сразу после scala. Это даже не обсуждается.

Это даже не обсуждается.

Наверное потому, что нету никаких пруфов.

Однажды у Генри Форда спросили, как ему удаётся всегда быть на гребне волны научно-технического прогресса. Он ответил «я создаю эту волну». Если нет нужных пруфов — так создайте их.

Если нет нужных пруфов — так создайте их.

Так они есть. Только не в пользу ГО.

вот пруф от автора nodejs, где он признает, что go намного круче его школьной поделки — www.mappingthejourney.com/...​an-Dahl-Creator-of-Nodejs

это не пруф, а личное мнение того, кто уже 4 года с его же слов не имеет к Ноде никакого отношения

Ну, если yahoo поисковый сервис, то и google поисковый сервис.

писать на том, что лучше всего знаете и не метаться от одного к другому, так и не приступив к работе, вера не позволяет?

Ждал этого ответа, надеялся что его не напишут. Если вы перечитаете мой вопрос, который выделен жирным шрифтом, вы поймете что на вопрос мой так и не ответили.

вы поймете что на вопрос мой так и не ответили.

Ок. Отвечаю. Принципиальной разницы с технической стороны для игры нету. Вообще.
В обоих случаях это вебсокеты. Нода и ява используют один и тот же транспорт на уровне ОС (epoll). Писать колбеками можно на джаве. Писать ООПешно можно на ноде. Писать плохо/хорошо можно под обе платформы.

Есть только небольшая разница с точки зрения бизнеса:

— Джавистов гораздо больше, а значит найти толкового легче и быстрее.
— У джавы больше возможностей для оптимизации и мощнейший JIT.

То есть — в долгосрочной перспективе джава будет получше. За счет возможной экономии железа. Агарио, например, в лучшие дни тратил 10000$ в мес на сервера.

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

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

Нода и ява используют один и тот же транспорт на уровне ОС (epoll).
Даже более того, под юникс других вариантов нет, разве что на блокированных сокетах.
То есть — в долгосрочной перспективе джава будет получше. За счет возможной экономии железа. Агарио, например, в лучшие дни тратил 10000$ в мес на сервера.
Не сгущайте краски в плане издержек, если бизнес пойдёт в гору, и пацаны придут к успеху, серверной мощности домашнего ноута вполне будет достаточно.

Для таких игр идеально подойдет netty на java. Spring противопоказан, так как перформанс.
Но если вы с нетти не знакомы, то лучше на ноде. Правда нода проиграет по перформансу раза в два-три. Но тут уже больше скил разработчкиа играет роль.

Spring противопоказан, так как перформанс
схуяли DI фреймворк как-то аффектит перфоманс ?

А что такое Spring? О чем мы тут вообще? Что именно аффектит перфоманс?

На ноді писати набагато швидше, це дозволяє оперативно відтестувать гіпотезу. А то уявіть: пишете ви фабрики адаптерів до фасадів на джаві місяцями, а гра виявляється нікому не потрібною.

Есть Spring Boot, на котором можно написать простенький сервак.

Написать простенький сервак можна на всьому. Справа в швидкості та зручності.

на буті зараз можна писати так само швидко як і на ноді....

А то уявіть: пишете ви фабрики адаптерів до фасадів на джаві місяцями
dou.ua/…​rums/topic/20228/#1083937
у вас щось болить на цю тему?
пишете ви фабрики адаптерів до фасадів на джаві місяцями
где джава требует это делать? я что-то пропустил?

бывают разрабы которые так делают.

бывают разрабы, которые говнокодят на ноде (если что, абстракции — не говнокод и далеко не всегда усложнения). Может дело не в языке?

Это как в том посту «4 ночи дебажил джаву потомучто забыл ’;’ ». Здесь бы данного автора на винегрет пустили, а в фесбучике ничего — норот лайкает.

Это справедливо только для очень простых приложений. Никто не заставляет писать сразу абстракцию в полный рост. После где-то 5-10кб кода удобство навигации по статическому коду в Джава уже дает о себе знать.

да это же теорема Эскобара

-

Підписатись на коментарі