Also it's an alternative to C++ which is heavily used in gamedev. I personally believe Rust can shine in gamedev and every experiment is interesting.
To the end user? It doesn't matter one bit.
To your peers? It's interesting and educational to talk shop.
For C/C++/etc devs looking for something similar, BFD objcopy supports an "-I binary". It will emit an object file with _binary_objfile_start, _binary_objfile_end and _binary_objfile_size symbols.
But I have got to say that making it a language feature means that Rust is truly a batteries included language.
Having first-class language support for resource files looks fantastic.
Isn't that exactly what resource files give you or am I confusing something? Anything you add in resource files have are accessible as a static variable.
The problem with objcopy outside of unconvenient usage and naming is that naive objcopy will result in your binary having executable stack [1]. You can change a symbol name, but that's also unconvenient.
Check resulting binary with:
$ readelf -lW the_binary | grep GNU_STACK
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8
$
Also: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart#H...
[0] https://github.com/graphitemaster/incbin
[1] https://news.ycombinator.com/item?id=10816322#10818085
EDIT:
My shell script - bin2o.sh:
#!/bin/sh
set -e
filename="$1"
name=$(echo "$1" | sed "s/[^A-Za-z0-9]/_/g")
obj="$2"
echo \
" .section .rodata
.global ${name}
.type ${name}, @object
.global ${name}_size
${name}:
.incbin \"${filename}\"
1:
${name}_size:
.int 1b - ${name}
.section .note.GNU-stack,\"\",%progbits
" | gcc -x assembler -c - -o "$obj"E.g. bytes [0, 12, 99] would become "\x00\x0C\x63".
Almost every language has facilities to treat a string as a set of bytes, so this works basically everywhere. It's nice because you don't need any special language-level support for it.
let stuff = include_bytes!("my.file");> First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it requires plenty of per-project boilerplate and some additional shenanigans to disable it in production builds.
Lua is a great fit here and interops with Rust(and just about everything else) very well.
I admit I haven't bothered to research the current state of things, but how do more recent Lua bindings handle this? Does Lua 5.3 actually have a proper solution here, or do most bindings just wrap every single call with lua_pcall? I didn't do that in my bindings because I wanted to offer the full speed of Lua, but it's certainly an option.
Because Lua supports coroutines with a stack independent from the system C (Rust) stack, you often want to be careful mixing your stack-allocated objects. Lua 5.2 added lua_callk which allows yielding and resuming coroutines across the C API (that is, "yielding" a coroutine with a nested C or Rust function invocation).
Leveraging Lua's awesome coroutine support is one of the biggest reasons to use Lua, IMO.
Also, Lua can safely recover from out-of-memory (OOM) scenarios. On OOM it will throw an error that can be safely caught. Any Lua API which might internally allocate memory can throw this error, not just the lua_call family of routines. Quality libraries are expected to also handle OOM, which usually can be accomplished the same way as handling any other error: wrapping and anchoring temporaries, directly or indirectly, in the Lua VM.
Generally I've found that any time you're interacting with an FFI in Rust all bets are off and you need to be very aware of what your libraries do and what their runtime looks like(just in C/C++).
As an alternative, though, there are several Rust-based scripting languages that attempt to expose some of the power of the type system, etc., while being more amenable to dynamic loading, REPL, etc:
EDIT: And for those interested, you might want to check out Rust's recent inclusion in a AAA title: https://www.reddit.com/r/rust/comments/69s225/rust_makes_it_... :P
The Reddit comments are great.
Edit - Could you tell me why you downvoted me. This wasn't even the slightest bit argumentative, so I am not sure who I angered.
This internal Rust discussion focuses on it for more details: https://github.com/rust-lang/rust/issues/35968
This gist is that Apple is requiring bitcode, but isn't giving easy access to the LLVM version they use for their own tools. This means there's not a path forward to support bitcode generation from Rust that would align with Apple's requirements. This currently only effects iOS on Watch and TV, meaning you can easily target macOS and iPhone without issue, but I fear that the writing is on the wall.
That said, if you're dynamically interpreting code at runtime that was downloaded from the internet, you're only allowed to do that using JavaScriptKit. You cannot, for example, embed the Lua interpreter and then interpret code downloaded (but code in your app bundle is fine).
When I teach kids javascript I start with an etch-a-sketch. It's aided by a simple library to hide the mechanics of the HTML canvas element, context, etc. This allows it to be small enough that they can view it all in one go and build upon it.
print("Draw with the arrow keys");
var cx=320;
var cy=240;
function update() {
// the arrow keys have key codes 37,38,39 and 40
if (keyIsDown(38)) { cy-=1; }
if (keyIsDown(40)) { cy+=1; }
if (keyIsDown(37)) { cx-=1; }
if (keyIsDown(39)) { cx+=1; }
fillCircle(cx,cy,6);
}
run(update);
Otherwise rust-sdl2 is batteries included, there may be more ceremony than html5 canvas but it's easy to hide behind a simple interface. It has many simple examples.
But, like with C++, as long as the language doesn't come with a standard graphics library, I doubt the "official" books can really use graphics apps as a learning tool.
The MiniFB code does seem to be a good starting point for this sort of thing.
This sounds (sort of) encouraging. I was kind of expecting to learn it by putting in an hour here and there e.g. 2-4h/month. But I'm beginning to think that might not cut it...
Rust ... isn't. I love Rust, but you do need to put some dedicated time into learning it. We're hoping to improve this!
Python is actually a good case for this, where choices to make the language simpler and more uniform led to knock-on effects that ultimately lead to aspects of it being quite cumbersome (IMO, obviously). For example, how anonymous functions are specified, how cumbersome and limited that makes map and grep, and how that leads to list comprehensions, which for all but the simplest cases are much more complicated to read and write than a simple chain of maps and greps (assuming something better than lambda).
At the other end of the spectrum you have APL and its relatives. Lots of work to learn and become proficient in, but then you can read and write terse, performant and versatile programs with it quickly. Of course, the pool of people that can understand what you wrote is orders of magnitude smaller than with some of the easier to learn languages.
I understand the urge to make Rust as accessible as possible, and I applaud that effort. I just hope that Rust continues to walk the line of accessibility without compromise on the core ideals.
I'm not a rust dev (definitely interested in picking it up though), but heavily into clojure and learning haskell slowly on the side. I hear this complaint a lot from people who think that because they learnt C#, Go, Java and Swift in a weekend that all languages will be just as quick to stick in their heads.
I have not tried out Rust yet, but couldn't this be solved by wrapping the float in a single-field struct that checks for NaN on construction, implements Ord using PartialOrd and otherwise passes everything through to the ordinary float inside?
If this isn't possible, I'm definitely interested in the reasons.
The five platforms support is bloody impressive.
https://hackernoon.com/compiling-rust-to-webassembly-guide-4...
I was able to build the Rust version fast, and the SDL library is actually quite usable/stable for most things.
Flappy-Rust has particle effects, the beginnings of parallax-scrolling and basic collision detection. The rust code ended up being pretty reasonable however I'm quite sure there are a few places I could have simplified the sharing of assets.
If anyone is interested in this space check out my repo: https://github.com/deckarep/flappy-rust
Also please see the README.md where I talk a bit more in-depth about how the Rust version differs from the Go version.
Here is a .gif preview of the first iteration of the game: https://github.com/deckarep/flappy-rust/blob/master/flappy-r...
