Repository navigation
Exploring production-quality Native AOT support — collaboration and potential sponsorship #354
horizonchasers
started this conversation in
Ideas
Replies: 1 comment
|
Hello Chris, First of all, it would be great to have Native AOT support. I think the first step is to get rid of trimming warnings. As you mentioned, there have been some experiments in the past, but I don't think they are up-to-date or relevant. For source-generators, I think PolyType will be helpful and is worth looking into. Funding will be useful for investigation but for now I have at least 6 PRs worth reviewing and I probably won't have time for it for the next 2-3 weeks. I hope to look into these in October and after that we could discuss in more details how we can move forward and what the obstacles are. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi Giorgi and contributors,
We’re exploring .NET Native AOT for our WoolInsights CLI, which uses DuckDB.NET for local data storage and querying. We’d like to understand whether there is interest in collaborating on maintained, production-quality AOT support upstream.
We’ve seen the earlier work in #202 and the Trimming branch and would appreciate your guidance on how best to build on it.
Our initial experiments suggest that useful workloads can run under Native AOT, but they do not establish compatibility across the full provider. We have encountered challenges around runtime generic construction and type mapping, particularly for nested types.
Our objective is to preserve DuckDB.NET’s functionality and existing behavior, including typed results, null handling, and nested values. We would be open to source generation or explicit type registration where AOT requires build-time knowledge, subject to your preferred API design.
We could contribute a minimal reproduction, a compatibility test matrix, and incremental patches. We would also be interested in discussing potential funding for a scoped investigation and implementation, including testing and ongoing maintenance.
Would this direction be useful to the project? Is there existing work we should coordinate with, and what would you consider an appropriate first milestone?
We can start by sharing a small reproducible test project with exact package versions, publish commands, and observed results. We also currently have access to extensive tokens for the next couple of months and could provide access to that and or throw Astra at this if you see this as a future path for the project. If not we can maintain our own fork with a simplified implementation that works for our specific needs.
All reactions