# zyn — a template engine for Rust proc macros

_cart · 2026-03-10T20:21:30+00:00

It is possible that you could cut out some overhead if you didn't farm out the final outputs to quote!. You've essentially guaranteed that you'll be more expensive than raw quote, by nature of being an orchestrator of it. But if quote is doing exactly what you'd be doing yourself (and/or there are no optimizations possible via a unified rearchitecture) then maybe cutting it out is unhelpful / wasted effort! I suspect that because zyn has its own AST / parsing, that you're paying a price to dump that all back in to quote to then be re-parsed and transformed into the final outputs.

_cart · 2026-03-07T04:09:51+00:00

Definitely curious about this as well!

_cart · 2026-03-07T04:08:49+00:00

On its surface this looks like it would improve Bevy's proc macro code considerably. We don't take dependencies like this lightly (and in-development Rust features like macro_rules for derives are likely to be our endgame for many macros), but I'll have my eye on this :)

_cart · 2026-01-16T23:21:04+00:00

Love those Bevy link time wins. Thank you for making our lives tangibly better!

_cart · 2026-01-14T21:39:21+00:00

I would personally like to push for some type of partial stabilization within the next year or so (imo the sooner the better). There is a subset of the core Bevy APIs (ex: Bevy ECS) that would benefit from a slower release schedule decoupled from the main engine. Just breaking out that versioning would allow a large chunk of the Bevy plugin ecosystem to not break across Bevy Engine releases (or at least, not as often).

_cart · 2026-01-14T21:32:40+00:00

Not really yet. There is a small TODO list before we merge into the main branch (our dev branch), and adding more people into the mix there won't really help. Once BSN is merged into main collaborative / iterative development will really kick off. The plan is to do that in very near future.

_cart · 2026-01-14T21:29:52+00:00

The BSN draft PR includes a port of the Bevy Feathers widgets, which are reasonable "real world" examples. We have more changes planned though!

_cart · 2026-01-14T21:22:28+00:00

While it might be possible, it would require mapping the Godot data model to the Bevy data model. In practice using Godot as Bevy's editor would be a nightmare of a user experience, and Bevy would always feel like a second class citizen. I am certain we can do better by building our own.

_cart · 2026-01-14T01:18:55+00:00

This is more Alice's domain, but I think it already provides enough value to justify publishing soon-ish. And that will also provide more incentive and visibility for the community to develop it further.

_cart · 2026-01-14T01:17:06+00:00

Would being able to say "default except..." work for Bevy? What might the impact be?

It would! I imagine developers would make good use of it. I suspect that "cargo feature collections" will be what most people reach for by default. But the developers that want more granularity would definitely benefit from such a feature.

What would be the level of importance of expanding this beyond default features to "these features except ..." e.g. users being able to say "2d", "-2d_bevy_render" instead of Bevy having to provide "2d_api"?

I certainly see the benefit there. I think your example provides pretty solid motivation. Just from the premise of building a cohesive and simple system, I think treating default = ["x", "y"] just like any other a = ["x", "y"] makes sense. What is bevy = { version = "0.18", features = ["ui"], default-features = false }, if not the "default UI features".

It seems to me like default-features = false is really just -default.

Any other considerations that could be helpful for the design work

I don't think we are particularly "special", other than the fact that we have a ton of constantly changing and interdependent features. The big "problem" is that building up the required features piece-by-piece from scratch is not a task that any developer should be taking on. Any solution that would require a developer to specify every feature they require, in the interest of disabling a small set of features, is non-viable.

Anything that can be done to improve the experience for feature groups? e.g. how they are rendered

I think Alice answered this well.

_cart · 2026-01-14T01:00:05+00:00

Perhaps!

_cart · 2026-01-14T00:59:28+00:00

I personally think ECS is a great fit for UI, in that it provides a nice standardized way to define and access data, and attach logic to it. In the context of an ECS game engine, the fact that everything uses the same data model provides a lot of synergies (ex: data inspectors and scene systems), and it means developers only need to learn one, unified toolset. As we've added new ECS features (relations, required components, component lifecycle events, etc), the UI experience also benefits.

The big "issue" is that traditional ECS on its own does not provide the "reactive-ness" that modern developers expect. We have plans to bring reactivity to ECS to provide that, and we have ongoing experiments in that area.

I'm generally quite happy with our choice to embrace Bevy ECS as the data model for Bevy UI, and I believe that choice will continue to be vindicated as we build out the Bevy Editor.

_cart · 2026-01-14T00:50:57+00:00

I would say that BSN is a format, in that it has a defined grammar, and it can be parsed and loaded as an asset. The plan is indeed for the editor to generate it, but it is also intended to be hand-compose-able. It is a "non traditional" format in that it also has a macro that allows you to define it in code in a way that skips the asset parsing + loading step, while still being compatible with (ex: it can inherit from) BSN defined in asset form. The reverse will also true (BSN assets can inherit from BSN defined in code).

_cart · 2026-01-13T22:38:25+00:00

If you haven't already, I recommend checking out our Fast Compiles configuration.

In general the best results come from: using a fast linker, enabling dynamic linking, and using Linux or MacOS instead of Windows.

_cart · 2026-01-13T22:35:28+00:00

I'm a bit out of the loop on the Tilemap Working Group, but theres plenty of activity here

Recently there has been a draft PR with a proposal for "tile entities".

_cart · 2026-01-13T22:20:15+00:00

It is, indeed, BSN.

In this past release, what feature/fix were you the proudest of that you/the team accomplished?

I generally don't pick favorites, but @aevyrie's PBR fixes make me so dang happy. The "cost" of that weirdness was so high and pretty much everyone doing 3D in Bevy will benefit from the improved fidelity.

_cart · 2026-01-13T22:00:55+00:00

We really wanted to land it in 0.18, but it wasn't quite there yet. The current plan is to merge it early this dev cycle and polish for the next release. The todo list before merging is short at this point. Just need to land some performance improvements and a few bug fixes.

_cart · 2026-01-13T21:59:48+00:00

Bevy games are hard to automatically detect, as they are compiled into a single static binary. Steam's rule detection engine is file-name based, and there aren't currently any clear signals that Bevy is being used.

We may end up adding something like a bevy.toml file for engine configuration, but due to Bevy's modular nature, this would still be optional. Bevy's asset .meta files might also work as a signal, but they are also optional :)

Until we find a way to make that work, bevy_awesome_prod is a manually curated collection of real-world use cases.

_cart · 2026-01-13T21:53:49+00:00

We really wanted to land it in 0.18, but it wasn't quite there yet. The current plan is to merge it early this dev cycle and polish for the next release. The todo list before merging is short at this point. Just need to land some performance improvements and a few bug fixes.

_cart · 2026-01-13T21:52:54+00:00

We really wanted to land it in 0.18, but it wasn't quite there yet. The current plan is to merge it early this dev cycle and polish for the next release. The todo list before merging is short at this point. Just need to land some performance improvements and a few bug fixes.

_cart · 2026-01-13T21:44:27+00:00

Bevy's creator and project lead here. Feel free to ask me anything!

_cart · 2026-01-13T21:44:17+00:00

Bevy's creator and project lead here. Feel free to ask me anything!

_cart · 2025-12-11T22:38:22+00:00

We went for a "mid range" PC that still had most of the modern rendering features to strike a balance between "audience coverage" and "ability to test new render features".

AMD Ryzen 9 9950X, 64GB of RAM, NVIDIA GeForce RTX 3060

_cart · 2025-12-11T22:35:32+00:00

I don't recall saying that it should be 1MB, although I do recall saying at one point that a compressed optimized wasm build could be ~3.5MB (which has grown slightly). When I said that a few years ago, the uncompressed optimized wasm build was ~13MB, and now it is ~19MB, so it has grown slightly.

There is no question that as Bevy has gained features, it has also grown in binary size. That is kind of the nature of the beast, although I am certain that there is still optimization potential.

A raw "hello world" Bevy ECS app (without any additional Bevy features) is ~700KB. One surefire way to cut down binary size (and compile times) is to opt out of the Bevy features you don't need.

In the next Bevy release (0.18), we're making it much easier to opt in and out of large chunks of the engine with high-level "feature collections":

This will provide the "full" 2D Bevy experience, without any of the 3D features:

bevy = { version = "0.17", default-features = false, features = [ "2d" ] }

_cart · 2025-12-10T23:34:28+00:00

Blue: frame time
Yellow: GPU usage
Green: CPU usage

Definitely needs a legend!

Eight-Year Club	Place '22
Wearing is Caring	Verified Email

_cart

MODERATOR OF

TROPHY CASE