phobos2077 wrote:The scope of this library is nowhere near "tiny" IMO [...] I might still use this library as a whole because structure it provides is good, but it doesn't follow the single responsibility principle.
As far as I can tell (someone please correct me if I'm wrong), this library provides two major benefits. One is a convenience: you can have your entities list automatically sorted in different ways for different systems. The other is a potential optimization: Tiny will maintain a cache of relevant entities for each system, so that systems don't need to look at and reject irrelevant entities. I say potential
because of course there is some overhead associated with maintaining the cache, and you're not necessarily going to pick up more speed from caching than you'll lose from that overhead in every scenario (for example, when most of your systems affect most of your entities).
It might be a good idea to evaluate whether you need these particular benefits. For example, you might decide that you only ever need to sort your entities for drawing; in that case you can easily do it outside the ECS. Or you might determine that you can hit your baseline performance goals without the caching behavior, or that you actually get better performance from not caching. In that case you don't need a lot of the complexity associated with manually invalidating the cache and so on. You also might decide you don't really want another "world" and would prefer a more "immediate mode" style of applying your systems.
Lua's flexibility allows for pretty decent ECS-style designs without another layer of abstraction. Entities can be tables, components can be fields, and systems can be functions. Instead of filters, you can simply wrap the body of your system function with a conditional. If you don't need caching, there's no real need for separate filters. Of course you could still write them as separate functions if you want to. Instead of adding your entities and your systems to a world, you can just apply all your systems to all your entities inside a loop in your update or draw callback, immediate-mode style.
In other words, all you actually need to get the same structure
this library provides is a small amount of discipline and plain old Lua language constructs. I wouldn't use it for structure alone, I'd use it based on its own particular merits, like those mentioned above or any others I missed. I'm not trying to discourage anyone from using this library, just suggesting to weigh the added complexity against the benefits, and make sure it's actually doing something for your particular use case that a no-library solution wouldn't do.