CurtHagenlocher commented on PR #4318: URL: https://github.com/apache/arrow-adbc/pull/4318#issuecomment-4483469874
> I'm curious, is there a use case for exporting .NET based drivers as shared libraries now? I think when we discussed before there was some concern that (like Go) the runtime may pose issues My sense is that the situation isn't intrinsically better than or worse than Go; in both cases, you have a component in the process with its own garbage collector and threads that don't interact with any other component -- including the main process. Someone who's okay with that and prefers to code in C# should have the opportunity to do so. It may also be that someone has an application which is stuck on older .NET and might like to use a driver compiled against a newer version -- because of performance, or because it has better support for HTTP/2, or because it depends on features not easily available on the older platform. AOT-compiling the driver lets them continue to use .NET while also leveraging the newer version. (Disclaimer: we have not yet done any performance tests to see how that part pans out, but our data-related applications in general tend to be about 30% faster on .NET 8 than on .NET 4.8.) I've also found -- at least on Windows -- that the debugging experience with an AOT-compiled .NET driver is notably better than it is with a Go driver. Finally, we have a Spark driver in the `HiveServer2` project, and wouldn't it be nice to ship a "native" driver based on that without doing any additional work? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
