Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bevy Foundation

bevyengine.org

Post reply on HN
Print view View original

31–40 of 82 posts

Re: The Bevy Foundation

#31

Post by noelwelsh »

ioasuncvinvaer wrote: post #27
noelwelsh wrote: post #26

I've been using Bevy recently so here are some thoughts on this: Firstly, the overall quality is high and seeing this attention being paid to the project's organization is another good sign. Documentation is not great. The Bevy book runs out of content very quickly. The "Cheat Book" has additional useful information: https://bevy-cheatbook.github.io/ . With these plus the examples I've been able to figure out everyth…

How does it lose type safety? I was under the impression that bevy's Query system is type safe.

ECS is basically a very simple relational database. There is no equivalent of foreign keys or other constraints between components. I can't say, for example, "every entity that has a location must also have an associated mesh". If I forget to add a component it's just a silent failure. Everything runs fine, just the expected result doesn't happen.

Re: The Bevy Foundation

#33

Post by suby »

noelwelsh wrote: post #31
ioasuncvinvaer wrote: post #27

Earlier quoted context omitted.

How does it lose type safety? I was under the impression that bevy's Query system is type safe.

ECS is basically a very simple relational database. There is no equivalent of foreign keys or other constraints between components. I can't say, for example, "every entity that has a location must also have an associated mesh". If I forget to add a component it's just a silent failure. Everything runs fine, just the expected result doesn't happen.

You can probably write runtime tests for this. Some system which queries for component Location, and then does an assert for each component that the associated entity also has a mesh.

Granted, this is annoying and not a particularly great solution, but it would serve to give you a reminder for when you forget. I don't mean to diminish from your overall point either, it's a valid and good one I think.

Re: The Bevy Foundation

#35

Post by zamalek »

diggan wrote: post #17
29athrowaway wrote: post #16

If you are trying Bevy for the first time, and it runs slow, put this on your Cargo.toml [profile.dev.package."*"] opt-level = 3

This + more is described if you follow the Quickstart, which if it's your first time, is probably the best place to get started quickly :) https://bevyengine.org/learn/quick-start/getting-started/set...

Using LLD/Mold is another pro-tip from Bevy that all projects - possibly RustC - should adopt.

Re: The Bevy Foundation

#38

Post by weinzierl »

lars_francke wrote: post #34
weinzierl wrote: post #32

I applaud the decision for a 501(c)(3) and not a 501(c)(6).

Can you explain the difference?

Not a lawyer and what I'm going to say is vastly oversimplified, but the gist is:

- A 501(c)(3) is for the benefit of the public

- A 501(c)(6) is for the common interests of their members

They both have advantages and disadvantages and are appropriate for certain scenarios.

Examples are:

- A 501(c)(3) Python, Scala, Zig, Mozilla, Apache, SFC, FSF

- A 501(c)(6) .NET, Rust, Eclipse

Re: The Bevy Foundation

#39

Post by noelwelsh »

suby wrote: post #33
noelwelsh wrote: post #31

Earlier quoted context omitted.

ECS is basically a very simple relational database. There is no equivalent of foreign keys or other constraints between components. I can't say, for example, "every entity that has a location must also have an associated mesh". If I forget to add a component it's just a silent failure. Everything runs fine, just the expected result doesn't happen.

You can probably write runtime tests for this. Some system which queries for component Location, and then does an assert for each component that the associated entity also has a mesh. Granted, this is annoying and not a particularly great solution, but it would serve to give you a reminder for when you forget. I don't mean to diminish from your overall point either, it's a valid and good one I think.

Yeah, runtime checks are not very desirable.

I have this vague thought that Rust needs a different kind of type system.

Standard type systems[0] basically rely on references between values[1]. I seem to read about numerous Rust systems that don't use references for various reasons. Usually the borrow checker gets in the way or they want a different memory layout[2]. This makes me think that what's needed is a type system that allows constraints to be expressed between values without requiring a reference between them. I don't know what this type system looks like, though.

[0]: Rust's type system is a fairly standard type system from an academic POV. The novelty is that it's the first language with traction to use a linear / affine type system, but these are relatively well studied in academia.

[1]: The theory is not formulated this way, but the representation they compile into is a bunch of references.

[2]: ECS, as I understand it, is not a reaction to Rust's type system but an architecture driven by memory layout, parallelism, and breaking-out-of-OO-hierarchy concerns. However the net result is the same.

Re: The Bevy Foundation

#40

Post by dcre »

lars_francke wrote: post #34
weinzierl wrote: post #32

I applaud the decision for a 501(c)(3) and not a 501(c)(6).

Can you explain the difference?

It sounds like 3 is for charities and 6 is for business organizations like a chamber of commerce. The former has tax-deductible donations and can’t participate in lobbying or political campaigns. It seems like 6 would have been a weird choice here.
Post reply on HN