
My gamedever wishlist for Rust - m0th87
https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859
======
mrspeaker
When Jonathan Blow started his programming language specifically for making
performant games
([https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1...](https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO)),
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.

~~~
Sleaker
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.

~~~
kibwen

      > 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)).

------
d9fb698e010974b
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.

~~~
anon4
C++ is the only language I've used, where a collection of completely
reasonable decisions led to the situation that "if (a == b)" worked fine, but
"if (b == a)" crashed the program due to a failed assertion.

And we weren't even using any templates!

~~~
tarpherder
I fail to see how reasonable decisions lead to the situation where a == b
works "fine" while b == a effectively crashes the program. Could you elaborate
what the reasonable decisions were?

~~~
flohofwoe
Yeah, this sounds more like a and b are different types but somebody messed up
overriding equality operators. I wouldn't blame the language for that.

------
grandmaster789
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
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.

------
rootlocus
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?

~~~
outworlder
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
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?

~~~
kibwen
You're a bit too over-focused on so trivial an issue. The game in question is
a lone developer's personal side project and isn't even open-sourced yet.
Don't jump to the conclusion that a codebase written for fun and developed in
isolation has any bearing on that developer's professional capabilities.

~~~
Ace17
Interestingly, I think it might have. Would you rather hire a "clean code"
lone developer, or a "messy" one?

~~~
kibwen
That's a loaded question, I deliberately wouldn't judge a candidate based on
their undisclosed personal projects. :P tomaka is a well-regarded author of
many high-quality libraries, such as
[https://github.com/tomaka/glium](https://github.com/tomaka/glium) . This is
the output I would use to gauge his applicability for any hypothetical
position.

------
MichaelGG
>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
And... how would that be possible at compile time?

~~~
MichaelGG
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...](https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859/7)

~~~
acconsta
Oh OK, that's cool. I don't think many languages could enforce that.

------
s_tec
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.

------
amelius
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
That's a rather difficult sort of generic type to implement: it would have to
include the base address in the type somehow.

~~~
JoeAltmaier
Construct ptrs with the base address? At that point, why not just use '+' and
be done with it.

------
irishcoffee
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
It is a Discourse forum, I'm surprised you could see anything at all without
javascript

~~~
steveklabnik
[http://eviltrout.com/2013/06/19/adding-support-for-search-
en...](http://eviltrout.com/2013/06/19/adding-support-for-search-engines-to-
your-javascript-applications.html) is an old post, but as far as I know, is
still basically correct.

------
douche
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
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)

