Alice I Cecile

@stechlab-labels.bsky.social is really really good for blocking spam and bots

No #bevymergetrain today, sorry! Off sick: I got my annual flu and COVID vax, which is very good, but comes at a great and terrible cost (a day or two of enforced rest). Take care y'all; I'll see you next week.

This was the right thing to do. Supporting diversity, equity and inclusion is important for building a healthy open source community, and the open-ended clawback clause is deadly for any nonprofit.

Thanks PSF.

Rare Mevy (Macros for Bevy) Update! 🦜
🦆 added a shorter UI syntax
🪁 ..inspired by TailwindCSS
🐇 ..and LSP hovers still working

🐱 github.com/dekirisu/mev...

(for bevy v0.16 still, partially works for v0.17)
#rustlang #bevyengine #gamedev

YouTube video by Developer Voices Architecting Bevy - A Rust Game Engine (with Alice Cecile)

Having listened to this show, #Bevy seems like a project done right. I would love to be part of a project like this, if it is what @alice-i-cecile.bsky.social so ably describes. Not just because I love ECS, but because of how it's been organized. Beautiful.
youtu.be/PND2Wpy6U-E #rustlang

Steve is leaving us at Oxide 😭😭😭😭😭😭😭😭

But also going to go work at ERSC to help #jj-vcs take over the world, and I couldn't possibly be more excited about that

That's all for this week <3 A rare 100% merge rate! Like always, thanks so much for following along: it's a real pleasure to get to work with so many lovely contributors and community members each day.

Now go make stuff! I promise you can do it.

I'm going to merge this PR, but this bug fix really demonstrates the subjective nature of development. What is the "right" behavior here? How should these features interact? Should we expose a toggle, or is that just overhead and complexity that no one really cares about?

There's no right answers!

Fix `DespawnOn` not upholding invariants on entities with default filters by janhohenheim · Pull Request #21616 · bevyengine/bevy Objective Fixes DespawnOnEnter/DespawnOnExit no longer working on Observers #21579 Fixes DespawnOnExitState ignores disabled entities. #20167 Solution Allow at least the engine-internal default ...

6. github.com/bevyengine/b...

A contentious bug fix: allowing our various "state-scoped entities" mechanisms to operate on ordinarily hidden entities.

I feel quite strongly that this is the right fix: users adding these components to disabled entities expect that they should get cleaned up!

Move `tick.rs` into `change_detection` module by JaySpruce · Pull Request #21613 · bevyengine/bevy Follow-up to #21604. Tick and friends should be in the change_detection module, not component.

5. github.com/bevyengine/b...

A simple relatively uncontroversial code organization PR, moving some of our change detection-related types into our change_detection module. Great, merging! This was preceded by a PR to split the 2k LOC module into multiple files, making it much easier to navigate 🎉

I'm personally really keen on the tech-debt focused work in this area because it makes schedule introspection easier, allowing folks (probably me 😅) to write tools to understand and visualize the order and timing of their systems.

This is a key debugging tool, and cleanup makes it easier to write.

Move toposorting onto `DiGraph` directly, and cleanup error handling by ItsDoot · Pull Request #21608 · bevyengine/bevy Objective Part of Extensible Schedule Graphs #20115 Since Better ScheduleBuildError introspection and handling #20256, ScheduleGraph::topsort_graph no longer uses self, so let&#39;s put it directl...

4. github.com/bevyengine/b...

Another round of incremental cleanup to our scheduling code. This work is all towards a goal of supporting sophisticated system scheduling strategies. It may be a mouthful, but it's a reasonable thing to want! Reasonable enough and well-scoped PR: happy to merge this.

API for traversing `Relationship`s and `RelationshipTarget`s in dynamic contexts by eugineerd · Pull Request #21601 · bevyengine/bevy Objective Currently there is no way to traverse relationships in type-erased contexts or to define dynamic relationship components, which is a hole in the current relationships api. Solution Introd...

3. github.com/bevyengine/b...

One of Bevy's great Rust crimes is that it allows you to store, represent and work with data that while "typed", does not correspond to a Rust type. We forgot to add support for working with dynamically typed relationships: this PR fixes that oversight! LGTM; merging.

If users are writing out a type once per project, you really don't need to skimp on characters: choose clear names.

Abbreviations are particularly brutal for folks with limited domain expertise or weak English language skills. They take longer to process, and cannot be looked up in a dictionary!

Update `PanCam` and `FreeCam` to use full term `Camera` by syszery · Pull Request #21592 · bevyengine/bevy Objective This PR fixes #21569, which proposes renaming the newly introduced camera controller modules FreeCam and PanCam to use the full term Camera. Solution Renamed the PanCam controller, PanCa...

2. github.com/bevyengine/b...

A bikeshedding-centric PR: renaming `PanCam` to `PanCameraController`. This is an example of a broader policy that we have in Bevy: prefer clear, explicit names unless the API is very high traffic. We have agreement and related code is cleaned up, so it's merge time.

This docs PR is the sort of PR that makes me really grateful for our triage-by-controversy system: uncontroversially good changes like this "bubble up", getting checked and refined by the community and smoothly merged in (like I am now!).

Bad docs waste so much time: merge fixes for them fast!

1. github.com/bevyengine/b...

One of the many bits of game dev arcana is the truly spectacular number of coordinate systems and the conversions between them. In this case, we're converting from NDC (normalized device coordinates, of the camera's viewport) and world space, and the docs needed work.

Hi #bevy! It's time for another #bevymergetrain, as I go over the community-approved PRs stuck in our backlog <3 There's only 6 today, so grab a nice warm drink and follow along as I discuss #rust, #gamedev and the realities of #opensource project management.

changing rustfmt is politically difficult, because any changes you make is gonna piss someone off

it doesn't surprise me that maintenance has been slow and hard

OK, the way Clippy told me to replace cos(pi / 4) with the FRAC_1_SQRT_2 constant is wild. Clippy is becoming self-aware.

the thing is, rust can have really fast compile times, but the pervasive use of macros and build scripts obscures that fact. impure proc macros and build scripts are the free parking of the rust ecosystem: benefiting the few at the cost of many

Look, it’s really straightforward to get a publisher as a new name indie in 2025. Simply do 95% of the work making and marketing your game, and if your metrics are trending towards almost certain success, a publisher will swoop in to promise the remaining 5%, deliver 3%, and collect 75%

Avian is getting pretty big nowadays! To mark the start of a new release cycle, I spent some time improving our processes moving forward.

Notably, Avian now stores migration guides in-repo, similar to Bevy:
github.com/avianphysics...

Cinnog is what I use for This Week in Bevy.

thisweekinbevy.com

How we organized the Rust Clippy feature freeze https://lobste.rs/s/emudbc #rust #historical

It is important for people who are expected to obey a law to be able to easily find, read and understand it, for free.

One of the best things you can do for yourself is be friends with people who know a hell of a lot more about certain stuff than you do

Thank you for the kind words and the thoughtful response. I'm deeply sympathetic to your viewpoint, and some days I certainly feel like Rust is creaking under its own weight. Why does your typical backend web service need all this complexity with borrows and lifetimes and manual memory management? But allow me to present the other side of the argument. My background is in systems-level developer tools, and Rust has a combination of things that no other programming environment has: * & and &mut, which enforce a rigorous separation between mutable and immutable state. I think this is the single most important feature of Rust, and the closest analog to this in other environments is purely functional languages like Haskell * enums with data + exhaustive pattern matching; the latter is something even Haskell lacks * high-level idiomatic code that performs like low-level code (e.g. iterators): Rust achieves this through an extraordinary combination of monomorphizing and inlining * working in memory-constrained environments: tracing GC tends to have significant memory overhead, and I've worked in server environments where a big limiting factor was the amount of DRAM being produced globally * good polymorphism: I think OOP is a suboptimal paradigm that breaks under day-to-day development stress. I've written about it at https://news.ycombinator.com/item?id=42512629 * fast startup times: this is a requirement for command-line tools people use hundreds of times a day—I spent many years working on Mercurial where Python's slow startup time was a very common complaint * first-class support for using native OS calls directly; many higher-level languages like Java abstract away the details, so things like signal handling are hard to hook into * first-class Windows support: again, non-negotiable for many developer tools, since the plurality of developers are on Windows (cont)

* and last but not least, a great dependency ecosystem, which ties into all of the above points: & and &mut mean that some transitive dependency three levels down won't suddenly alter the list you pass in, idiomatic performance means that perf regressions are rare, first-class Windows support means most dependencies just work on Windows, and so on Is it possible to have an application-level/GCd/managed language that meets most or all of these requirements? Certainly. Does such an application-level language exist today? No, and there's nothing on the horizon either (Haskell has its heart in the right place, but is missing many of the more practical features here). Rust isn't a great application-level language, but it's the best application-level language. And given how high the barrier tends to be for a new language to reach adoption, I'll probably be retired long before something like that shows up. And yeah, async really is quite confusing in so many ways, and it's really unfortunate that this situation has seen no improvements in so many years. And yet, through its characteristics combined with the other things listed here, it enables developers to solve real problems that are completely infeasible in any other language. So I keep trying to make Rust better :)

Why I like and keep working on Rust

IF ANYONE BUILDSIT, EVERYONE DIES WHY SUPERHUMAN AI WOULD KILLUS ALL ELIEZER YUDKOWSKY & NATE SOARES

Next up on my reading list.

…I am already regretting this choice.

I saw _the_ teapot in Dublin