Zakładając, że tworzymy serwer do gry MMO gry z wczesnych lat 2000: Metin, Tabaluga, Tibia, Kabal.
Czy Rust jest do tego zadania lepszy?
0
1
Zależy która część serwera, bo zazwyczaj tam jest więcej niż jedna usługa.
0
hauleth napisał(a):
Zależy która część serwera, bo zazwyczaj tam jest więcej niż jedna usługa.
https://github.com/geektcp/everwar
https://github.com/otland/forgottenserver
Emulacja świata gry, łączenie z bazą danych, udostępnienie api do języka typu lua, komunikacja z clientem gry.
4
To zależy — czy Ty i Twój zespół znacie Rusta? Czy znacie C++?
C++ w greenfieldowych projektach da się pisać naprawdę sensownie i bezpiecznie, porównywalnym (chociaż większym) nakładem wysiłku, jak przy Ruście; za to dużo łatwiej o ludzi do pomocy/zatrudnienia, czy trochę łatwiej o zewnętrzne biblioteki.
4
Althorion napisał(a):
To zależy — czy Ty i Twój zespół znacie Rusta? Czy znacie C++?
No właśnie. To jest kluczowe pytanie.
Moim zdaniem żeby coś na poważnie zrobić w Rust, trzeba najpierw zrobić co na niepoważnie, poświęcić trochę czasu na naukę tego języka (co jest super przygodą, ale jednak zajmuje to czas).
Istnieją łatwe języki, gdzie zaczynasz i już możesz coś napisać bez większej znajomości języka (jak np. Python, czy ogólnie języki skryptowe), ale Rust to raczej poziom wyżej trudności. Trzeba się nauczyć myśleć po rustowemu. Bez tego nie będziesz produktywny i możesz się męczyć nad tym, żeby ci się w ogóle skompilował kod (Rust jest bardziej ścisły niż większość mainstreamowych języków).
Z drugiej strony C++ też jak nie znasz, to nie zrobisz. Albo co gorsza zrobisz źle i będzie apka odwoływać się do nieprawidłowych obszarów pamięci, na co Rust by nie pozwolił.
1
Althorion napisał(a):
To zależy — czy Ty i Twój zespół znacie Rusta? Czy znacie C++?
Można, a nawet warto się kierować, który język się zna i w którym umie się to zrobić. Przede wszystkim, żaden język nie jest lepszy ani gorszy w tym zastosowaniu, Oba kompilują się do kodu binarnego, oba mają podobne możliwości. Przede wszystkim, należy wiedzieć, co jest potrzebne poza samymi algorytmami. Różnica zaczyna być odczuwalna dopiero w zastosowaniach nietypowego I/O lub elementów, które są typowe w danym zastosowaniu, ale nie istniejące w standardowej bibliotece języka.
Co do C++ i Rust to nie wiem, ale na przykład załóżmy, że chcę napisać apkę na IPhone, znam dobrze C++, a nie znam w ogóle Swift. Bardzo możliwa jest sytuacja, że napisanie nawet prostej apki pod iOS w C++ jest możliwe, ale powiązanie z API iOS jest trudne, a z kolei zrobienie tego samego dla osoby znającej Swift jest łatwe.
Aby ułatwić wybór, to pomyśl, co będzie potrzebne do Twojego programu. Przykładowo może być:
- Nasłuch na porcie, przyjmowanie połączeń TCP i strumień gniazda TCP.
- Odczyt i zapis pliku binarnego.
- Połączenie z baza danych, wysyłanie poleceń SQL i odbiór tabeli będące odpowiedzią na polecenie "select".
- Tworzenie bitmapy i zapisanie jej w pliku PNG (w serwerze do gry raczej tego nie będzie, ale to tak przykładowo).
- Nagrywanie dźwięku z mikrofonu.
Potem pomyśl, czy umiesz zrealizować zrealizować każdy element osobno. Jak nie umiesz, to poczytaj, czy to jest możliwe i jak to zrobić, po prostu wpiszesz w google np. "rust create bitmap image", znajdziesz jakiś przykład i spróbujesz go uruchomić. Mając wiedzę, jak zrobić każdy element programu i jak użyć w swoim programie (na przykład nagranie dźwięku z mikrofonu na serwerze po przyjęciu połączenia, namalowanie spectrogramu i wysłanie obrazu do klienta, który się podłączył), to już wiesz, ze w tym języku zrobisz ten program i weźmiesz pod uwagę. Potem pomyśl, w którym języku łatwiej Tobie zrobić program.
Althorion napisał(a):
Moim zdaniem żeby coś na poważnie zrobić w Rust, trzeba najpierw zrobić co na niepoważnie, poświęcić trochę czasu na naukę tego języka (co jest super przygodą, ale jednak zajmuje to czas).
Z drugiej strony C++ też jak nie znasz, to nie zrobisz. Albo co gorsza zrobisz źle i będzie apka odwoływać się do nieprawidłowych obszarów pamięci, na co Rust by nie pozwolił.
Znam dobrze C++, zarządzanie pamięcią w C++ mam "w małym palcu", choć to często wymieniana wada tego języka, a Rust w ogóle. Niedawno sam miałem taki sam dylemat, jak zacząłem interesować się WebASM. Akurat te dwa języki najlepiej nadają się do tego i wydaje się, że nie ma większej różnicy, w czym zaprogramuję w sensie, że to samo można zrobić i w jednym i w drugim. Wybrałem C++ dlatego, że ja to znam, chciałem też przerobić jedną aplikację napisaną wcześniej w Java lub C# i moim zdaniem łatwiej przerobić do C++ niż do Rust. Wielowątkowość się przyda, w C++, C# i Java uruchamianie nowego wątku robi się w podobny sposób. Generalnie, można powiedzieć, ze Java, C++ i C# są takie same pod względem ogólnych założeń, sposobu deklarowania i działania stałych, zmiennych, plików, wątków i wiele więcej. Oczywiscie, że składnia się różni, funkcje biblioteki standardowej też się różnią, ale idea jest ta sama. W Rust już takie podstawy, jak zmienne, obiekty i wskaźniki działają zupełnie inaczej.
W C++ to znalazłem kompilator, skompilowałem przysłowiowy "hello world", poczytałem i popróbowałem współpracę z JavaScript, wielowątkowość (bo w WebASM to nie jest takie proste i oczywiste, w przeciwieństwie do desktopowych apek) i tyle. Już mogłem tworzyć coś konkretnego. A gdybym chciał zacząć w Rust, to trochę wody w rzecze by upłynęło zanim zrobię jakiś większy program. Jakbym bardzo chciał, to bym opanował Rust i miał program w Rust, ale C++ vs Rust, to w moim przypadku równa się "gorszy język i cały program po w miarę krótkim czasie czy lepszy język i program po bardzo długim czasie".
Może i Rust obiektywnie jest lepszy, bo kompilator pilnuje, żeby nie zrobić "kuku" w pamięci, wielowątkowość realizuje się z dużym naciskiem na bezpieczeństwo danych i operacji, nie ma rzucania i łapania wyjątków. Kolejna nowością są zmienne mutowalne i niemultowalne, nie rozumiem, po co to jest. Przypuszczam, że kompilator lepiej optymalizuje zmienne niemutowalne, bo wie, że wartość przypisuje się tylko jeden raz. Mam wrażenie, że ten, kto wymyślił Rust, zebrał wszystkie słabości C++ i chciał wymyślić język wolny od tych słabości, w którym podstawowych zasad bezpieczeństwa (w szczególności zarządzenie pamięcią) pilnuje kompilator. Z drugiej strony, C++ wcale nie jest taki zły, szczególnie, jak korzysta się z inteligentnych wskaźników zamiast wyrażonego wprost alokowania i zwalniania pamięci (słowa new i delete), a w wątkach ma się do dyspozycji mutex, który pozwala tworzyć sekcje krytyczne.
Pod pojęciem "większy program" rozumiem takie programy (właściwie to można zaliczyć do tego wszystkie projekty na moim GitHub):
https://github.com/andrzejlisek/TextPaint
https://github.com/andrzejlisek/Roulette
https://github.com/andrzejlisek/XorFile
1
andrzejlisek napisał(a):
Może i Rust obiektywnie jest lepszy, bo kompilator pilnuje, żeby nie zrobić "kuku" w pamięci, wielowątkowość realizuje się z dużym naciskiem na bezpieczeństwo danych i operacji, nie ma rzucania i łapania wyjątków. Kolejna nowością są zmienne mutowalne i niemultowalne, nie rozumiem, po co to jest.
Żeby wygodniej panować nad tym, kto ma dostęp do których danych i kto może je zmieniać i kiedy.
Przypuszczam, że kompilator lepiej optymalizuje zmienne niemutowalne, bo wie, że wartość przypisuje się tylko jeden raz.
Nie wiem, co robi kompilator, ale nie trzeba myśleć o optymalizacji, żeby dostrzec zyski z niemutowalności albo z kontroli mutowalności (czyli rzeczy mogą być mutowalne, ale tylko w konkretnych miejscach).
Ogólnie jak masz wartość X i pewien kawałek kodu działa w oparciu o to, że X się nie zmieni, to zmiana X byłaby jak podcinanie gąłęzi (np. iterujesz po tablicy w przód i jednocześnie usuwasz z niej elementy albo przesuwasz dowoli).
Albo jak masz 2 kawałki kodu i jeden kawałek kodu zmienia X, a kawałek kodu działa w oparciu, że X się nie zmieniło.
To łatwo może doprowadzić do bugów. Sprawa jest na tyle poważna, że nawet programiści JavaScript zdali sobie sprawę z korzyści niemutowalności albo kontroli mutowalności (choćby te wszystkie menedżery stanu w JS do tego służą, chociaż tu kontrola mutacji idzie w parze również z reaktywnością).
Natomiast w Rust jest akurat to fajnie rozwiązane, czego brak mi w JS, czyli prawdziwej kontroli na poziomie języka tego, kto może kiedy i co mutować. Że jeśli funkcja dostanie niemutowalną referencję do czegoś, to nie zmutuje jej przez nieuwagę czy brak dyscypliny programisty, bo taki kod się nie skompiluje.
1
LukeJL napisał(a):
Nie wiem, co robi kompilator, ale nie trzeba myśleć o optymalizacji, żeby dostrzec zyski z niemutowalności albo z kontroli mutowalności (czyli rzeczy mogą być mutowalne, ale tylko w konkretnych miejscach).
Ogólnie jak masz wartość X i pewien kawałek kodu działa w oparciu o to, że X się nie zmieni, to zmiana X byłaby jak podcinanie gąłęzi (np. iterujesz po tablicy w przód i jednocześnie usuwasz z niej elementy albo przesuwasz dowoli).
Albo jak masz 2 kawałki kodu i jeden kawałek kodu zmienia X, a kawałek kodu działa w oparciu, że X się nie zmieniło.
To łatwo może doprowadzić do bugów. Sprawa jest na tyle poważna, że nawet programiści JavaScript zdali sobie sprawę z korzyści niemutowalności albo kontroli mutowalności (choćby te wszystkie menedżery stanu w JS do tego służą, chociaż tu kontrola mutacji idzie w parze również z reaktywnością).
Natomiast w Rust jest akurat to fajnie rozwiązane, czego brak mi w JS, czyli prawdziwej kontroli na poziomie języka tego, kto może kiedy i co mutować. Że jeśli funkcja dostanie niemutowalną referencję do czegoś, to nie zmutuje jej przez nieuwagę czy brak dyscypliny programisty, bo taki kod się nie skompiluje.
Co do Rust, to czytałem, że w miarę możliwości zaleca się tworzyć zmienne niemutowalne, nawet domyślnie zmienna jest niemutowalna, a żaby była mutowalna, trzeba dopisać słowo mut. Moim zdaniem, w JS jest dokładnie to samo, czyli const dla niemutowalnych i let dla mutowalnych. Szczegóły działania kompilatora nie są ważne, rozumiem, że zalecenie stosowania niemutowalnych służy przede wszystkim zwróceniu uwagi na możliwe bugi wywołane wielokrotnie przypiasaniem wartości. przy kompilacji (Rust) lub uruchamianiu (JS) wyskoczy błąd i albo programista z premedytacją robi zmienną mutowalną (dopisuje mut w Rust lub zmienia const na let w JS), albo widzi bug i go poprawia. Czy to właśnie o to chodzi?
2
@Althorion: Firma kumpla przkeonała klienta do zrobienia projektu w rust zamiast c++. 90% załogi uczyło się w trakcie, z obserwacji mówi że skończyli go z mniejszą iością błędów. Zgodzę się co do bibliotek ale ludzie ogarną. Raczej to kwestia tego że już w dużym embeeded firmy napisały swoje libki w c++ i jest nie chcęć do wrapowania ich a już na pewno przepisywania.
2
andrzejlisek napisał(a):
Moim zdaniem, w JS jest dokładnie to samo, czyli
constdla niemutowalnych iletdla mutowalnych.
Dobrze by było, gdyby w JS było tak samo, niestety nie jest i na tym polega problem.
W JS przy użyciu const tylko zmienna jest stała, a nie wartość, którą można dalej sobie zmieniać dowoli:
const a = {x: 1, y: 1};
a.x = 10;
a.y = 123;
// ale tego już nie zrobimy, bo byłoby to przypisanie zmiennej:
// a = {x: 2, y: 2};
czyli dopóki nie przypisujemy całkiem nowej wartości do zmiennej, ale zmieniamy w środku obiekt, to JS nie widzi problemu (pewnym złagodzeniem może być readonly z TS, ale to też raczej proteza, która działa tylko w niektórych usecase'ach).
natomiast w Rust adekwatny kod:
struct Point {
x: i32,
y: i32,
}
fn main() {
let foo = Point {x: 1, y: 1};
foo.x = 10;
foo.y = 123;
}
się już nie skompiluje, ponieważ Rust widzi, że chcemy zmienić strukturę w środku, więc wyskoczy błąd kompilacji:
cannot assign to `foo.x`, as `foo` is not declared as mutable
Czyli Rust pozwala na więcej przewidywalności.
Możemy również robić referencje do wartości (niemutowalne &foo i mutowalne &mut foo) i przekazywać je do funkcji, które takich referencji wymagają. I mamy więcej przewidywalności, szczególnie, że jest borrow checker, który pilnuje i np. możesz mieć ile chcesz niemutowalnych referencji, ale jeśli masz mutowalną referencję, to nie możesz mieć innych w tym czasie (albo wartość jest tylko do odczytu i wtedy nie ma problemu z dzieleniem, albo wartość jest zapisywana i tylko jeden kawałek kodu może mieć dostęp do takiej wartości, która może być w każdej chwili zmieniona) i kompilator tego pilnuje (czasem aż za mocno).
w JS natomiast jest łatwiej pisać, ale też mniej ochrony przed różnymi dziwnymi błędami.
6
Kolejna nowością są zmienne mutowalne i niemultowalne, nie rozumiem, po co to jest.
Zmienne niemutowalne można bezpiecznie współdzielić. Zmienne mutowalne nie mogą być współdzielone aby uniknąć sytuacji że w jednym miejscu kodu zmienna ma wartość 1 a dwie linijki dalej ma już wartość 2 mimo że pomiędzy nie była wcale zmieniana. Spooky action at a distance to jest bolączka praktycznie wszystkich języków które mają referencje / wskaźniki oraz dowolne mutowanie wszystkiego.
Stan współdzielony rozwiązuje się historycznie na kilka sposobów:
- zabraniając współdzielenia (message passing, Erlang)
- zabraniając mutacji (programowanie funkcyjne)
- ograniczając zasięg mutacji przez enkapsulację (programowanie obiektowe, bardzo niedoskonałe rozwiązanie)
- zabraniając współdzielenia i mutacji równocześnie ale pozwalając na mutacje lub współdzielenie osobno (Rust)
0
Z ciekawości zapytam. Programuje w Javie dość długo (jeszcze nie zawodowo) i jakiś czas temu napisałem Hello Worda w Rust, poczytałem trochę i w miarę luźniejszego okresu mam w planach hobbystycznie przysiąść do niego. Czy z Javy ciężko przestawić myślenie na Rust? Tam nie ma obiektów, dziedziczenia itd. Fajne recenzje ten język ma i kusi.
2
IceBreaker napisał(a):
Z ciekawości zapytam. Programuje w Javie dość długo (jeszcze nie zawodowo) i jakiś czas temu napisałem Hello Worda w Rust, poczytałem trochę i w miarę luźniejszego okresu mam w planach hobbystycznie przysiąść do niego. Czy z Javy ciężko przestawić myślenie na Rust? Tam nie ma obiektów, dziedziczenia itd. Fajne recenzje ten język ma i kusi.
Może być ciężko. Kod w Rust pisze się inaczej niż w Javie. Mocno inaczej.
- Należy niemal zapomnieć o umieszczaniu referencji między obiektami. Tzn da się, ale jest to trudne i często niepotrzebne. Styl budowania programów jako graf obiektów w Rust nie działa.
- W szczególności referencje cykliczne między obiektami są fatalnym pomysłem.
- Enumy + pattern matching (switch) jest używany bardzo często zamiast klasycznego polimorfizmu z interfejsami / dziedziczeniem.
- Nie ma dziedziczenia w ogóle, ale to akurat pikuś, bo i tak w Javie pewnie korzysta głównie z kompozycji.
- Nie ma GC i trzeba się trochę przyzwyczaić do np. przesuwania wartości i w ogóle operowania wartościami zamiast żąglowania referencjami. W sensie, jak nie załapiesz jak działa
moveto będziesz mieć cholernie pod górkę. Do tego trzeba się trochę nauczyć różnych idiomów, np. internal mutability czy zliczanie referencji przez Rc/Arc. - Traity/genericsy Rust są potężniejsze niż interfejsy/genericsy Javy i wymagają trochę nauki aby wykorzystać ich pełną moc. Ogólnie systemowi typów Rust jest znacznie bliżej do Haskella / Scali / ML niż Javy.
- Jest wiele rzeczy których w ogóle nie ma w Javie, np. makra proceduralne.
Znajomość C++ / ML / Scali na pewno pomaga bardziej niż znajomość samej Javy.
0
Tak potężne projekty jak silnik do gier potrzebują pełnego wsparcia do paradygmatu OOP a jednocześnie wolności do pełnej optynalizacji. Jak to drugie może Rust dawać, tak to pierwsze to już srednio z tego co się orientuje.
2
Rust ma wszystko z OOP z wyjątkiem dziedziczenia. Po co Ci dziedziczenie w silniku gier?
Poza tym akurat w grach możesz mieć setki tysięcy obiektów i modelowanie tego za pomocą OOP będzie niewydajne. Znacznie lepsze jest ECS czy podejścia zorientowane na dane. Tj. projektujesz struktury tak aby dały się wydajnie przetwarzać przez CPU/GPU a nie tak aby reprezentowały jakieś rzeczywiste byty w grze. Czyli np sprity w grze mogę nie być reprezentowane przez obiekty w jednej kolekcji a rozbite na różne komponenty przechowywane w osobnych kolekcjach.
Ponadto OOP które polega na polimorfizmie dynamicznym (czasu wykonania) ma dość spory narzut - metody wirtualne, nagłówki obiektów marnujace pamięć i zmniejszające efektywne użycie cache CPU. My mamy ten problem w Cassandra, bo ktoś kiedyś wymyślił że wiersze tabelek będą wewnętrznie reprezentowane obiektowo, i w efekcie każda celka bazy jest wrapowana w obiekt, serializatory i deserializatory są za interfejsami, aby np odczytać długość komórki danych musisz wywołać metodę wirtualną (polimorficzną względem typu danych) i to wszystko razem choć może i ładnie się czyta, to chodzi jak g**no. I nie da się łatwo poprawić bo to trzon bazy. W efekcie Cassandra jest nadal CPU-bound a powinna być I/O bound.
Btw: istnieją silniki gier w Rust wykorzystujące podejścia zorientowane na dane np. Bevy. A Godot, napisany zdaje się w C++, ostatnio dodał Rust jako język skryptowania i jakoś brak dziedziczenia nie przeszkadza.
0
Czitels napisał(a):
Tak potężne projekty jak silnik do gier potrzebują pełnego wsparcia do paradygmatu OOP a jednocześnie wolności do pełnej optynalizacji. Jak to drugie może Rust dawać, tak to pierwsze to już srednio z tego co się orientuje.
Co to jest pełne wsparcie do paradygmatu OOP i czemu silniki gier go wg ciebie potrzebują?
Ja jeśli widzę argumenty silnie pro albo anty OOP, to mam wrażenie, że OOP nie istnieje i jest uzywane albo jako sposób w jaki przyzwyczaiłem się pisać i nie umiem inaczej, jeśli ktoś jest zwolennikiem, albo sposób w jaki odzwyczaiłem się pisać i nim gardzę, jeśli pada z ust przeciwnika OOP.
3
Anatolijus napisał(a):
Zakładając, że tworzymy serwer do gry MMO gry z wczesnych lat 2000: Metin, Tabaluga, Tibia, Kabal.
Czy Rust jest do tego zadania lepszy?
Najlepszy będzie język, który znacie najlepiej. Serwer gry MMO na prawdę nie wiele robi i ani Rust ani C++ nie bylby moim pierwszym wyborem. Osobiście wybrałbym nodejs bo jest prosty, lekki, wygodny. Ewentualnie jakbym miał ochotę nauczyć się czegoś nowego to może GO. Po osiągnięciu fazy późnego prototypu zrobiłbym ewaluację.
Jeżeli robicie P2P (coś jak Warframe) to lokalny serwer powinien być zrobiony w języki w jaki robicie klienta dla wygody deplojmentu a wtedy serwery do apdejtu konta w czymkolwiek co znacie najlepiej, ale znowu, nodejs nie będzie najgorszym wyborem.
1
TL;RD, bo na kupę muszę.
Temat wątku:
Czy Rust jest lepszy od C++ do tworzenia serwerów gier?
Nie. Rust nie byłby lepszy od C++, a C++ nie byłby lepszy od C, ani od Pascala, ani od C# czy Javy. Pytanie, które zadałeś w temacie wątku, to nie jest pytanie technologiczne, a filozoficzne — nie ma na nie odpowiedzi. Jeśli brać pod uwagę języki programowania ogólnego przeznaczenia, to nie ma takiego, w którym nie dałoby się napisać serwera dla jakiejkolwiek gry.
Zaplusowałem powyższy post @severala, dlatego że zawiera kluczową wskazówkę:
several napisał(a):
Najlepszy będzie język, który znacie najlepiej.
Jeśli znasz język Rust, to użyj Rust, jeśli znasz inny, to użyj któregokolwiek innego — w każdym możesz napisać taki backend. Do tego, jeśli nie planujesz stawiać serwera obsługującego dziesiątki tysięcy graczy jednocześnie, to nawet wydajność nie ma większego znaczenia, bo dla prostej gry to i największy bloatware spokojnie da radę.
Wszystko zależy od tego, które technologie znasz i jakie masz wymagania. Weź ten język, w którym potrafisz robić cuda. Jeśli potrzebujesz szybko postawić gotowe rozwiązanie, to zwróć uwagę na to, czy np. są dostępne przydatne biblioteki, które ułatwią i przyspieszą implementację. IMO jeśli już robić coś sensownego (nie stricte do nauki), to wybrać sensowną technologię, czyli coś dojrzałego i funkcjonalnego. Świeże, jeszcze niestabilne wynalazki bym sobie odpuścił, bo szkoda poświęcać czasu na coś o niepewnej przyszłości, co może być martwe za pół roku.
Sam programuję grę we Free Pascalu i gdyby to miała być gra sieciowa (a nie będzie), to serwerowy backend również napisałbym we Free Pascalu i miałoby to mnóstwo zalet. Serwer i klient w tym samym języku to pełna kompatybilność kodu, możliwość współdzielenia fragmentów źródeł itd. Zresztą, sam wszystko buduję w Lazarusie — silnik, grę, edytory zawartości, instalator, deinstalator, aktualizator itd. (dla sieciówki byłby jeszcze serwer i klient). Nie potrzebuję przebierać w językach i być modnym, skoro stary dobry Pascal daje mi dosłownie wszystko co jest mi potrzebne (plus wieloplatformowość).
3
furious programming napisał(a):
Nie. Rust nie byłby lepszy od C++, a C++ nie byłby lepszy od C, ani od Pascala, ani od C# czy Javy. Pytanie, które zadałeś w temacie wątku, to nie jest pytanie technologiczne, a filozoficzne — nie ma na nie odpowiedzi. Jeśli brać pod uwagę języki programowania ogólnego przeznaczenia, to nie ma takiego, w którym nie dałoby się napisać serwera dla jakiejkolwiek gry.
Backend do gry ma parę wymagań pozafunkcjonalnych jak wymagane niskie latency, które ciężko osiągnąć np. w takiej Javie. Pytanie jest technologiczne a twoja argumentacja jest błędna, bo tak szczerze mowiąc to jakiekolwiek pytanie o technologię można zredukować do "rób co chcesz".
Anatolijus napisał(a):
Zakładając, że tworzymy serwer do gry MMO gry z wczesnych lat 2000: Metin, Tabaluga, Tibia, Kabal.
Czy Rust jest do tego zadania lepszy?
Według mnie tak. Serwer do gry nie ma wymagań takich jak sama gra (silnik graficzny) i możesz go napisać w czym tam chcesz. Riot napisał serwer do Valoranta (taki klon csa) w Go, choć sama gra jest oparta o UE.
0
slsy napisał(a):
Backend do gry ma parę wymagań pozafunkcjonalnych jak wymagane niskie latency, które ciężko osiągnąć np. w takiej Javie.
Wyraźnie zaznaczyłem w swojej odpowiedzi, że technologia nie ma żadnego znaczenia, jeśli chodzi o mały, prosty projekt, o serwer, który nie ma obsługiwać dziesiątków tysięcy graczy jednocześnie. Dorzuciłbym do tego też projekty stricte edukacyjne, bo nic nie stoi na przeszkodzie, aby sobie na potrzeby nauki, taki serwer postawić w Javie czy Pythonie.
Pytanie jest technologiczne a twoja argumentacja jest błędna, bo tak szczerze mowiąc to jakiekolwiek pytanie o technologię można zredukować do "rób co chcesz".
No nie, nie jest to pytanie technologiczne, bo nie ma na nie jednoznacznej odpowiedzi. To że dotyczy technologii, wcale nie oznacza, że jest technologiczne. Niektórzy po prostu lubią poświęcać czas na takie filozoficzne dyskusje, które nigdy żadnych konkretnych odpowiedzi nie dadzą, za to są pożywką do wykłócania się i polaryzacji. Rust czy C++, PlayStation czy Xbox, Volkswagen czy Nissan itd. — strata czasu.
Rust nie jest lepszy od C++ ani vice versa, bo oba te języki są ogólnego przeznaczenia i pozwalają zaprogramować absolutnie cokolwiek. W dodatku ich wydajność znajduje się na z grubsza tej samej półce i są wystarczająco dojrzałe, więc nie ma żadnego znaczenia który język się wybierze. Istotne jest jedynie to, który zna się lepiej.
Znamienne jest to, że nazywasz moją opinię „błędną argumentacją”, a sam udzieliłeś dokładnie takiej samej odpowiedzi:
slsy napisał(a):
Anatolijus napisał(a):
Zakładając, że tworzymy serwer do gry MMO gry z wczesnych lat 2000: Metin, Tabaluga, Tibia, Kabal.
Czy Rust jest do tego zadania lepszy?Według mnie tak. Serwer do gry nie ma wymagań takich jak sama gra (silnik graficzny) i możesz go napisać w czym tam chcesz.
Dodatkowo uważasz, że Rust jest lepszy od C++ do tego celu, ale nie podajesz żadnych argumentów wyjaśniających dlaczego jest lepszy. Bo tak jak pisałem, tego typu dyskusje są jałowe, pozbawione sensu. Zamiast rozprawiać nad tym, który język wybrać, lepiej byłoby wziąć którykolwiek i zacząć ten serwer implementować.
1
furious programming napisał(a):
Wyraźnie zaznaczyłem w swojej odpowiedzi, że technologia nie ma żadnego znaczenia, jeśli chodzi o mały, prosty projekt, o serwer, który nie ma obsługiwać dziesiątków tysięcy graczy jednocześnie. Dorzuciłbym do tego też projekty stricte edukacyjne, bo nic nie stoi na przeszkodzie, aby sobie na potrzeby nauki, taki serwer postawić w Javie czy Pythonie.
Lepszy język to niekoniecznie język, który jest bardziej wydajny. Istnieje cała masa innych czynników wpływających na jakość kodu jak np. jak łatwo zaimplementować dany ficzer (co się głównie sprowadza bogactwa bibliotek) albo jak przyjemny jest proces rozwijania oprogramowania z perspektywy dewa (co można zmierzyć statystycznie, ale technicznie nie jest to wykonalne, bo nie zmusisz do szczerej opinii kilkaset niezależnych devów)
No nie, nie jest to pytanie technologiczne, bo nie ma na nie jednoznacznej odpowiedzi. To że dotyczy technologii, wcale nie oznacza, że jest technologiczne. Niektórzy po prostu lubią poświęcać czas na takie filozoficzne dyskusje, które nigdy żadnych konkretnych odpowiedzi nie dadzą, za to są pożywką do wykłócania się i polaryzacji. Rust czy C++, PlayStation czy Xbox, Volkswagen czy Nissan itd. — strata czasu.
IMO takie pytania mają sens, bo potrafią ukształtować własną opinię. Nie musisz się zgadzać ze wszystkimi argumentami, ale znajomość różnych opinii pozwala zrewidować swój światopogląd.
Rust nie jest lepszy od C++ ani vice versa, bo oba te języki są ogólnego przeznaczenia i pozwalają zaprogramować absolutnie cokolwiek. W dodatku ich wydajność znajduje się na z grubsza tej samej półce i są wystarczająco dojrzałe, więc nie ma żadnego znaczenia który język się wybierze. Istotne jest jedynie to, który zna się lepiej.
Wspomniany przez ciebie FreePascal też pozwala na zaprogramowanie czegokolwiek, ale nie chciałbym użyć tej technologii do napisania jakiegokolwiek serwera, bo;
- technologia po prostu nie jest hot w przypadku rozwiązań serwerowych, community jest małe
- brakuje gotowców. Sprawdziłem na szybko dwie sprawy tj. logowanie strukturalne i eksportowanie metryk prometheusa i nie znalazłem nic ciekawego.
Dodatkowo uważasz, że Rust jest lepszy od C++ do tego celu, ale nie podajesz żadnych argumentów wyjaśniających dlaczego jest lepszy.
Uznałem, że nie ma sensu dodawać wyjaśnienia, bo nie powiedziałbym nic nowego. Rust vs C++ to przeżarty temat i według mnie pisanie serwera do gry nie odbiega w żaden sposób od standardowego serwera webowego, których jest pełno w C++ jak i w Ruscie
1
slsy napisał(a):
IMO takie pytania mają sens, bo potrafią ukształtować własną opinię. Nie musisz się zgadzać ze wszystkimi argumentami, ale znajomość różnych opinii pozwala zrewidować swój światopogląd.
Technologii do wykonania projektu nie wybiera się na podstawie opinii, a konkretnych wymagań. W przeciwnym razie nikt nigdy by niczego nie wybrał, bo przerzucanie się różnymi opiniami nie miałoby końca.
Wspomniany przez ciebie FreePascal też pozwala na zaprogramowanie czegokolwiek, ale nie chciałbym użyć tej technologii do napisania jakiegokolwiek serwera, bo;
- technologia po prostu nie jest hot w przypadku rozwiązań serwerowych, community jest małe
I nie musi być hot w przypadku rozwiązań serwerowych, bo oprogramowanie serwerowe nie różni się praktycznie niczym od desktopowego, jeśli chodzi o stricte technologiczne niuanse. Jeśli chodzi o community, to wystarczy raptem kilka ogarniętych osób, w razie chęci podpytania o cokolwiek. Bardziej by się przydał kontakt z ludźmi znającymi nie jakiś język programowania, a architekturę i algorytmy używane w przypadku serwerów gier — sam język nie ma większego znaczenia.
- brakuje gotowców. Sprawdziłem na szybko dwie sprawy tj. logowanie strukturalne […]
Serio potrzebujesz gotowców, żeby wiedzieć jak logować dane do JSON-a czy XML-a? 
[…]i eksportowanie metryk prometheusa i nie znalazłem nic ciekawego.
Też na szybko sprawdziłem i jednak co nieco znalazłem:
- Free Pascal:
- Delphi:
Choć tak jak patrzę na źródła tego pierwszego, to żadna gotowa biblioteka nie jest do tego potrzebna. Ile tam jest kodu? 1000LoC? To do zaklepania raptem w jeden wieczór (albo w weekend, na spokojnie).
Uznałem, że nie ma sensu dodawać wyjaśnienia, bo nie powiedziałbym nic nowego.
Czyli jednak nie ma na czym ukształtować własnej opinii i zrewidować swojego światopoglądu. 
0
Z tych dwóch wymienionych przez autora PHP będzie lepszy do serwera.
Przykład pierwszy z brzegu: serwer do Minecraft PE
https://github.com/pmmp/PocketMine-MP
1
Wiem, że to trochę spam ale nie mogłem się powstrzymać bo temat "co lepsze" wprost wpisuje się w to czym dzisiaj siębawię.
Odpowiedzi na pytanie "Czy Rust jest lepszy od C++ do tworzenia serwerów gier?"
Po rozmowie z ekspertami AI na ten temat sądzi, że:
Po rozważeniu argumentów obu stron, wydaje się, że wybór między Rust a C++ do tworzenia serwerów gier zależy od wielu czynników, takich jak specyficzne wymagania projektu, doświadczenie i preferencje zespołu developerskiego, a także od priorytetów takich jak bezpieczeństwo pamięci, wydajność, czy dojrzałość ekosystemu.
Rust oferuje zaawansowane mechanizmy bezpieczeństwa pamięci i współbieżności, które mogą przyczynić się do tworzenia bardziej niezawodnego kodu, co jest ważne w serwerach gier. Rust rozwija się dynamicznie i oferuje nowoczesne narzędzia, które mogą ułatwić tworzenie stabilnego oprogramowania.
Z drugiej strony, C++ jest sprawdzony w boju, oferuje wyjątkową wydajność i kontrolę, a jego ekosystem jest bogaty w dojrzałe biblioteki i narzędzia, które zostały przetestowane na przestrzeni lat. Dla serwerów gier, które wymagają ekstremalnej wydajności i niskich opóźnień, C++ może być bardziej odpowiedni, zwłaszcza w środowiskach, gdzie każdy cykl procesora jest na wagę złota.
Ostatecznie, wybór między Rust a C++ powinien być dokonany po dokładnej analizie wymagań projektu i zasobów zespołu. Obie technologie mają swoje miejsce w przemyśle gier i mogą być odpowiednie w różnych kontekstach. W tym przypadku nie ma jednoznacznego zwycięzcy, ponieważ oba języki oferują unikalne zalety, które mogą być cenne w procesie tworzenia
W załączniku cały "wywiad":
Jest to nawiązanie do tematu: GPT API jako sędzia i strony. Apple czy PC + program
0
Dziękuję wszystkim za odpowiedzi. C++ rzeczywiście wydaje się lepszym wyborem w branży gier komputerowych. Może za jakiś czas to będzie zig albo języki takie jak odin.