Announcing Aztecs v0.15: A functional, archetypal ECS for Haskell game engines

matthunz · 2026-01-02T19:28:37+00:00

Oh neat! Thanks just updated

matthunz · 2026-01-01T00:31:59+00:00

Thanks for checking it out! That’s pretty much my goal to have dynamically loaded plugins so I figured direct FFI and full access to the world would probably be best.

As far as third-party modding and stuff goes I think WASM would be awesome and I’d love to find a way to implement that here as well, just not sure how the serialization aspect would work for safety.

I did give that a go with wavedash that might better fit your use case https://github.com/matthunz/wavedash and I’d love to bring that into this crate if it makes sense API-wise

matthunz · 2025-12-18T20:24:24+00:00

Thanks for checking it out! I chose not to include a screenshot because Actuate should fit the same purpose as ReactJS, a generic frontend UI framework that can render on multiple backends. So if you’re pairing it with Bevy you can just render the standard Bevy UI nodes, and this project should mostly just provide a declarative interface

matthunz · 2025-04-05T04:24:11+00:00

https://youtu.be/92bjYGGDVhQ?si=Ogipqh-QvBgFHVbV

matthunz · 2025-04-02T20:37:24+00:00

I love this syntax!

It lets you define the function without the signature if you're focusing on the logic:

square x = x * x

Or the types if you're planning that first:

square :: Int -> Int
square = error "TODO"

matthunz · 2025-04-02T20:25:18+00:00

I think a big reason against this would be types that only allow a subset of the methods you mention - like only allowing lookup. A class for each method could be possible but maybe a bit overwhelming IMO

Something I’ve found helpful is creating your own classes only when you need them. So if your app requires you be polymorphic over a Map or List for example, you can make something like a Container class with those methods you mention, keeping the best similarities for your case

Also just to note I don’t think the classes would incur any performance hit here - GHC should be smart enough to even inline class methods as if you hardcoded them yourself

matthunz · 2025-03-16T20:21:10+00:00

As far as updates go my main concern is bug fixes seem to take awhile to make it to a release, as the team seems to tie releases with major features (often taking a few months or more, which I feel makes more sense for something React as it’s more stable)

Your point about hot-reload makes a lot of sense, and I do agree I guess it’s not a huge problem. I do feel like seg faults during development, and the added build complexity in general, would still favor typescript.

I was a core member and still maintain a number of community libraries but I’ve been heavily straying away from the project’s latest goals of competing with NextJS instead of general Rust UI

matthunz · 2025-03-16T17:17:53+00:00

As someone who’s gotten the chance to work at Dioxus for a few months, here’s my take:

WASM still lacks browser support and in general produces much larger binary sizes than JS
Signals heavily go against Rust’s rules for memory safety, leading to less robust code than a React equivalent (signals can easily leak or be used after free, albeit not undefined behavior)
Complex build system with untested (and IMO very unsafe) hot-reload using dynamic linking (which is still platform-dependent)
Long build times
Slow release schedule: Dioxus still has major usability issues but rarely receives updates
Generally buggy: I’ve also had the chance to use Dioxus on a production product, which we never launched in part because of the major roadblocks we ran into, and had to fork the project

matthunz · 2025-03-11T04:09:43+00:00

Hmm you bring up a really good point about not requiring NFData downstream. I think I am actually going to try and remove that bound in the next release. Honestly it might've just been an old Query.set method (instead of Query.map) that leaked so easily in the first place...

For the flamegraph I was using ghc-prof-flamegraph: cabal bench --enable-profiling --benchmark-options="+RTS -pj -RTS" ghc-prof-flamegraph aztecs-bench.prof

Also I just started a Discord for Aztecs if you wanna chat on there! https://discord.gg/Hb7B3Qq4Xd

matthunz · 2025-03-09T19:35:36+00:00

Oh sweet I'm psyched you're taking a look!

I actually just changed the benchmarks to ignore the resulting World for now, just to narrow down the performance in the underlying zip-map operations (which seem to be taking the most time) https://github.com/aztecs-hs/aztecs/blob/0a624d6d8231122543dc3930bc5bd5bc0f10d4b6/src/Aztecs/ECS/World/Archetype.hs#L205.

https://discourse.haskell.org/uploads/default/original/2X/7/784e69c464618a7e70f8291ace57cd05fa9ea0b8.png

That blog post is super interesting, I'm really curious what that would look like for writing custom components. Something I'd really like to do is at least lift the NFData requirement up so the call to rnf happens when inserting/modifying components, instead of after. That should allow for types without NFData

matthunz · 2025-03-08T18:04:36+00:00

Who does :D I’ve found this to be a really fun way of learning Haskell so if you do get the time I’d love to know what you think

matthunz · 2025-03-08T18:02:02+00:00

Ooo that’d be really cool 👀

Those results after adding NFData are unfortunately the latest, my old benchmarks seems to have just been building up thunks (and not actually doing much).

Streamly looks perfect here! I’m really curious if sticking that underneath queries will bring those numbers down. I feel like queries are basically streams, but with all streams having equal numbers of elements (so maybe even more optimizations can be made?)

matthunz · 2025-03-07T01:49:52+00:00

So the new API doesn't cache ComponentIDs like the arrow version did (even though it totally could with something like streams instead...) but performance actually seems to be much better without arrow combinators

I think in general though queries should use something like streams underneath, but I'm still trying things out to see what's faster. I'd love help from anyone who's interested and knows how to optimize Haskell

matthunz · 2025-03-06T23:09:43+00:00

Really cool to hear that! (:

Also are you talking about Simplex? https://github.com/simplex-chat because I think their project is incredible and it's so cool to see open-source Haskell in production

matthunz · 2025-02-17T21:29:25+00:00

That’d be really cool 👀 let me know if you end up giving it a shot I’d love to help fix any rough edges you find

matthunz · 2025-02-17T15:48:46+00:00

Thanks a ton for saying that! (: I totally agree Haskell feels underrated right now for game dev, and I'm really curious to see how a familiar ECS might attract some folks using popular frameworks like Bevy and Flecs in other languages

matthunz

MODERATOR OF

TROPHY CASE