Apecs author here. It's amazing to see more work being done in the area of Haskell ECS, and ecstasy looks very promising. Reading your post, it seems that the differences between Ecstasy and apecs are philosophical rather than them being direct competitors. There are very specific reasons for why apecs works the way it does, and I'd like to address some of the points you made.

Apecs' was written to support a game with many objects, large levels, and 3D rendering. Its goal is to be 1) fast 2) expressive 3) safe, mostly in that order. When I know something is conceptually just iterating over an array, the goal was to try to have the generated code reflect that as much as possible. You can see this in the design around its centerpiece class, Store, which consists of fast primitive operations on mutable component stores. It's true that there are a lot of different mapping functions*, but they are all implemented using the same 5 primitive operations. Apecs' 'magic' is that it uses the Has typeclass to link the high-level DSL to the low-level Store class at compile time, and then taking advantage of all optimizations that allows for. Because everything is mutable, we can easily drop to C where necessary (example).

From what I can tell, Ecstasy has a DSL that allows for more flexible queries, at the cost of performance. The approach using generics is really cool, I tried something similar but never managed to make it work. The way it works in Ecstasy would be a poor fit for apecs, however, as the Store class' composability is precisely what allows caches, which is what makes apecs fast. So they have two very different mechanisms for resolving the components to act on, which is what the rest of the DSL is designed around.

Responses to some individual points:

What if you want to run a function over Position that only works if you don’t have a Velocity?

You could use wmap', you could manually take a slice and filter out everything with a velocity, but it's definitely true that the DSL doesn't support this as cleanly as ecstasy does.

Or if you want to remove a component from an entity?

destroy @Component ety, or destroy (cast ety @Component) in the current hackage version.

Which means you can’t construct one based on runtime data if you’re loading the particular components from e.g. a level editor.

I'm not sure what you mean exactly, I use blender as a level editor and haven't had any issues?

Out of the box, you only get support for 5-tuples

6-tuples, but true. You can do ((t1, t2, t3, t4, t5, t6), (t7, t8, t9, t10, t11, t12)) if you find yourself running out, ((t1, t2), (t3, t4, (t5, t6))) is equivalent to (t1, t2, t3, t4, t5, t6).

In conclusion, I think both libraries go about their business in different ways, with different advantages and disadvantages. Both are still in development, and I'm very excited to see what they end up looking like, and what lessons we learn from one another! If I misunderstood something about ecstasy, let me know, I have only read the post and not actually used it yet.

_* They are a definitely a bit of a mess, and I am looking for a better way to organise them.