2 ms·

Personally, I'm betting on Haskell - for indie dev in particular where I want to manage huge amounts of complexity as an individual. This is partially because I

Personally, I'm betting on Haskell - for indie dev in particular where I want to manage huge amounts of complexity as an individual. This is partially because I've been programming Haskell professionally for 5+ years so I'm over the learning curve and well into the realm of efficiency gains. The GHC RTS is akin to the Lua layer and handles all the high-level logic. For storage and compute-intensive things, we can drop to lower-level primitives for performance and then easily hook into them in our scripting layer. I wouldn't be surprised if fleshing out this domain hints at future useful GHC extensions as well. I like Rust a lot, but I honestly think the ability to do highly-abstract programming is worth having to deal with a non-literal compilation pipeline. For gamedev at least. I honestly think it will be astounding what scale of game a single developer will be able to build in Haskell in 3-5 years once all the pioneering is out of the way. Programming a game the size Blasphemous could easily be managed by a single Haskeller I'm pretty sure - leaving resources to focus on art, sound, and storytelling. And that's an easy call - it'll be fun to see just how big and complicated of game logic we can make cheap thanks to good abstractions.

cylon13 6y ago
One of the problems with Haskell for game development is, because of the novelty of lazy evaluation, it's very difficult to learn what causes space leaks, and it's difficult to learn how to debug them. If you're already an expert in Haskell this might not seem like a big deal, but it certainly makes adoption a lot harder. Another related issue is the level of abstraction is so high that it makes it harder to be extremely optimal with memory usage and access, which is something game developers love doing, even sometimes when they don't strictly have to. I love programming in Haskell, but I'm highly suspect that it will ever be a widely used game programming language. It's very good at expressing computations in the abstract at the expense of being good at telling a physical computer exactly what to do. Game programmers tend to prefer languages that fall in the latter category in my experience.
- whateveracct 6y ago
  Yeah I agree it'll never be mainstream for gamedev. Haskell is not really built to have runaway adoption. It's a strength as much as it's a weakness. But I think it'll allow me to be insanely efficient as a gamedev. So I'm a Haskeller-turned-gamedev. Not a gamedev-turned-Haskeller. Haskell performance and memory usage is kind of like JVM programming. You need a mental model of how GHC and its RTS & GC operate. Having frame-oriented code honestly makes it easier to reason about. We Do need more learning materials about this stuff, but first we need more experience! But idt it's any different than using GC for gamedev. And manual memory management is well within Haskell's capabilities. Haskell profiling IME makes space leaks very obvious. That's a too-common paper cut, but once you get cut once you don't make the mistake again :)
ImprobableTruth 6y ago
I could see this with Idris, but Haskell's lazyness is just too unpredictable for anything you wouldn't use a scripting language for. People have been trying to get gamedev done in Haskell for like a decade with virtually nothing to show for. The LambdaCube 3D guys have been working on it for ~8 years and last I've seen they couldn't even get quake 3 graphics to render smoothly.I haven't seen any noticeable development in recent times, so I don't expect that to change in the next few years. The only thing I could realistically see happening anytime soon would be people using it as a scripting language for Godot, but I'm not convinced that working with the Godot abstractions won't rob you off most of the gains you make by using Haskell.
- whateveracct 6y ago
  I plan to have something to show for it :) Laziness really isn't an issue. Especially when writing FFI/low-level Haskell. I suspect the heavy-lifting will be written in a more performance-conscious style. And a lot of it will be deferring to industry-standard C libraries. And then you're right, idiomatic Haskell would have its place in the scripting layer. I honestly don't think there's anything inherent to Haskell that stops it from being used to make high-quality commercial video games. So my plan is to try to build those in Haskell and let the libraries and infrastructure fall out (as it always nicely does using Haskell in my experience.) Honestly, developing high-quality games is more bound by art & creativity than Haskell.

cylon13 6y ago

One of the problems with Haskell for game development is, because of the novelty of lazy evaluation, it's very difficult to learn what causes space leaks, and it's difficult to learn how to debug them. If you're already an expert in Haskell this might not seem like a big deal, but it certainly makes adoption a lot harder. Another related issue is the level of abstraction is so high that it makes it harder to be extremely optimal with memory usage and access, which is something game developers love doing, even sometimes when they don't strictly have to. I love programming in Haskell, but I'm highly suspect that it will ever be a widely used game programming language. It's very good at expressing computations in the abstract at the expense of being good at telling a physical computer exactly what to do. Game programmers tend to prefer languages that fall in the latter category in my experience.

whateveracct 6y ago
Yeah I agree it'll never be mainstream for gamedev. Haskell is not really built to have runaway adoption. It's a strength as much as it's a weakness. But I think it'll allow me to be insanely efficient as a gamedev. So I'm a Haskeller-turned-gamedev. Not a gamedev-turned-Haskeller. Haskell performance and memory usage is kind of like JVM programming. You need a mental model of how GHC and its RTS & GC operate. Having frame-oriented code honestly makes it easier to reason about. We Do need more learning materials about this stuff, but first we need more experience! But idt it's any different than using GC for gamedev. And manual memory management is well within Haskell's capabilities. Haskell profiling IME makes space leaks very obvious. That's a too-common paper cut, but once you get cut once you don't make the mistake again :)

ImprobableTruth 6y ago

I could see this with Idris, but Haskell's lazyness is just too unpredictable for anything you wouldn't use a scripting language for. People have been trying to get gamedev done in Haskell for like a decade with virtually nothing to show for. The LambdaCube 3D guys have been working on it for ~8 years and last I've seen they couldn't even get quake 3 graphics to render smoothly.I haven't seen any noticeable development in recent times, so I don't expect that to change in the next few years. The only thing I could realistically see happening anytime soon would be people using it as a scripting language for Godot, but I'm not convinced that working with the Godot abstractions won't rob you off most of the gains you make by using Haskell.

whateveracct 6y ago
I plan to have something to show for it :) Laziness really isn't an issue. Especially when writing FFI/low-level Haskell. I suspect the heavy-lifting will be written in a more performance-conscious style. And a lot of it will be deferring to industry-standard C libraries. And then you're right, idiomatic Haskell would have its place in the scripting layer. I honestly don't think there's anything inherent to Haskell that stops it from being used to make high-quality commercial video games. So my plan is to try to build those in Haskell and let the libraries and infrastructure fall out (as it always nicely does using Haskell in my experience.) Honestly, developing high-quality games is more bound by art & creativity than Haskell.