My gamedever wishlist for Rust
users.rust-lang.org
users.rust-lang.org
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.
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.
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.
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.
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?
> forcing the user to do it 'the rust way' with boxed types
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.
It does seem strange, because:
- It has constructs which aren't present in C/C++ in the exact form, like traits or pattern matching (maybe it'd be easier if they were called templates and switch, but they're not quite the same thing, so a different name is good). There's a lot of Rust-specific jargon for things that aren't as complicated as they seem.
- Some constructs (e.g. enums and empty structs) look like C's, but again aren't quite the same.
- It has powerful generics and macros, so people who want to write really clever code, can.
To take a cue from the article: how do you write a generic max() function for an arbitrary number of arguments?
macro_rules! max {
($e: expr) => { $e };
($e: expr, $($rest: tt)*) => { max($e, max!($($rest)*)) }
}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.
I believe this sentence is a paradox.
It's close enough to true to be useful, but it's false when you treat the word "all" literally.
Like any type system, there are programs that are valid that cannot be expressed. This can frustrate people when they can see that their program is OK under the current configuration of it, but there's no easy way to represent that as a guarantee. (Same annoyance dynamic-languages users might feel about static typing.)
FWIW, I prefer ML-ish derived languages, am a mediocre C programmer, and Rust seemed easy enough to learn to the point I enjoyed using it.
And actually, borrowing isn't really complicated, just _different_.
And we weren't even using any templates!
Have you used languages with memory safety and no garbage collection before?
I think Rust has no more features than it needs to support its goals, and would be interested to know what features you would like removed.
The type system grows more powerful (and more complex) every time I revisit Rust, it seems.
I'm glad, as an increasingly powerful type system facilitates abstractions that were once painful, slow, unsafe, or impossible, but it is complex.
If you don't count lifetimes, Rust's type system isn't really more powerful or complex than, say, that of Swift. There are no dependent types here. There are no type families. There aren't even higher-kinded type parameters.
> The type system grows more powerful (and more complex) every time I revisit Rust, it seems.
What additions are you referring to?
> The type system grows more powerful (and more complex)
> every time I revisit Rust, it seems.
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.
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), which has made a Rust convert of many a graphics programmer.
"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?
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.
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?
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?
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...
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.
It's already there isn't it? Isn't a custom pointer just a stack struct implementing Deref (and possibly DerefMut)?
However, you would probably want a different implementation anyway due to the different performance characteristics of disk/SSD vs RAM.
Without reasonable implementations of those, I'd struggle to see Rust as a realistic option for writing games.