It's not ideal, but when there isn't a good option isn't available in .NET it's usually available in Python/npm. Typically I'll use background jobs when calling out of process for added resiliency/replayability and observability.
IMHO, we don't lack good libraries in XY, we are lacking good interop. Going through REST or stdio is quite painful just to render PDF (or export spreadsheet, ...)
And even so, there are .NET bindings for a few of those libraries like PyTorch, OpenCV and ONNX Runtime.
Only that there are plenty of use cases coverage, moreso when willing to actually pay for tooling.
I never mentioned that .NET was on the world domination path for AI libraries.
If folks rather use an interpreted language, CPU vendors will appreciate it.
Here you're saying .NET has nearly everything, you just need to pay for it sometimes.
> And even so, there are .NET bindings for a few of those libraries like PyTorch, OpenCV and ONNX Runtime.
As apparently AI is no problem for .NET either since it has some bindings. So I really didn't need to use Python if I was prepared to pay for some tools as "There is hardly anything that isn't available in .NET" - misrepresent the situation much?
As if that does anything to help the different Python packages you need. Yeah you could rewrite every Python package built on top of it, or you know, shell out to a process or API.
Existing PyTorch, OpenCV and ONNX Runtime bindings doesn't meant there is a solution for every Python package out there.
However, I will state, since you're the one driving the discussion down this path, that there are many AI scenarios that are nicely taken care by .NET and Windows tooling like WindowsML, which work good enough for many Microsoft shops scenarios.
Not everything needs to be Python.
Yeah I know some things that aren't covered, like everything I've listed in my first comment that I'm currently shelling out to Python for.
> Existing PyTorch, OpenCV and ONNX Runtime bindings doesn't meant there is a solution for every Python package out there.
So why are you trying to use some scattered bindings to misrepresent .NET's AI capabilities? Your intent has been to say there's no need to use anything else since .NET basically has it all - to someone who needs to shell out to Python, because .NET didn't have what I needed.
> many AI scenarios that are nicely taken care by .NET and Windows tooling like WindowsML, which work good enough for many Microsoft shops scenarios.
So intead of shelling out to Python, I could've just.. replaced my inexpensive Linux servers and deploy to Window Servers and Azure??? Thanks for the advice, but I'll stick to the easiest solution that actually works.
> Not everything needs to be Python.
No, just everything I need to shell out to Python for, i.e. my entire point.
How do you handle deployment / packaging of multiple, different ecosystems?
Python and others have similar issues, with them having limitations as well