5 ms·

As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating

As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.

celdon25 3y ago
Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.
- hi-v-rocknroll 3y ago
  Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case. * So fast, they really don't need HCR.
  - celdon25 3y ago
    I haven't tried it yet but I've wondered if Elixir might be a good choice for a game server with many concurrent players.
    - hi-v-rocknroll 3y ago
      Definitely and for chat. BEAM/HiPE VM allows native linking using NIFs so it's possible to integrate Erlang or Elixir with C-compatible projects for critical code sections, library interfacing, and perhaps even the majority of a performance-critical game engine as native code. Rustler also exists to write NIFs in Rust. Recall how VMware ESXi core tech was implemented mostly as Linux kernel modules and heavily-modified Linux to turn it inside-out as a type-1 hypervisor.
  - misswaterfairy 3y ago
    Nim does, when tied in with Unreal Engine 5. https://github.com/jmgomez/NimForUE https://github.com/jmgomez/NimForUE https://www.youtube.com/watch?v=Cdr4-cOsAWA https://www.youtube.com/watch?v=Cdr4-cOsAWA
  - nox101 3y ago
    HCR provides changing things while th game is running in it's current state. fast recompile does not. Start game, wait for engine to initialize, select level, wait for it to load, move player or camera to desired location. Now iterate on something at that location via HCR. If you have to recompile and restart the game you're not going to have fast iteration
- sam0x17 3y ago
  They have an interpreter mode now that is quite good and should be well-suited for these situations
- neonsunset 3y ago
  Gamedev industry already settled on almost perfect language for this task (C#) so there is little profit in trying to reinvent the wheel. And by perfect I mean not the way Unity uses it but the way pure C# engines use it.
- pizza234 3y ago
  Crystal doesn't support parallelism[1], which is a dealbreaker in this context (and for performance sensitive programs in general). [1]=production grade; additionally, it seems that no work has been done on it for years.
emseetech 3y ago
| Go because the iteration and compile times are very fast Safety is important and for certain applications, Rust is unrivaled. But for games, like web apps, where time to market and innovation can be just as if not more important than being free of runtime errors, Go is more suited to rapid development than Rust on compile times alone. Of course, the libraries and support for both aren't quite there yet, so at this point neither is well suited to game dev.
- hi-v-rocknroll 3y ago
  I agree. We almost have a paradox of choice nowadays because it's easier than ever to create new language platforms. Rust is something different because its thesis is safety and performance by default, more or less optimized for systems development primarily, but at the bargain of making dangerous things more complicated to accomplish somewhat intentionally. Unconventional languages are sometimes used as a conspicuous challenge to attract developers or to attempt to move some parts of an industry into new territory.
paulddraper 3y ago
Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate. Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game. --- EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.
- hi-v-rocknroll 3y ago
  That's true. Go ain't C4 (JVM), ORCA (Pony), HiPE (Erlang/OTP BEAM), or CLR (C#). The JVM and CLR runtimes have been beaten on for years at immense scale in server-side business settings. I wished Go supported embedded work (without a GC), had an alternative allocator a bit more like Erlang's, and had alternative implementations that transpiled to other languages, but it doesn't. Ultimately, I left when zillions of noobs poured in because it was seen as "easy" and started wasting my time rather than searching for answers themselves. If performance were such a huge concern, I don't see any valid resistance to Rust that completely lacks a GC and makes it easy to call C code other than "it's something different", "there's too much hype", or "I don't like it". Recent development tools like RustRover make is really damn easy to see whats a move value or a borrow, debug test cases, run clippy automatically, and check crates versions in Cargo.toml. Throw Copilot in there and let it generate mostly correct, repetitious code for you.
- philosopher1234 3y ago
  I’ve heard that go has very low latency gc, i haven’t heard of it having spikes
  - neonsunset 3y ago
    The problem with Go is its inadequate FFI, which is important for gamedev which tends to be FFI and syscall-heavy due to embedding another gamescript language and/or calling into underlying rendering back-end, sometimes interacting with input drivers directly, etc. Which is why C# has been chosen so often (it has performance not much worse than C++ (you can manually optimize to match it), zero or almost zero-cost FFI, and can also be embedded, albeit with effort). There are also ways to directly reduce GC frequency by writing less allocation-heavy code, without having to resort to writing your own drop-in GC implementation (which is supported but I haven't seen anyone use that new API just yet aside from a few toy examples, I suppose built-in GC is good enough).
ClimaxGravely 3y ago
Often in the past Lua has been used and in my experience it's been quite nice. It's very easy to bind, there's some nice editors out there and the performance is decent. There's some other game-specific scripting languages that have popped up (angelscript and wren come to mind but there's more). I've not used them in full production products though. Mostly just kicked the tires. Now that I think about it though, it's been almost 6 years since I've worked on an engine with lua support. Mainly because in the last few years I've been working with unity or unreal.
fuzztester 3y ago
>As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. I read on a recent HN thread that Crystal compilation is slow due to its type inference, IIRC.
KaiserPro 3y ago
> Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C# If you're starting from scratch, then maybe. Having had to crash learn games dev (ex VFX systems person) Unity + c# is just so nice to use. most of the easiness of python, but with proper strict typing. (which you can turn off, if you want) plus the wealth of documentation, its great. I imagine unreal is quite good in that regard too.

celdon25 3y ago

Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.

hi-v-rocknroll 3y ago
Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case. * So fast, they really don't need HCR.
- celdon25 3y ago
  I haven't tried it yet but I've wondered if Elixir might be a good choice for a game server with many concurrent players.
  - hi-v-rocknroll 3y ago
    Definitely and for chat. BEAM/HiPE VM allows native linking using NIFs so it's possible to integrate Erlang or Elixir with C-compatible projects for critical code sections, library interfacing, and perhaps even the majority of a performance-critical game engine as native code. Rustler also exists to write NIFs in Rust. Recall how VMware ESXi core tech was implemented mostly as Linux kernel modules and heavily-modified Linux to turn it inside-out as a type-1 hypervisor.
- misswaterfairy 3y ago
  Nim does, when tied in with Unreal Engine 5. https://github.com/jmgomez/NimForUE https://github.com/jmgomez/NimForUE https://www.youtube.com/watch?v=Cdr4-cOsAWA https://www.youtube.com/watch?v=Cdr4-cOsAWA
- nox101 3y ago
  HCR provides changing things while th game is running in it's current state. fast recompile does not. Start game, wait for engine to initialize, select level, wait for it to load, move player or camera to desired location. Now iterate on something at that location via HCR. If you have to recompile and restart the game you're not going to have fast iteration
sam0x17 3y ago
They have an interpreter mode now that is quite good and should be well-suited for these situations
neonsunset 3y ago
Gamedev industry already settled on almost perfect language for this task (C#) so there is little profit in trying to reinvent the wheel. And by perfect I mean not the way Unity uses it but the way pure C# engines use it.
pizza234 3y ago
Crystal doesn't support parallelism[1], which is a dealbreaker in this context (and for performance sensitive programs in general). [1]=production grade; additionally, it seems that no work has been done on it for years.

emseetech 3y ago

| Go because the iteration and compile times are very fast Safety is important and for certain applications, Rust is unrivaled. But for games, like web apps, where time to market and innovation can be just as if not more important than being free of runtime errors, Go is more suited to rapid development than Rust on compile times alone. Of course, the libraries and support for both aren't quite there yet, so at this point neither is well suited to game dev.

hi-v-rocknroll 3y ago
I agree. We almost have a paradox of choice nowadays because it's easier than ever to create new language platforms. Rust is something different because its thesis is safety and performance by default, more or less optimized for systems development primarily, but at the bargain of making dangerous things more complicated to accomplish somewhat intentionally. Unconventional languages are sometimes used as a conspicuous challenge to attract developers or to attempt to move some parts of an industry into new territory.

paulddraper 3y ago

Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate. Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game. --- EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.

hi-v-rocknroll 3y ago
That's true. Go ain't C4 (JVM), ORCA (Pony), HiPE (Erlang/OTP BEAM), or CLR (C#). The JVM and CLR runtimes have been beaten on for years at immense scale in server-side business settings. I wished Go supported embedded work (without a GC), had an alternative allocator a bit more like Erlang's, and had alternative implementations that transpiled to other languages, but it doesn't. Ultimately, I left when zillions of noobs poured in because it was seen as "easy" and started wasting my time rather than searching for answers themselves. If performance were such a huge concern, I don't see any valid resistance to Rust that completely lacks a GC and makes it easy to call C code other than "it's something different", "there's too much hype", or "I don't like it". Recent development tools like RustRover make is really damn easy to see whats a move value or a borrow, debug test cases, run clippy automatically, and check crates versions in Cargo.toml. Throw Copilot in there and let it generate mostly correct, repetitious code for you.
philosopher1234 3y ago
I’ve heard that go has very low latency gc, i haven’t heard of it having spikes
- neonsunset 3y ago
  The problem with Go is its inadequate FFI, which is important for gamedev which tends to be FFI and syscall-heavy due to embedding another gamescript language and/or calling into underlying rendering back-end, sometimes interacting with input drivers directly, etc. Which is why C# has been chosen so often (it has performance not much worse than C++ (you can manually optimize to match it), zero or almost zero-cost FFI, and can also be embedded, albeit with effort). There are also ways to directly reduce GC frequency by writing less allocation-heavy code, without having to resort to writing your own drop-in GC implementation (which is supported but I haven't seen anyone use that new API just yet aside from a few toy examples, I suppose built-in GC is good enough).

ClimaxGravely 3y ago

Often in the past Lua has been used and in my experience it's been quite nice. It's very easy to bind, there's some nice editors out there and the performance is decent. There's some other game-specific scripting languages that have popped up (angelscript and wren come to mind but there's more). I've not used them in full production products though. Mostly just kicked the tires. Now that I think about it though, it's been almost 6 years since I've worked on an engine with lua support. Mainly because in the last few years I've been working with unity or unreal.

fuzztester 3y ago

>As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. I read on a recent HN thread that Crystal compilation is slow due to its type inference, IIRC.

KaiserPro 3y ago

> Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C# If you're starting from scratch, then maybe. Having had to crash learn games dev (ex VFX systems person) Unity + c# is just so nice to use. most of the easiness of python, but with proper strict typing. (which you can turn off, if you want) plus the wealth of documentation, its great. I imagine unreal is quite good in that regard too.