Вхід і реєстрація
7 квітня 2017, 13:30 5793
Али Альхаулани

Node.js vs Java for multiplayer games

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

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

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

Теми: gamedev, Java, node.js
👍ПодобаєтьсяСподобалось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
Olya Kapinos Head of Marketing в Skyworker 26.10.2017 15:38

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

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

Відповісти
Підтримати
Andy W 06.09.2018 18:43

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

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

Відповісти
Підтримати
Olya Kapinos
And riy 13.04.2017 19:07

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

Відповісти
Підтримати
Aliaksandr Valialkin программист в VictoriaMetrics 14.04.2017 08:49

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

Відповісти
Підтримати
And riy
Lyova Zi 04.09.2017 19:27

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

Відповісти
Підтримати
And riy
Alex Gri Senior Java Developer в Oracle 10.04.2017 12:39

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

Відповісти
Підтримати
Сергей Черепанов ... 10.04.2017 12:24

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

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

Відповісти
Підтримати
Сергей Черепанов ... 10.04.2017 12:38

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

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

go: github.com/mikesaidani/l2go

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

Відповісти
Підтримати
Сергей Черепанов
Victor Trach 05.09.2018 03:45

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

Відповісти
Підтримати
Сергей Черепанов
Сергей Черепанов ... 05.09.2018 13:10

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

Відповісти
Підтримати
Victor Trach
Дмитро 05.09.2018 15:57

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

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

Відповісти
Підтримати
Сергей Черепанов
Дмитро 05.09.2018 16:05

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

Відповісти
Підтримати
anonymous
Дмитро 05.09.2018 17:28
Де пруф що стаття об’єктивна?

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

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

Відповісти
Підтримати
anonymous
Дмитро 05.09.2018 18:00

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

Відповісти
Підтримати
anonymous
Дмитро Думанський Co-Founder в Blynk 05.09.2018 18:10
нода с одним потоком легче выдает в бенчах показатели лучше чем у неискуственно накрученных серверов написанных на java/C#.

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

Відповісти
Підтримати
Дмитро
Дмитро 05.09.2018 18:27

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

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

Відповісти
Підтримати
Дмитро Думанський
Дмитро Думанський Co-Founder в Blynk 05.09.2018 18:40
На графіку нода в середині

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

Відповісти
Підтримати
anonymous
Дмитро 05.09.2018 18:54
Ну і бібліотечний js ад ніхто не відміняв, а скільки там печалькі в типовій апці знає кожен.

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

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

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

Відповісти
Підтримати
Дмитро Думанський
Дмитро 05.09.2018 19:01

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

Відповісти
Підтримати
anonymous
Дмитро 05.09.2018 19:06
Тоді чому виступаєте в ролі фан боя ноде джс? Тролите?

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

Відповісти
Підтримати
anonymous
Дмитро 05.09.2018 19:17
А ви мене одразу хворим назвали.

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

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

Відповісти
Підтримати
anonymous
Дмитро 05.09.2018 19:18
переписують гівно мамонта

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

Відповісти
Підтримати
anonymous
Дмитро Думанський Co-Founder в Blynk 05.09.2018 23:01
типа в java апках боли меньше.

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

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

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

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

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

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

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

Відповісти
Підтримати
Дмитро Думанський
Дмитро Думанський Co-Founder в Blynk 06.09.2018 00:05
с традиционными проблемами java, которые там уже живут в среднему куда больше 10 лет.

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

к чему это?

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

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

Відповісти
Підтримати
Дмитро
Дмитро 06.09.2018 08:09
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 код самостоятельно не писать :)

Відповісти
Підтримати
Дмитро Думанський
Дмитро Думанський Co-Founder в Blynk 06.09.2018 10:38

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

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

Відповісти
Підтримати
Дмитро
Дмитро 06.09.2018 11:06
Всі перечислені проблеми або вже вирішені, або ніколи не існували. Сорі, нема часу розписувати по кожному пункту.

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

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

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

Відповісти
Підтримати
Дмитро Думанський
Дмитро Думанський Co-Founder в Blynk 05.09.2018 18:38
Запустите по instancy ноды ядро или %сколько там у jvm сервера воркеров на прием% будет такое же как и с netty.

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

Відповісти
Підтримати
Дмитро
Дмитро 05.09.2018 18:49

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

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

Відповісти
Підтримати
Дмитро Думанський
Valeriy Shvets Engineer в Phonexa 05.09.2018 18:57

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

Відповісти
Підтримати
Дмитро
anonymus ps 06.09.2018 12:58

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

Відповісти
Підтримати
Дмитро
Сергей Черепанов ... 06.09.2018 11:59

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

Відповісти
Підтримати
Дмитро
Дмитро 06.09.2018 12:05
И писать сервер который не сможет больше чем в один цпу, не очень дальновидно

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

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

Відповісти
Підтримати
Сергей Черепанов
Сергей Черепанов ... 06.09.2018 12:32

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

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

Відповісти
Підтримати
Дмитро
zzhou 09.04.2017 01:58

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

Відповісти
Підтримати
Grez
Владимир Кожаев 08.04.2017 15:16

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

Відповісти
Підтримати
schwarzlichtbezirk 08.04.2017 18:21
Взять что-то готовое как ты понимаешь легче и быстрее, чем писать своё.
Вот именно, я того же мнения. Есть куча отличных проектов, на которые положили болт, на некоторые из них — с левой резьбой. Взяв любой из них можно сэкономить кучу времени на изобретении велосипеда.
Відповісти
Підтримати
Владимир Кожаев
anonymous 08.04.2017 09:25

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

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

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

Відповісти
Підтримати
anonymous
Jim Moriarty 09.04.2017 01:45

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

Відповісти
Підтримати
Костя Третяк
Maksym D 10.04.2017 12:20

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

Відповісти
Підтримати
Костя Третяк
Grez 11.04.2017 08:57
резко уменьшают время на добавление новых фич
Балшит какойто чесное слово. Добавление новой фичи — переписывание всех югит тестов. Время девелопмента тупо увеличиваеться пропорционально покрытию.
Відповісти
Підтримати
Maksym D
Євген Козлов Front-end developer в SoftServe 11.04.2017 09:06

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

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

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

Відповісти
Підтримати
Grez
Grez 11.04.2017 09:21
Если фича изолирована — ей только новые ЮТ понадобятся.

Изолированные фичи это 1 из 10 в реальном мире.
Если фича в что-то интегрируется, то не представляю себе, зачем переписывать все старые ЮТ: большинство будут новые, частично обновлены старые. Те, что обновлены не будут, и говорят «хазяин, на нашем поле всё хорошо».
все старые ЮТ нет, но пересекающие функциональность фиксить — да. Причем многие разработчики на этом этапе ложат болт (особенно на изначально не свои, комплексные ЮТ), и делают чтобы тупо компилировалось.
Відповісти
Підтримати
Євген Козлов
Vasya Pupking 11.04.2017 20:31
Причем многие разработчики на этом этапе ложат болт
многие говнокодеры и прочие криворукие имбецилы
Відповісти
Підтримати
Grez
Grez 11.04.2017 23:03

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

Відповісти
Підтримати
Vasya Pupking
Євген Козлов Front-end developer в SoftServe 11.04.2017 23:34
и мокающие пол приложения чтобы какуюто фигню оттестить
печаль какая :(
Відповісти
Підтримати
Grez
Vadim Kopanev Architect 12.04.2017 00:34

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

Відповісти
Підтримати
Grez
Maksym D 11.04.2017 19:06

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

Відповісти
Підтримати
Grez
Vasya Pupking 11.04.2017 20:34

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

Відповісти
Підтримати
Maksym D
Maksym D 11.04.2017 21:16

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 11.04.2017 21:21

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

Відповісти
Підтримати
Maksym D
Vasya Pupking 11.04.2017 20:30
Балшит какойто чесное слово. Добавление новой фичи — переписывание всех югит тестов.
оооо как все запущено...
Відповісти
Підтримати
Grez
Grez 11.04.2017 23:07

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 12.04.2017 00:28

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

Відповісти
Підтримати
Grez
Jim Moriarty 11.04.2017 23:06

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

Відповісти
Підтримати
Maksym D
Viktor Kryvyziuk 10.04.2017 16:57

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

Відповісти
Підтримати
Костя Третяк
Костя Третяк 10.04.2017 17:10

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

Відповісти
Підтримати
Viktor Kryvyziuk
Костя Третяк 10.04.2017 17:15

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

Відповісти
Підтримати
Viktor Kryvyziuk
Viktor Kryvyziuk 10.04.2017 17:21

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

Відповісти
Підтримати
Костя Третяк
zzhou 09.04.2017 02:05

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

Відповісти
Підтримати
anonymous
Олексій Пєніє 09.04.2017 03:36

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

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

Відповісти
Підтримати
zzhou
Костя Третяк 09.04.2017 11:33
Но когда эта хрень на этапе компиляции начинает ипать мозги

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

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

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

Відповісти
Підтримати
Олексій Пєніє
Jim Moriarty 11.04.2017 23:28

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

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

Відповісти
Підтримати
Костя Третяк
Євген Козлов Front-end developer в SoftServe 11.04.2017 23:35
что будет с твоей типизацией когда кто то полезет править напрямую выплюнутый твоим тайпскриптом жс?
эм. это жопа в процессе и к типизации отношения не имеет.
Відповісти
Підтримати
Jim Moriarty
Костя Третяк 12.04.2017 00:27

Як для 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
Відповісти
Підтримати
Jim Moriarty
zzhou 12.04.2017 08:43

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

Відповісти
Підтримати
Костя Третяк
Vitaliy Fedoriv Java Developer 12.04.2017 10:25
it compiles from JavaScript to better JavaScript
чомусь згадується старий анекдот: «чего только эти русские не придумают, лишь бы дороги не строить» :)
Відповісти
Підтримати
zzhou
zzhou 12.04.2017 16:47

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

Відповісти
Підтримати
Vitaliy Fedoriv
Дмитро 12.04.2017 14:08

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

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 значит не официальная. спасибо, посмеялся.
Відповісти
Підтримати
zzhou
zzhou 12.04.2017 16:59

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

Відповісти
Підтримати
Дмитро
Дмитро 12.04.2017 22:27

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

Відповісти
Підтримати
zzhou
minodvesP Vasya 12.04.2017 13:25
TypeScript — official language at Google
Да... а когда-то гугл толкал свой Dart...
Вот помню как-то тогда пробовал в него (в Dart) вкурить — так и не вкурил как его юзать. В общем поделом ему (дарту), ибо тайпскрипт реально кошернее его)
Відповісти
Підтримати
Костя Третяк
anonymous 09.04.2017 08:04

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

Відповісти
Підтримати
zzhou
zzhou 09.04.2017 08:16

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

Відповісти
Підтримати
anonymous
Grez 09.04.2017 19:31

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

Відповісти
Підтримати
zzhou
Grez 11.04.2017 08:59

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

Відповісти
Підтримати
zzhou
zzhou 11.04.2017 09:06

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

Відповісти
Підтримати
Grez
Grez 11.04.2017 09:15

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

Відповісти
Підтримати
zzhou
Vasya Pupking 11.04.2017 20:35

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

Відповісти
Підтримати
Grez
Євген Козлов Front-end developer в SoftServe 11.04.2017 09:08

то есть


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

function checkUser(String name) {
...
}
уже ок?
Відповісти
Підтримати
Grez
Grez 11.04.2017 09:13

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

Відповісти
Підтримати
Євген Козлов
Євген Козлов Front-end developer в SoftServe 11.04.2017 09:23

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

Відповісти
Підтримати
Grez
Grez 11.04.2017 09:29
и как тут строгая типизация уменьшает количество текста?

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

док пишут далеко не всегда и не везде, и уж темболее не везде поддерживают.
Відповісти
Підтримати
Євген Козлов
Vasya Pupking 11.04.2017 20:36

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

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

Расшифруйте что такое VO-шки.
Відповісти
Підтримати
Vasya Pupking
Grez 12.04.2017 23:53

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 13.04.2017 00:35

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

Відповісти
Підтримати
Grez
Alex Koshterek погромизд 13.04.2017 10:47

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

Відповісти
Підтримати
Grez
Grez 13.04.2017 18:59

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

Відповісти
Підтримати
Alex Koshterek
Alex Koshterek погромизд 13.04.2017 19:08

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

Відповісти
Підтримати
Grez
Vadim Kopanev Architect 13.04.2017 19:34
Сколько времени\строк кода бек энда такое займет на вашей технологии ?
а тут от программиста зависит, тот же самый потратит теже 2 недели с овертаймами
Відповісти
Підтримати
Grez
Valentin Nechayev архімаггриб в Дарницькі печери 14.04.2017 10:06

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

Відповісти
Підтримати
Grez
Valentin Nechayev архімаггриб в Дарницькі печери 14.04.2017 10:05

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

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

Відповісти
Підтримати
Alex Koshterek
Alex Koshterek погромизд 14.04.2017 17:34

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

Відповісти
Підтримати
Valentin Nechayev
Oleksandr Narbut .Net developer 10.04.2017 12:18
писать на нем в разы дешевле чем на строготипизированных языках
Вот людям делать нечего, сидят и придумывают свои TypeScript’ы дорогущие
Відповісти
Підтримати
anonymous
anonymous 12.04.2017 09:40

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

Відповісти
Підтримати
Oleksandr Narbut
Костя Третяк 08.04.2017 04:27

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

Відповісти
Підтримати
anonymus ps 06.09.2018 13:09

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

Відповісти
Підтримати
Костя Третяк
schwarzlichtbezirk 08.04.2017 04:15

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

Відповісти
Підтримати
Дмитро Думанський Co-Founder в Blynk 08.04.2017 11:14
Это даже не обсуждается.

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

Відповісти
Підтримати
schwarzlichtbezirk
schwarzlichtbezirk 08.04.2017 18:29

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

Відповісти
Підтримати
Дмитро Думанський
Дмитро Думанський Co-Founder в Blynk 08.04.2017 18:44
Если нет нужных пруфов — так создайте их.

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

Відповісти
Підтримати
schwarzlichtbezirk
Aliaksandr Valialkin программист в VictoriaMetrics 04.09.2017 18:33

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

Відповісти
Підтримати
Дмитро Думанський
Євген Козлов Front-end developer в SoftServe 04.09.2017 23:36

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

Відповісти
Підтримати
Aliaksandr Valialkin
Artem Bondarenko Embedded enginner (HW/FW/SW) в Looking for relocation. 12.04.2017 15:42

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

Відповісти
Підтримати
anonymous
Корнеев Дмитрий Software developer в Cossack Labs 08.04.2017 00:34

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

Відповісти
Підтримати
Али Альхаулани 08.04.2017 16:13

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

Відповісти
Підтримати
Корнеев Дмитрий
Дмитро Думанський Co-Founder в Blynk 08.04.2017 16:58
вы поймете что на вопрос мой так и не ответили.

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

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

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

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

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

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

Відповісти
Підтримати
Али Альхаулани
schwarzlichtbezirk 08.04.2017 18:18
Нода и ява используют один и тот же транспорт на уровне ОС (epoll).
Даже более того, под юникс других вариантов нет, разве что на блокированных сокетах.
То есть — в долгосрочной перспективе джава будет получше. За счет возможной экономии железа. Агарио, например, в лучшие дни тратил 10000$ в мес на сервера.
Не сгущайте краски в плане издержек, если бизнес пойдёт в гору, и пацаны придут к успеху, серверной мощности домашнего ноута вполне будет достаточно.
Відповісти
Підтримати
Дмитро Думанський
Дмитро Думанський Co-Founder в Blynk 07.04.2017 14:22

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

Відповісти
Підтримати
Vasya Pupking 07.04.2017 21:32
Spring противопоказан, так как перформанс
схуяли DI фреймворк как-то аффектит перфоманс ?
Відповісти
Підтримати
Дмитро Думанський
Vasya Pupking 11.04.2017 03:08

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

Відповісти
Підтримати
Дмитро Думанський
Yury Gavrilenko 07.04.2017 14:02

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

Відповісти
Підтримати
Taras Murzenkov Java Developer. 07.04.2017 14:06

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

Відповісти
Підтримати
Yury Gavrilenko
Yury Gavrilenko 07.04.2017 14:08

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

Відповісти
Підтримати
Taras Murzenkov
Mikhail Dubovskiy 09.04.2017 19:02

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

Відповісти
Підтримати
Yury Gavrilenko
sanchez 07.04.2017 20:51
А то уявіть: пишете ви фабрики адаптерів до фасадів на джаві місяцями
dou.ua/…​rums/topic/20228/#1083937
у вас щось болить на цю тему?
Відповісти
Підтримати
Yury Gavrilenko
Vasya Pupking 07.04.2017 21:34
пишете ви фабрики адаптерів до фасадів на джаві місяцями
где джава требует это делать? я что-то пропустил?
Відповісти
Підтримати
Yury Gavrilenko
Grez 08.04.2017 18:41

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 11.04.2017 03:10

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

Відповісти
Підтримати
Grez
Grez 11.04.2017 09:05

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

Відповісти
Підтримати
Vasya Pupking
Taras Kovtun живет в своих мечтах 07.04.2017 22:23

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

Відповісти
Підтримати
Yury Gavrilenko
Vadim Kopanev Architect 07.04.2017 14:02

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

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.