5 ms·

Because he claims that reducing the possibility for bug is a main concern I feel two languages, in his nicely written write-up, are left out: Rust -- low-level

by cies 11y ago

Because he claims that reducing the possibility for bug is a main concern I feel two languages, in his nicely written write-up, are left out: Rust -- low-level like C, fast like C, more modern than C, specific ways to reduce categories of bugs (borrow checker), promotes a more functional way for programming Haskell -- not as low-level as C, but pretty fast (best possible performance was not his main concern), many ways to reduce categories of bugs that can arise For game dev't you'll find both have maintained bindings to SDL2.

fsloth 11y ago
How is the Haskell stability nowadays? Simon Peyton Jones joked at one point that Haskell is not meant for production from the point of view that they are tinkering with it constantly. At some point the Haskell landscape looked like the GHC core and an endless desert of abandoned projects (which imply strongly it's not as good towards the librarys purpose as some other language).
- Kenji 11y ago
  I have worked with GHC for more than half a year and never encountered any compiler bugs or instabilities. Haskell is surprisingly solid. That being said, Haskell is not well suited for things like games. It's just not the right paradigm. Some people may disagree with me but the fact that most games (and also other programs) are not programmed in Haskell speaks for itself. Haskell is a fun and playful (and also difficult) language but I'd never start a large serious project in it again.
  - chii 11y ago
    > That being said, Haskell is not well suited for things like games. It's just not the right paradigm. is that really true? i feel like a game ought to fit into a functionally pure paradigm much better, because a game should really only depend on player input, and that can be modelled much easier as RenderIO (WorldState b -> PlayerInput a -> WorldState b) , but not having actually written any, this is just my assumption...
    - theseoafs 11y ago
      Well, obviously, a game state can change even if a player had no input. So you would have to have some concept of an empty player input on your model. (Also, modern games often require pulling from databases, remote servers... It's not just about transforming game states and rendering them any more.) The problem with games are that they have a lot of state, and a lot of loopy state. You end up in a place where you have a set of entities which are organized into a graph and you need to traverse this graph and destructively update some elements in a way that is visible immediately to all elements. You can do this in Haskell, but... It won't be easy. Definitely much tougher than doing it in C, and at the end of the day your game written in idiomatic Haskell will be more complicated and less performant than the C solution. Also, see: http://prog21.dadgum.com/3.html http://prog21.dadgum.com/3.html http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html
    - fsloth 11y ago
      Haskell seems to be really nice for data structure transforms. A game can be modeled as such. But, it appears to me Haskell is used in programs which do a few large transforms whereas games do hundreds to thousands transforms per second. Games usually want to be mutable and using immutable language probably means there will be considerable effort in fighting against language features. Ocaml and F# are more forgiving (some would say more practical) since they employ mutability as first class design element.
    - dottrap 11y ago
      John Carmack thinks there is potential in Haskell or other functional languages for game dev, so much so that he ported Wolfenstein 3D to Haskell as a summer project. I think he talks about in in this QuakeCon 2013 segment: https://www.youtube.com/watch?v=1PhArSujR_A https://www.youtube.com/watch?v=1PhArSujR_A
ksk 11y ago
Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I'd love to be proven wrong though...
- Keyframe 11y ago
  Well, TBH Rust hasn't been long enough around for it to even be in a cycle of a pro game or engine. It has been long enough for people to take a looksie around and experiment with it. Here are opinions of AAA developer on it: http://emoon.github.io/prodbg-web/rust_pres/index.html#/ http://emoon.github.io/prodbg-web/rust_pres/index.html#/
- cies 11y ago
  > Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Nope, not in Rust AFAIK. Indie games in Haskell are around. Off the top of my mind, Niki and the Robots is written in Haskell. > Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I was not so much recommending tech, just found these languages would fit nicely the list he assembled.
- pjmlp 11y ago
  Professional game studios only change when forced to do so. It was straight Assembly until console and OS SDK became mostly C. Then it was straigh C until the said SDKs became C++. Nowadays it will be C++ until they get forced to change again.
  - ksk 11y ago
    In your mind who is forcing them and why?
    - pjmlp 11y ago
      I said it on my comment already, OS and console vendors SDKs. Contrary to common belief among current generation of young developers, C compilers did not always generated good code. In the 8 and 16 bit days, proper games were done in Assembly. Any language you can think of, were the managed languages of the day. At the end of the 16bit days, C had widespread enough outside UNIX, that OS vendors started adopting it. So SDKs were then in C. So many were forced to use C, even if their code was mainly composed of C functions wrapping inline Assembly. Similarly, around the PS3 time, SDKs started to move to C++. So many didn't had other options than moving along to C++ compilers. But, just like the Assembly generation, many still use mainly C code compiled by a C++ compiler. So when an OS or console vendor says the language X is the platform's language, they either adopt it, even if only partially, or ignore the platform until they cannot avoid it anymore.

by cies 11y ago

fsloth 11y ago

How is the Haskell stability nowadays? Simon Peyton Jones joked at one point that Haskell is not meant for production from the point of view that they are tinkering with it constantly. At some point the Haskell landscape looked like the GHC core and an endless desert of abandoned projects (which imply strongly it's not as good towards the librarys purpose as some other language).

Kenji 11y ago
I have worked with GHC for more than half a year and never encountered any compiler bugs or instabilities. Haskell is surprisingly solid. That being said, Haskell is not well suited for things like games. It's just not the right paradigm. Some people may disagree with me but the fact that most games (and also other programs) are not programmed in Haskell speaks for itself. Haskell is a fun and playful (and also difficult) language but I'd never start a large serious project in it again.
- chii 11y ago
  > That being said, Haskell is not well suited for things like games. It's just not the right paradigm. is that really true? i feel like a game ought to fit into a functionally pure paradigm much better, because a game should really only depend on player input, and that can be modelled much easier as RenderIO (WorldState b -> PlayerInput a -> WorldState b) , but not having actually written any, this is just my assumption...
  - theseoafs 11y ago
    Well, obviously, a game state can change even if a player had no input. So you would have to have some concept of an empty player input on your model. (Also, modern games often require pulling from databases, remote servers... It's not just about transforming game states and rendering them any more.) The problem with games are that they have a lot of state, and a lot of loopy state. You end up in a place where you have a set of entities which are organized into a graph and you need to traverse this graph and destructively update some elements in a way that is visible immediately to all elements. You can do this in Haskell, but... It won't be easy. Definitely much tougher than doing it in C, and at the end of the day your game written in idiomatic Haskell will be more complicated and less performant than the C solution. Also, see: http://prog21.dadgum.com/3.html http://prog21.dadgum.com/3.html http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html
  - fsloth 11y ago
    Haskell seems to be really nice for data structure transforms. A game can be modeled as such. But, it appears to me Haskell is used in programs which do a few large transforms whereas games do hundreds to thousands transforms per second. Games usually want to be mutable and using immutable language probably means there will be considerable effort in fighting against language features. Ocaml and F# are more forgiving (some would say more practical) since they employ mutability as first class design element.
  - dottrap 11y ago
    John Carmack thinks there is potential in Haskell or other functional languages for game dev, so much so that he ported Wolfenstein 3D to Haskell as a summer project. I think he talks about in in this QuakeCon 2013 segment: https://www.youtube.com/watch?v=1PhArSujR_A https://www.youtube.com/watch?v=1PhArSujR_A

ksk 11y ago

Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I'd love to be proven wrong though...

Keyframe 11y ago
Well, TBH Rust hasn't been long enough around for it to even be in a cycle of a pro game or engine. It has been long enough for people to take a looksie around and experiment with it. Here are opinions of AAA developer on it: http://emoon.github.io/prodbg-web/rust_pres/index.html#/ http://emoon.github.io/prodbg-web/rust_pres/index.html#/
cies 11y ago
> Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Nope, not in Rust AFAIK. Indie games in Haskell are around. Off the top of my mind, Niki and the Robots is written in Haskell. > Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I was not so much recommending tech, just found these languages would fit nicely the list he assembled.
pjmlp 11y ago
Professional game studios only change when forced to do so. It was straight Assembly until console and OS SDK became mostly C. Then it was straigh C until the said SDKs became C++. Nowadays it will be C++ until they get forced to change again.
- ksk 11y ago
  In your mind who is forcing them and why?
  - pjmlp 11y ago
    I said it on my comment already, OS and console vendors SDKs. Contrary to common belief among current generation of young developers, C compilers did not always generated good code. In the 8 and 16 bit days, proper games were done in Assembly. Any language you can think of, were the managed languages of the day. At the end of the 16bit days, C had widespread enough outside UNIX, that OS vendors started adopting it. So SDKs were then in C. So many were forced to use C, even if their code was mainly composed of C functions wrapping inline Assembly. Similarly, around the PS3 time, SDKs started to move to C++. So many didn't had other options than moving along to C++ compilers. But, just like the Assembly generation, many still use mainly C code compiled by a C++ compiler. So when an OS or console vendor says the language X is the platform's language, they either adopt it, even if only partially, or ignore the platform until they cannot avoid it anymore.