Exploring bevy-reflection
Intro
As I suspect many others do, I have a shared passion for programming on the one hand and video games on the other hand. This has led me to try to combine them a few times across my adult life to create some sort of hobbyist game. However, these attempts usually were unsuccessful due to one of two reasons:
- I used some popular tool such as Unreal or Unity which abstracted away a good bit of programming away and thus made developement less fun for me.
- I tried to build the game from the ground up which made development a lot slower and caused me to lose interest over time as progress halted.
Recently I started another attempt of finally developing a game after discovering the Bevy Game Engine. However my explorations of different aspects in the gaming sphere are not the topic of this post. Instead I want about a crate I discovered while exploring the Bevy’s ecosystem: bevy-reflect.
Reflection(Runtime and Compiletime), Metaprogramming and Serialization
When I initially encountered this bevy-reflect crate I must admit that I was a little startled. I was under the impression that reflection was not implemented in Rust as it solved issues that are usually reasons to want
Runtime vs Compiletime Reflection
To understand the in and outs of reflection one has to familiarize with the concepts of runtime and compiletime reflection. The bevy-reflection crate provides runtime reflection. Another example for the usage of runtime reflection I encountered in my earlier years of programming is Java where runtime reflection is used heavily in features dependency injection of popular libraries such as spring. On the other hand compiletime reflection is a popular feature of another language I really like: Zig. Comptime is one of Zigs main selling points and uses compiletime reflection for metaprogramming. Another programming language that will soon support compiletime reflection is C++ which will natively support reflection from C++26 onwards.