4 ms·

When Jonathan Blow started his programming language specifically for making performant games (https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD

When Jonathan Blow started his programming language specifically for making performant games (https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1...), he talked about Rust a bit - it seemed like this was the closest language to what he wanted. I wonder if addressing these issues would make it more appealing to coders like him.

pcwalton 11y ago
My impression is that the issue he had with Rust is that it enforces memory safety. That isn't something that is likely to change (although I would be open to it if there were a lot of demand—yes, really!) The Rust community, me among them, seems pretty happy with enforced safety.
kibwen 11y ago
I believe that Blow values ease-of-prototyping more than safety, and sees all of Rust's safety guarantees as a distraction. Games have smaller maintenance windows than other applications, so caring about security is definitely a harder sell (especially if the game is non-networked, so the attack surface is already minimized). That said, the existence of Rust's thriving gamedev community means that not everyone shares this point of view, but I think there's still plenty of demand for a more specialized language for this niche.
- PopeOfNope 11y ago
  > I believe that Blow values ease-of-prototyping more than safety That's not entirely accurate. Based on his talks, he likes frictionless development over jumping through hoops that may or may not result in a safer application. Considering how many lines of code game programmers pump out on a daily basis, even small pain points can cause huge delays over a 2+ year dev cycle. Lines of code per day is a larger concern than safety for most games.
  - pcwalton 11y ago
    > Based on his talks, he likes frictionless development over jumping through hoops that may or may not result in a safer application. I think it's clear that using Rust will result in a safer application per unit of developer time compared to a non-memory-safe language. But I'm certainly willing to believe that not everyone cares about having a memory-safe application.
    - PopeOfNope 11y ago
      It's not clear to me. Give me some proof and I'll change my mind. A scientific study, a case study, a statistical analysis, anything other than theory. Haskell's strict typing system and theoretically correctness was supposed to lead to better code as well. I used xmonad for a few years. It crashes just as much as any other window manager.
      - pcwalton 11y ago
        The number of memory safety problems in memory-safe languages is much, much lower than in non-memory safe ones. Look at the classes of vulnerabilities in, say, Ruby programs and compare them to the number of memory safety-related security vulnerabilities in, for example, Firefox. I have actually analyzed this and memory-safety-related problems in Firefox are the majority of critical security vulnerabilities.
        PopeOfNope 11y ago
        The number of memory safety problems in memory-safe languages is much, much lower than in non-memory safe ones Citation? I have actually analyzed this and memory-safety-related problems in Firefox are the majority of critical security vulnerabilities. Cool. That means you can provide actual numbers and statistics... right?
Sleaker 11y ago
Doubtful, he has his own programming language explicitly because of Rust forcing the user to do it 'the rust way' with boxed types etc. he doesn't want to be pigeonholed. It's not going to appeal to people like him, and I think the OP is getting into some good reasons on why Rust probably wont ever be a good language for game programming.
- pcwalton 11y ago
  > I think the OP is getting into some good reasons on why Rust probably wont ever be a good language for game programming This is much stronger than the OP was claiming, or than I would claim. None of the issues raised are fundamental; note that very few people in the Rust community, gamedev or otherwise, are asking for less safety. I write things very similar to games on a daily basis in Rust, and I've found that the Rust way actually works very well.
- dkhenry 11y ago
  Nothing in that list makes me think Rust won't ever be a good language for game programming. It reads more like these are the current pain points that need to be addressed, and even with that list there are no real showstoppers there. Most are just nuances that they would like to see addressed.
- Manishearth 11y ago
  It's a wishlist, and the OP is a prominent member of the Rust community. Most of those things are minor pain points (he even mentions "None of these are critical.") that he hopes can be improved on.
- kibwen 11y ago
  > forcing the user to do it 'the rust way' with boxed types This is mistaken, everything in Rust is unboxed and on the stack by default. You have to go out of your way to box something (with, appropriately, `Box::new` (or the forthcoming `box` operator)).

pcwalton 11y ago

My impression is that the issue he had with Rust is that it enforces memory safety. That isn't something that is likely to change (although I would be open to it if there were a lot of demand—yes, really!) The Rust community, me among them, seems pretty happy with enforced safety.

kibwen 11y ago

I believe that Blow values ease-of-prototyping more than safety, and sees all of Rust's safety guarantees as a distraction. Games have smaller maintenance windows than other applications, so caring about security is definitely a harder sell (especially if the game is non-networked, so the attack surface is already minimized). That said, the existence of Rust's thriving gamedev community means that not everyone shares this point of view, but I think there's still plenty of demand for a more specialized language for this niche.

PopeOfNope 11y ago
> I believe that Blow values ease-of-prototyping more than safety That's not entirely accurate. Based on his talks, he likes frictionless development over jumping through hoops that may or may not result in a safer application. Considering how many lines of code game programmers pump out on a daily basis, even small pain points can cause huge delays over a 2+ year dev cycle. Lines of code per day is a larger concern than safety for most games.
- pcwalton 11y ago
  > Based on his talks, he likes frictionless development over jumping through hoops that may or may not result in a safer application. I think it's clear that using Rust will result in a safer application per unit of developer time compared to a non-memory-safe language. But I'm certainly willing to believe that not everyone cares about having a memory-safe application.
  - PopeOfNope 11y ago
    It's not clear to me. Give me some proof and I'll change my mind. A scientific study, a case study, a statistical analysis, anything other than theory. Haskell's strict typing system and theoretically correctness was supposed to lead to better code as well. I used xmonad for a few years. It crashes just as much as any other window manager.
    - pcwalton 11y ago
      The number of memory safety problems in memory-safe languages is much, much lower than in non-memory safe ones. Look at the classes of vulnerabilities in, say, Ruby programs and compare them to the number of memory safety-related security vulnerabilities in, for example, Firefox. I have actually analyzed this and memory-safety-related problems in Firefox are the majority of critical security vulnerabilities.
      - PopeOfNope 11y ago
        The number of memory safety problems in memory-safe languages is much, much lower than in non-memory safe ones Citation? I have actually analyzed this and memory-safety-related problems in Firefox are the majority of critical security vulnerabilities. Cool. That means you can provide actual numbers and statistics... right?

Sleaker 11y ago

Doubtful, he has his own programming language explicitly because of Rust forcing the user to do it 'the rust way' with boxed types etc. he doesn't want to be pigeonholed. It's not going to appeal to people like him, and I think the OP is getting into some good reasons on why Rust probably wont ever be a good language for game programming.

pcwalton 11y ago
> I think the OP is getting into some good reasons on why Rust probably wont ever be a good language for game programming This is much stronger than the OP was claiming, or than I would claim. None of the issues raised are fundamental; note that very few people in the Rust community, gamedev or otherwise, are asking for less safety. I write things very similar to games on a daily basis in Rust, and I've found that the Rust way actually works very well.
dkhenry 11y ago
Nothing in that list makes me think Rust won't ever be a good language for game programming. It reads more like these are the current pain points that need to be addressed, and even with that list there are no real showstoppers there. Most are just nuances that they would like to see addressed.
Manishearth 11y ago
It's a wishlist, and the OP is a prominent member of the Rust community. Most of those things are minor pain points (he even mentions "None of these are critical.") that he hopes can be improved on.
kibwen 11y ago
> forcing the user to do it 'the rust way' with boxed types This is mistaken, everything in Rust is unboxed and on the stack by default. You have to go out of your way to box something (with, appropriately, `Box::new` (or the forthcoming `box` operator)).