Many crates function with no_std+alloc, but a lot of useful crates do not. hecs is a no_std ECS library, but not a game engine per se. Additionally, Rhai looks promising for no_std scripting.
In theory, some sort of C standard library could be provided that runs on the Playdate. A version of the Rust standard library could then be built on top of it. Someone would need to do the porting work, but an executive decision was probably made to exclude the C standard library in the first place. Furthermore, the issue of the small main stack indicates that the Playdate is probably the wrong platform of "heavy" (or maybe even standard) libraries.
For what it is worth, it will be great if the Playdate encourages no_std Rust game development because that means more portable code that runs anywhere. My understanding is that the Playdate has a relatively beefy processor for the screen and RAM, leading to an interesting set of constraints- preprocess data so the stack does not overflow, but also use lean data structures do as much as possible at runtime so RAM does not run out. Code written for the Playdate may need optimizations that are useful but unnecessary on other platforms.
I suspect that the Playdate entry point (event handler) could live alongside a
main() function without hurting anything. It could probably also be conditionally removed. This leads to an architecture where the same update function is used on all platforms, with an adaptor for the right signature, if necessary.
I tried to do some Rust work on an NDA protected closed platform where stub functions were needed to generate symbols in the resulting binary. I wonder if it does not make sense to split the no_std desktop dynamic shared library "hackery" out into a separate file. For what it is worth, systems like the Playdate probably break a lot of the standard assumptions most programmers make about the execution environment- it is kind of embedded and kind of unix.
If the current alloc solution works, it is probably good enough. Just to throw something on the table, could it make sense for Rust to get the whole heap from the Playdate API so a custom allocation can be used?
In theory, it is possible to write 100% safe Rust code. In practice, unsafe Rust exists for a reason- hardware and external software may not conform to a conceptual model that cleanly maps to Rust's ownership rules. Is the callback problem more complicated than memory just being owned by caller. If so, is it really compatible with Rust's notions of "not your memory"?
My understanding is that SDL2 expects the programmer to write their own game loop. Obviously much of SDL2 does not make sense on Playdate. Multiple player controllers is one example.
@rob While skimming the crank source code, my first reaction was "I wish this was a makefile." If I want to write ASM and compile it into an object file, is there currently a way to link it to the binary using crank? My old lang_interop example uses rustc instead of cargo, so it looks like I never figured out a good solution. The Embedonomicon has a section .s files. Maybe the global_asm.s solution laid out in this post will just work? I can try to make a simple test project.