Тема: Движок la2
Показать сообщение отдельно
Непрочитано 19.01.2017, 01:24   #36

По умолчанию Re: Движок la2

Цитата:
Сообщение от f1redark Посмотреть сообщение
Не вижу проблем, для меня масштабирование это прерогатива архитектуры, а не языка, поэтому что нормальное с++ приложение что java масштабируется, но с++ при этом жрет гораздо меньше памяти, и работает быстрее.

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

Взять то же СПО, вам нужно, чтобы ваш любимый эклипс работал под арм? Под мипс? А игровой сервер?
Кто за вас напишет репликацию сессий игрока между инстансами ваших серверов? А кто за вас реализует шардинг между бд-инстансами(даже подпертыми репликами).
И зачем сравнивать эклипс и l2-сервер. Если говорить об эклипсе, или другом прикладном софте - нужно чтоб он работал на максимальном кол-ве доступного мне оборудования, начиная от макоси заканчивая древней виндой xp. Серверные же приложения должны быть дешевыми в разработке, хорошо масштабироваться, достойно тестироваться. На сях нет шансов написать дешево, быстро и гибко. Вы либо пропарите сроки, либо недотестируете, либо ценник сервака будет заоблачным. И это уже проблема языка и его экосистемы, потому что вместо того чтоб херачить код вы на каждом шаге огребаете от проблем совместимости и перегруженности языка.
Тема про серверный движок, превратилась в холивар. Никто не спорит что некоторый код на с/с++ будет быстрее чем на некоторых других языках. Целесообразно ли писать серверный движок на сях? Абсолютно нет, большинство языков втч java подходят для этого лучше. Мерило для разработки софта - цена/время/качество.
Даже пресловутая поддержка многих архитектурных платформ: когда ваш кластер получает следующую версию оси сервер за сервером (мы же за zero down-time) - java приложение окажется более живучим к обновке и шансы хапнуть горя из-за того что часть кластера была на голом arm железе, другая часть на виртуалках в облаке меньше в разы. Собирать кластер из абсолютно идентичных машин под одно конкретное приложение не очень то выгодно. Если так происходит - значит и приложение заточено именно под это конкретное железо, и юзает его на полную. Но тогда теряется выигрыш от переносимости кода. И что будет через год, когда вашему серваку понадобится более мощное железо? Разбирать кластер не очень-то выгодная затея. И не забывайте про тестовые среды, держать для которых продакшн железо - сильно бьет по карману.
Скорость выполнения кода на С++ как-раз в том, что есть отличная возможность заюзать особенности железа+софта на полную не пользоваться ей и писать более совместимый код который gcc/g++ скомпилит под любую платформу очень не разумно.
Скорость java - в быстром изготовлении продакшн-реди-кода, который можно подкрутить на скорость и новый функционал а также пойти любым из возможных путей по масштабированию этого кода.

Пользуясь случаем - ищу программиста на С++, который пишет а) быстро, б) дешево, в) качественно, г) с набором тестов. Уверен таких не существует, но попробовать стоит.
Camelion вне форума Отправить сообщение для Camelion с помощью ICQ Ответить с цитированием