I hear Rust being slow to compile is their biggest gripe, but really - look at what you’re gaining for the slowdown!
Bevy gives you a very nice ECS to model your app but compilation can be slower than hand crafted code, while not using it gives you tonnes more code and the complexities that come with it, just to compile faster?
I don’t know what you mean by, “just to compile faster.” Compiling fast is critical to game development. There’s no formula for fun so you have to iterate extensively.
I also don’t think that other solutions are “tonnes more code.” Any code will explode in size if poorly written. The same is true for bevy.
OK, even though it does not seem like that game was very notable, will give you that one game. Rust has at least ~5-6 game engines though, so you will have to come up with 4-5 more.
It's a single data structure that contains your entire game though? The whole point of the ECS is that literally everything uses the same data; it's like if you modeled every object in the world with one struct that has an optional field for every piece of data that could exist. I'm not saying that necessarily makes the tradeoff worthwhile, but calling it a "single data structure" is a bit reductive.
It's a single data structure that contains your entire game though?
Are you asking?
but calling it a "single data structure" is a bit reductive.
No it isn't. It's like a tiny database. Depending on how someone implements it, it could use arrays, hash maps and b-trees. There is no universe where this means a binary that does nothing should be 50 megabytes.
I would say yes it’s like a tiny database but as well as all the other things your added. And I think that’s a good thing, because it does this at the type level!
I’m actually seeing if I can build a parser using bevy_ecs just because the way their state machine works, it looks like it would be fun
In this case systems are the S of ECS and contain all your game logic, acting upon the entities and components (E and C).
By system management I assume they mean the APIs bevy offers for scheduling and sequencing systems and events so your game logic remains modularized while still running in the correct order.
It seems like you're calling an entire game engine "ECS". I'm not sure what the point is here, the whole question was what justifies having a 50 MB hello world binary. It doesn't matter what you put into a data structure, the data structure itself shouldn't make 50 MB binaries.
No, they aren't calling the entire game engine "ECS". Entity-Component-System is an architecture that Bevy is structured around.
As I have previously stated, I wouldn't blame the data structures used behind Bevy just yet, given Rust's tendency for making bloated binaries. What is taking the most space in this 50MB binary? How does it scale with the complexity of the application?
I don't know where you are trying to go with this logic. You still haven't assured that the 50MB is actually related to data structures used behind by bevy, lest you are insunating that the data structures used by bevy are solely responsible for that size, which is not what the post claims.
How small is a hello world in C on Linux? The last time I checked a few years ago, it was either 9Mb or 13Mb (memory is fuzzy on this one but one of them was right).
Edit: wow I’m way off… it must have been the 90s when I checked this lol
Yeah, testing here with GCC 13.3.0 led to 16K. Perhaps, when you made your test, the compiler was statically linking some libs, which would explain the massive increase in size.
I know the thread. Your point is about whether Bevy's "data structure" is worth 50MB. I pressing on the fact that you haven't shown what this 50MB actually are.
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
> To be clear you think an ECS implementation is 50MB?
No.
> Do you think a spreadsheet the[sic] holds a function pointer is a kernel?
Do you think an entire engine, including its system scheduler, is a spreadsheet? If so, shouldn't be hard to apply the same argument to any kernel. Of course, it all relies on your definitions and sense of reductionism.
I think you're conflating other big features of a game engine with a way to store data. If you look at other ecs implementations they are data structures, they don't do "system scheduling" (is that different from regular scheduling?)
First of, Bevy isn't just an ECS implementation. It's a game engine designed around ECS. While the ECS part is its core, Bevy also provides rendering, resource management, physics, etc. One of its other tasks, a rather important one too, is system scheduling: once you register systems, Bevy is responsible for dispatching them each frame, at the appropriate time, while also avoid data races over global resources and components.
No one thought that or said that so I don't know what point you're trying to make.
If you go to the comments I replied it was someone saying bevy compiles slow and has excessive bloated binaries. Someone else replied that you get so much, like ecs. Then I said that ecs specifically is just a data structure and has no reason to bloat binaries to be 50MB for an empty program that does nothing.
You're replying about things no one was discussing.
Your whole thread is about nitpicking the phrase "Bevy gives you a nice ECS". You are the one who asserted that "ecs specifically is just a data structure" (it isn't, by most definitions [1] [2], except yours). I supposed you were referring exclusively to a simple and basic component storage implementation (which is a data storage), where as OP was probably referring to the whole ergonomics of writing programs in it, alongside all the other features. It seems to me that you're the one who missed the point.
Then, you used this reductionism to question whether the 50MB binary is worth it. And that's ignoring the fact that there are ways to cut it if you wish, as mentioned in the reddit thread. And then there's the issue of whether it will actually matter for a full game.
I will need citation on which link, and how it defines ECS as a data structure.
From [1]:
> Entity component system (ECS) is a software architectural pattern. An ECS consists of entities composed of data components, along with systems that operate on those components.
From [2]:
> ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. Data is often stored in cache-friendly ways which benefits performance.
Other ECS implementations might not, but Bevy does come with a system scheduler. You register systems (functions that operate over the components) and, through their parameters, Bevy's scheduler decides how to parallelize the registered systems while avoid data races.
Other ECS implementations might not, but Bevy does come with a system scheduler.
That's an ecs data structure and a system scheduler. If I make a vector and a system scheduler, vectors don't suddenly have system schedulers, they are two different things.
You register systems (functions that operate over the components)
ECS isn't a data structure tho, it's a pattern. You must be referring to the component storage. That's, at best, half the equation. You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?
> That's just adding a function pointer to field
Just as much as creating a new process, through the IP/PC field in the TCB. Don't know why you focused on that particular point, but sure.
Every implementation out there is a data structure. You keep talking about things that use it and then lump them together. That's just you.
You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?
No, the first person I replied to said that justified a 50MB program. A few other software components don't make any sense either. 50MB is not something you get to with 4 or 5 parts of a game engine. That's the stripped binary too, it was originally 700MB.
Don't know why you focused on that particular point, but sure.
You brought it up, I'm not even sure what point you are trying to make.
> Every implementation out there is a data structure.
Examples?
> 50MB is not something you get to with 4 or 5 parts of a game engine.
Depends on the engine's architecture, runtime, etc. Again, don't know if you are blaming the bloat on those components alone (it seems like you are), but you haven't established a direct link between said components and the bloat, thus, it's hard to properly reason about the tradeoffs given that we don't know how said bloat scales.
> That's the stripped binary too, it was originally 700MB.
Actually, no. Rust doesn't strip binaries on release by default. There's a reason there's a guide about minimizing Rust program sizes.
> You brought it up, I'm not even sure what point you were trying to make.
You are the one who nitpicked over "You register functions", ignoring the rest of the sentence.
Compile times are my biggest struggle, too. I'm vibecoding Bevy with parallel agents, and the bottleneck is often compiling the changes on my 7950X, not getting Codex to write them.
As far as file sizes go, I'd be really interested in how a Rust compiler that didn't monomorphize so much would perform. Right now you have to modify the source code to write polymorphic generic functions, but it doesn't strictly have to be that way (at least as far as I can see).
I wouldn't use Bevy for a web only game either, especially while it's still single threaded on WASM.
I built a few games in WASM and was shocked to see many of the bevy variants larger than the Unity versions.
There’s definitely a market for rust game engines but it seems that no one’s hit the sweet spot yet.