Would Hylo be a good fit for ECS game engines?

[kvfreedom]

I've been looking for a language that can handle both engine internals and gameplay in one stack. The current options all have trade-offs:

• C++ is fast, but memory-unsafe and low-productivity;
• Rust has safety and performance, but ownership and lifetimes are a high barrier, feels heavy for gameplay;
• Zig has no GC and great compile-time features, but memory is still manually managed;
• Mojo has great compute performance and Python compatibility, but has GC and is focused on AI/ML;
• C# is productive, but has GC, with separate value vs reference type semantics;
• MoonBit is great for full-stack cross-platform with strong Wasm performance, but has GC and requires manual stack/heap decisions;
• Verse has simple syntax, automatic transaction rollback, and native sandbox safety, but only works for upper-level game logic, can't touch engine internals.

I've been looking into Hylo lately, and I see potential for it to unify both engine internals and gameplay in a single language: default value semantics, automatic lifetime management, and compile-time guaranteed concurrency safety — parallel systems run without manual locks. It feels like a natural fit for ECS's "pure data components + parallel systems" model. I'm curious:
1. Does Hylo's language design actually play well with ECS architecture? Any fundamental conflicts or gotchas I'm missing?
2. Have the core devs thought about game development as a use case?

[tothambrus11]

Hi, welcome to the community! As long as you have a single thread, I think Hylo and value semantics will be great for this use case. In fact, Hylo's compiler is written in a somewhat similar fashion in Swift, where we store all AST nodes and types in a big list in Module, and just save indices everywhere. Whenever we want to access a node, we need access to the Module as a whole, and temporarily project out the node that we need:

// pseudo code:
var m = Module("a.hylo")
let node1Id: NodeID = ...

// access the node
func doSomethingWithNode(module: inout Module, n: NodeID) {
  module[n].prop1 += " visited"
} 

I would recommend exploring Swift, it likely covers your needs already (except Hylo will get rid of the copy-on-write types in favor of explicit copies and better control over performance).

The concurrent execution is more tricky, because as the previous example showed, we need exclusive access to module (unless we only use it immutably). Historically, we would add synchronization, e.g. with mutexes, but that destroys performance. The Hylo model naturally works well with architectures where a whole can be broken up into its independent parts (e.g. an array can be broken into its independent sub-slices), so that we can perform concurrent, safe in-place mutation on each part.

You can achieve a similar memory-management experience in Rust, but you may indeed face some complexities with explicit lifetimes, which Hylo can avoid thanks to subscripts (projections).

In a game, e.g. if you stored each list of components separately and the operations on separate types of components were completely independent, we could parallelize easily by firing a new task for each type of component.

The story becomes more complicated when you just have one big memory pool with shuffled data and you want to access that safely from multiple threads.

Could you share some more details about your ECS use case and how you wanted to parallelize things? I'd be happy to study the problem a bit more.

[kvfreedom]

Thanks for the explanation! It got me thinking specifically about ECS system scheduling.

Unity and Bevy each have their own solutions in this area: Unity's Job System automatically tracks component read/write dependencies to avoid data races, while Bevy infers access permissions from function parameters and builds a topological schedule at runtime. The catch is that both are implemented at the framework level, not as native language features.

What if the language's native parallelism primitives (like spawning tasks) could automatically infer read/write access to shared data across all parallel tasks, defer execution automatically when write conflicts are detected, and run conflict-free tasks in parallel — all handled natively by the language, not by the framework? This way, any ECS (or really any parallel code) would get this safe, automatic scheduling out of the box, without every engine having to reinvent the scheduling layer from scratch.

Do you think Hylo's compile-time memory model and isolation guarantees are capable of this? Automatically inferring data access across parallel tasks and resolving conflicts entirely at compile time, with zero runtime overhead?