In general, you shouldn't really need to pass in large input objects to oso - it operates over the application data.
What this means practically is either the data is processed through whatever data access layer you have (i.e. SQL, or an ORM). And there's more work we're doing here to make that experience seamless [1].
Or if you do have some large input data and you iterate over it in the policy, then the oso host library (the part in your app) will just iterate through it without sending the entire object back and forth.
> I presume that this is how you’d rather have users build more advanced policy than extending what seems to be a pretty lightweight language
Yep, that's the idea. I answered a similar question here [2]. You can call class + instance methods from Polar, so if there's anything you can't do you can add it that way. We have considered/are considering adding a standard library to provide common pieces out of the box, but it's not a limiting factor for using oso currently.
There are some side benefits though that a standard library would provide - like having a robust implementation of common operations in the Rust core.
[1]: https://docs.osohq.com/getting-started/list-filtering/index....
[2]: https://news.ycombinator.com/item?id=25443354