13 ms·

My gamedever wishlist for Rust

94 points by m0th87 11y ago

irishcoffee 11y ago
Is it intended for that page to render html tags as well as content (in a very unreadable form) if I have javascript disabled?
- untothebreach 11y ago
  It is a Discourse forum, I'm surprised you could see anything at all without javascript
  - steveklabnik 11y ago
    http://eviltrout.com/2013/06/19/adding-support-for-search-engines-to-your-javascript-applications.html http://eviltrout.com/2013/06/19/adding-support-for-search-en... is an old post, but as far as I know, is still basically correct.
amelius 11y ago
Shouldn't it be "gamedevver" instead? Anyway, on my personal wishlist: Allow customized pointers. For example, if I use a mmapped file that is mapped at a different base address every time it is opened, the pointers within that file are always relative to the base address. I'd like to use "special" pointers inside the mmapped file, that are aware of this. Also, I'd like to use standard data structures (associative arrays, lists, sets) inside the mmapped file, meaning that the solution should be generic.
- pjc50 11y ago
  That's a rather difficult sort of generic type to implement: it would have to include the base address in the type somehow.
  - JoeAltmaier 11y ago
    Construct ptrs with the base address? At that point, why not just use '+' and be done with it.
- masklinn 11y ago
  > Anyway, on my personal wishlist: Allow customized pointers. It's already there isn't it? Isn't a custom pointer just a stack struct implementing Deref (and possibly DerefMut)?
- doomrobo 11y ago
  Can't you use raw pointers and .offset()? You can put them in a struct that mutates itself for every method call so it keeps track of the mmap. You'd also probably have to make sure that it has exclusive access to the mmap so another thread won't invalidate its pointers.
- devit 11y ago
  I think this can be implemented on current Rust, although you will have to define specific array, list and sets for this situation. However, you would probably want a different implementation anyway due to the different performance characteristics of disk/SSD vs RAM.
mrspeaker 11y ago
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.
d9fb698e010974b 11y ago
Is rust as complicated as it seems to me? I know ML derived languages well so I'm not a stranger to functional programming. And I'm a pretty competent C programmer, but it seems like Rust is about as complicated as C++, which I find offputting.
- steveklabnik 11y ago
  It depends on how you define "complicated." For example, Rust and C++ both have "move semantics," but Rust's is "A move is a memcpy, which the optimizer may or may not elide" and C++'s is http://stackoverflow.com/a/3109981/24817 http://stackoverflow.com/a/3109981/24817 rvalue references and copy/move constructors and all sorts of other things. There are three major kinds of backgrounds that Rust programmers come from: functional, systems, scripting. The functional crowd instantly groks Rust's pattern matching, first-class functions, and expression-based-ness. But they miss some more complex, stronger type system features. The systems crowd instantly groks Rust's low-level features, but struggles sometimes with the compiler being so strict. The scripting crowd instantly groks our tooling, and the functional-ish things, but struggles with the low-level. So really, everyone has a different definition of what "complex" is, because it's based on what you're familiar with. Some people find map to be more complex than for, some people think the exact opposite. All generalizations are false.
  - saosebastiao 11y ago
    Heh, the three kinds of backgrounds sounds like the perfect description of what I've found in the Rust community (being of the functional variety myself). However, once I understood ownership and lifetimes, I felt like the whole world opened up. I'm still waiting for more ecosystem and community before I start to use it more seriously, but I'm chomping at the bit for that to happen.
  - infogulch 11y ago
    > All generalizations are false. I believe this sentence is a paradox.
    - 11y ago
rootlocus 11y ago
This article comes from a person who prefers copy+pasting to reusable macros: "The reason why I have 15 "max" in my code is because it takes less time to copy-paste max( 15 times than it is to write a macro and think about where I should put it in my code structure!" Am I the only one who sees a problem with that?
- kibwen 11y ago
  Setting aside for the moment that game developers may have a tendency for quick-and-dirty solutions, tomaka is well worth listening to. :) They're the author of glium (https://github.com/tomaka/glium https://github.com/tomaka/glium), which all my OpenGL-using friends perpetually rave about and which showcases how Rust can be used to provide safe abstractions over low-level APIs.
- TillE 11y ago
  Every programmer is lazy sometimes. Obviously the author doesn't "prefer" this, it's probably just a resistance to implementing a macro which they think should be present in the standard library. If you only need to do this two or three times in your code, I can see how you wouldn't bother refactoring it, but would include it in a list of annoyances.
- outworlder 11y ago
  Yes and no. If it's a single instance (even if repeated 15 times), then it could be a net win in complexity to just leave the 15 max there – they are more obvious. This is in contrast to writing and maintaining a macro that does a trivial function, just once.
  - rootlocus 11y ago
    That may be your personal opinion, but 15 'max(' on a single would not pass code review in any decently maintained project, especially when there is a cleaner, reusable alternative. Moreover, complaining that implementing such a macro is too cumbersome because it implies finding a place for it in your code structure certainly doesn't imply professionalism. Just step back a minute and imagine the fresh intern comes to you with this code and explanation. Would it fly? Or are you just finding excuses because he's the author of a well known library?
MichaelGG 11y ago
>No way to detect at compile-time whether we are in the main thread Which languages do that? Other than requiring all functions to require a "mainthread" reference (perhaps a zero-sized type that lacks the traits to be sent cross-thread) are there ways to achieve this in general?
- acconsta 11y ago
  And... how would that be possible at compile time?
  - MichaelGG 11y ago
    It's possible at compile time because you won't have the "MainThread" object available unless it's passed in to your other functions. And since you'll deny the traits for sending the object from the main thread to other threads, your methods can never be called. And if you want it to be optional, like "if mainthread", then just accept an Option of MainThread. In fact I see exactly this is proposed in the comments on the article: https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859/7 https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust...
    - acconsta 11y ago
      Oh OK, that's cool. I don't think many languages could enforce that.
douche 11y ago
I'm a little ignorant of Rust, so forgive me if this is something I should know. What is the state of bindings for OpenGL/DirectX? Without reasonable implementations of those, I'd struggle to see Rust as a realistic option for writing games.
- steveklabnik 11y ago
  Graphics aren't my strong suit, but Glium is an OpenGL binding so good that I've heard of people converting to Rust just to get access to it: https://medium.com/@tomaka/the-glium-library-5be149d87dc1 https://medium.com/@tomaka/the-glium-library-5be149d87dc1
s_tec 11y ago
The interesting thing is how small all these issues are. The Rust ecosystem has really matured a lot if it can now be used to write serious software like games with only minor issues such as these. That's a pretty remarkable feat for the Rust team to have accomplished.
grandmaster789 11y ago
About a year ago I took a look at rust, but I didn't particularily like it. It enforces a single approach to programming stuff (which sounds an awful lot like the golden hammer antipattern) and lacked essential tools - notably an IDE, an actual debugger and profiling tools. Also, for gamedev you'd pretty much need either directX or openGL bindings. And proper Windows support. I'm not sure where Rust stands on any of these things lately.
- kibwen 11y ago
  1. IDEs: Mozilla is investing into IDE support for Rust in the coming year, with the goal to have great support for two cross-platform IDEs. 2. Debugger: define "actual debugger", because Rust works great with gdb and lldb and, as far as I know, always has. 3. Profiling tools: the same tools you'd use for C/C++: perf, instruments, callgrind, cachegrind, gperftools, etc. 4. OpenGL bindings: among others, there's Glium (https://github.com/tomaka/glium https://github.com/tomaka/glium), which has made a Rust convert of many a graphics programmer.

94 points by m0th87 11y ago

Is it intended for that page to render html tags as well as content (in a very unreadable form) if I have javascript disabled?

untothebreach 11y ago
It is a Discourse forum, I'm surprised you could see anything at all without javascript
- steveklabnik 11y ago
  http://eviltrout.com/2013/06/19/adding-support-for-search-engines-to-your-javascript-applications.html http://eviltrout.com/2013/06/19/adding-support-for-search-en... is an old post, but as far as I know, is still basically correct.

amelius 11y ago

Shouldn't it be "gamedevver" instead? Anyway, on my personal wishlist: Allow customized pointers. For example, if I use a mmapped file that is mapped at a different base address every time it is opened, the pointers within that file are always relative to the base address. I'd like to use "special" pointers inside the mmapped file, that are aware of this. Also, I'd like to use standard data structures (associative arrays, lists, sets) inside the mmapped file, meaning that the solution should be generic.

pjc50 11y ago
That's a rather difficult sort of generic type to implement: it would have to include the base address in the type somehow.
- JoeAltmaier 11y ago
  Construct ptrs with the base address? At that point, why not just use '+' and be done with it.
masklinn 11y ago
> Anyway, on my personal wishlist: Allow customized pointers. It's already there isn't it? Isn't a custom pointer just a stack struct implementing Deref (and possibly DerefMut)?
doomrobo 11y ago
Can't you use raw pointers and .offset()? You can put them in a struct that mutates itself for every method call so it keeps track of the mmap. You'd also probably have to make sure that it has exclusive access to the mmap so another thread won't invalidate its pointers.
devit 11y ago
I think this can be implemented on current Rust, although you will have to define specific array, list and sets for this situation. However, you would probably want a different implementation anyway due to the different performance characteristics of disk/SSD vs RAM.

mrspeaker 11y ago

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.

d9fb698e010974b 11y ago

Is rust as complicated as it seems to me? I know ML derived languages well so I'm not a stranger to functional programming. And I'm a pretty competent C programmer, but it seems like Rust is about as complicated as C++, which I find offputting.

steveklabnik 11y ago
It depends on how you define "complicated." For example, Rust and C++ both have "move semantics," but Rust's is "A move is a memcpy, which the optimizer may or may not elide" and C++'s is http://stackoverflow.com/a/3109981/24817 http://stackoverflow.com/a/3109981/24817 rvalue references and copy/move constructors and all sorts of other things. There are three major kinds of backgrounds that Rust programmers come from: functional, systems, scripting. The functional crowd instantly groks Rust's pattern matching, first-class functions, and expression-based-ness. But they miss some more complex, stronger type system features. The systems crowd instantly groks Rust's low-level features, but struggles sometimes with the compiler being so strict. The scripting crowd instantly groks our tooling, and the functional-ish things, but struggles with the low-level. So really, everyone has a different definition of what "complex" is, because it's based on what you're familiar with. Some people find map to be more complex than for, some people think the exact opposite. All generalizations are false.
- saosebastiao 11y ago
  Heh, the three kinds of backgrounds sounds like the perfect description of what I've found in the Rust community (being of the functional variety myself). However, once I understood ownership and lifetimes, I felt like the whole world opened up. I'm still waiting for more ecosystem and community before I start to use it more seriously, but I'm chomping at the bit for that to happen.
- infogulch 11y ago
  > All generalizations are false. I believe this sentence is a paradox.
  - 11y ago

rootlocus 11y ago

This article comes from a person who prefers copy+pasting to reusable macros: "The reason why I have 15 "max" in my code is because it takes less time to copy-paste max( 15 times than it is to write a macro and think about where I should put it in my code structure!" Am I the only one who sees a problem with that?

kibwen 11y ago
Setting aside for the moment that game developers may have a tendency for quick-and-dirty solutions, tomaka is well worth listening to. :) They're the author of glium (https://github.com/tomaka/glium https://github.com/tomaka/glium), which all my OpenGL-using friends perpetually rave about and which showcases how Rust can be used to provide safe abstractions over low-level APIs.
TillE 11y ago
Every programmer is lazy sometimes. Obviously the author doesn't "prefer" this, it's probably just a resistance to implementing a macro which they think should be present in the standard library. If you only need to do this two or three times in your code, I can see how you wouldn't bother refactoring it, but would include it in a list of annoyances.
outworlder 11y ago
Yes and no. If it's a single instance (even if repeated 15 times), then it could be a net win in complexity to just leave the 15 max there – they are more obvious. This is in contrast to writing and maintaining a macro that does a trivial function, just once.
- rootlocus 11y ago
  That may be your personal opinion, but 15 'max(' on a single would not pass code review in any decently maintained project, especially when there is a cleaner, reusable alternative. Moreover, complaining that implementing such a macro is too cumbersome because it implies finding a place for it in your code structure certainly doesn't imply professionalism. Just step back a minute and imagine the fresh intern comes to you with this code and explanation. Would it fly? Or are you just finding excuses because he's the author of a well known library?

MichaelGG 11y ago

>No way to detect at compile-time whether we are in the main thread Which languages do that? Other than requiring all functions to require a "mainthread" reference (perhaps a zero-sized type that lacks the traits to be sent cross-thread) are there ways to achieve this in general?

acconsta 11y ago
And... how would that be possible at compile time?
- MichaelGG 11y ago
  It's possible at compile time because you won't have the "MainThread" object available unless it's passed in to your other functions. And since you'll deny the traits for sending the object from the main thread to other threads, your methods can never be called. And if you want it to be optional, like "if mainthread", then just accept an Option of MainThread. In fact I see exactly this is proposed in the comments on the article: https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859/7 https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust...
  - acconsta 11y ago
    Oh OK, that's cool. I don't think many languages could enforce that.

douche 11y ago

I'm a little ignorant of Rust, so forgive me if this is something I should know. What is the state of bindings for OpenGL/DirectX? Without reasonable implementations of those, I'd struggle to see Rust as a realistic option for writing games.

steveklabnik 11y ago
Graphics aren't my strong suit, but Glium is an OpenGL binding so good that I've heard of people converting to Rust just to get access to it: https://medium.com/@tomaka/the-glium-library-5be149d87dc1 https://medium.com/@tomaka/the-glium-library-5be149d87dc1

s_tec 11y ago

The interesting thing is how small all these issues are. The Rust ecosystem has really matured a lot if it can now be used to write serious software like games with only minor issues such as these. That's a pretty remarkable feat for the Rust team to have accomplished.

grandmaster789 11y ago

About a year ago I took a look at rust, but I didn't particularily like it. It enforces a single approach to programming stuff (which sounds an awful lot like the golden hammer antipattern) and lacked essential tools - notably an IDE, an actual debugger and profiling tools. Also, for gamedev you'd pretty much need either directX or openGL bindings. And proper Windows support. I'm not sure where Rust stands on any of these things lately.

kibwen 11y ago
1. IDEs: Mozilla is investing into IDE support for Rust in the coming year, with the goal to have great support for two cross-platform IDEs. 2. Debugger: define "actual debugger", because Rust works great with gdb and lldb and, as far as I know, always has. 3. Profiling tools: the same tools you'd use for C/C++: perf, instruments, callgrind, cachegrind, gperftools, etc. 4. OpenGL bindings: among others, there's Glium (https://github.com/tomaka/glium https://github.com/tomaka/glium), which has made a Rust convert of many a graphics programmer.