How do their APIs compare?

Comparing the two projects' APIs is a bit apples-to-oranges since they're fundamentally different kinds of libraries (a general-purpose game engine vs. an NLP inference library), but here's how they differ concretely based on what's in the repo data:

bevyengine/bevy: ECS-centric, feature-gated modular API

Bevy's public API surface is built around composing an app from many optional crates/features. The top-level Cargo.toml exposes dozens of feature flags that map onto internal crates — e.g. bevy_animation, bevy_asset, bevy_render, bevy_ui, bevy_gizmos, bevy_picking [Cargo.toml:L281-L390]. Users opt into functionality by enabling features rather than importing separate packages, which is a very different shape from rust-bert's model-oriented API.

The core interaction pattern is systems and queries operating on components, not method calls on model objects. The migration guide excerpts show how the Query/iter_many API is evolving between versions — e.g. QueryManyIter::matched() and QueryManyUniqueIter::matched() are now required where iteration used to silently skip missing entities [_release-content/migration-guides/query_many_iter_results.md:L36-L75], and parallel iteration (par_iter_many) now returns Result per item that must be explicitly unwrapped with a let Ok(...) else { return } pattern [_release-content/migration-guides/query_many_iter_results.md:L106-L122]. This reflects a broader API trend in Bevy: making previously-silent failure modes explicit and typed, reinforced by the new BevyError::context/with_context ergonomic error-annotation API modeled after anyhow [_release-content/release-notes/bevy_error_context.md:L1-L40].

Bevy is also actively deprecating older "filtered resource" APIs (FilteredResources, FilteredResourcesMut, etc.) in favor of the more general QueryBuilder/QueryParamBuilder pattern, unifying resource access under the same query abstraction used for components [_release-content/migration-guides/deprecate_filtered_resources.md:L1-L40]. So Bevy's API philosophy is: one generalized query/system mechanism, extended via builders and traits, with frequent (documented) breaking changes roughly every 3 months per the README.

guillaume-be/rust-bert: task-oriented pipeline API

rust-bert's API is structured around ready-to-use pipeline structs, one per NLP task, each with a ::new(config) constructor and a task-specific method:

• QuestionAnsweringModel::new(...) + .predict(&[QaInput {...}], top_k, batch_size) [src/lib.rs:L141-L180]
• ConversationModel::new(...) + ConversationManager + .generate_responses(&mut manager) [src/lib.rs:L281-L320]
• TextGenerationModel::new(...) + .generate(&[prompts], prefix) [src/lib.rs:L316-L355]

Each pipeline call returns strongly-typed output structs (e.g. Answer { score, start, end, answer }, MaskedToken { text, id, score }) rather than generic tensors, so the "API surface" for a user is largely: pick a pipeline type, construct it (often via Default::default() config), and call one predict/generate method [src/lib.rs:L666-L705].

Underneath the pipelines, there's a lower-level model API exposed per architecture (BERT, GPT2, etc.), with resource constants like BertModelResources::BERT and BertConfigResources::BERT pairing a cache key with a Hugging Face download URL [src/models/bert/bert_model.rs:L39-L114], plus a shared config.rs utility for deserializing JSON configs [src/common/config.rs:L1-L17]. This lower tier is closer to a "build your own pipeline" API versus Bevy's system/query composition.

Key contrasts

• Composition model: Bevy composes behavior via ECS systems/queries over arbitrary component data, feature-flagged at compile time. rust-bert composes behavior by selecting a pre-built pipeline struct per task.
• Error handling philosophy: Bevy is moving toward explicit Result-returning iterators and a rich contextual error type (`BevyError