Sorry my benchmark test suite "fits" the units it reports to the duration. I totally get that its a bit confusing. I probably won't update them for this blog post because generating the graphs isn't fully automated yet (i manually theme the svgs to match the blog style).

But for future releases ill keep that in mind.

I'll be honest: the success of the initial release totally blew me away (both in a good way and a bad way). It took me a little over a month to adapt and develop ways to manage all of the threads (prs, community, dev work) without feeling burnt out.

Fortunately I've largely sorted out a workflow that works for my mental health, (i think) works for the community, and still leaves me plenty of time to do dev work. It helps that I can make this my full time job thanks to all of my awesome sponsors.

I am currently the only member of the Bevy organization that can merge prs, but a number of people have stepped up to review prs which helps a lot.

Eventually I do want to grant more people merge rights, but I'm holding off for as long as possible because I think having a single filter that ensures a cohesive vision is valuable.

Thanks! It is cached. It will only reload if the asset hasnt been loaded yet or was previously freed.

The developers of EVE Online had this same thought, about C++, so they used python as the gameplay scripting language. A few years later faced with unsolveable performance issues with large scale battles they had to resort to slowing down time by a factor of 4, during large scale battles.

Just a single anecdote but can be important to keep in mind. As well, some types of scripting languages can have their own productivity problems as projects get large. Lack of types making code hard to follow, bugs harder to track down, refactors riskier etc.

Rust isn't inherently slow to iterate, its just easy to write code that compiles slowly if you aren't careful. One of Bevy's primary focuses is to have fast iterative compile times. Changes to our examples can be recompiled in ~0.8-3 seconds (according to your hardware, os, and linker). We have a "fast compiles" configuration that works quite well.

First we do plan on exposing hooks to allow scripting languages to be plugged in to Bevy. We actually already have a pull request out for that.

However my default answer to the scripting question is that it is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games. I think a cohesive ecosystem is an incredibly important part of an engine's success. If half of Bevy devs use rust and the other half use C#, then compatibility and interop become a huge problem. The Rust language choice does set a high bar, but Bevy doesn't need to be all things to all people. Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.

In the near future 3rd party Bevy scripting plugins will start popping up, but I doubt I will ever officially endorse them.

I think you missed the part where we run the test 100,000 times per iteration. I promise its really fast :)

edit: but i do agree that the title is a bit unclear. ill fix that now

It should be able to run in a webview via WASM, but im less certain about the java communication part. If its a normal JS interface then you can probably do it.

Not yet, but it's one of our current focus areas: https://github.com/bevyengine/bevy/issues/254