Let me know once dart or go can run a wide ecosystem of libraries and middleware that apply to almost any situation. There's a reason people still use languages like C++, Python, and Java despite them being objectively bad in some respects. Without mainstream adoption you've got a chicken and the egg problem.
I think you're missing my point here. Let's say you're given a pytorch model. You can either run it with native python or grab the golang bindings that are used by 5 people, and if you get stuck there, god help you. You'll be hitting obscure bugs in no time.
Even if something officially supports multiple languages, the obscure ones will be usually get inferiorly implemented bindings just because they're not used as much and will consequently not be as tested and as patched as the main ones. It's unfortunate but that's life I guess.
> I think you're missing my point here. Let's say you're given a PyTorch model. You can either run it with native python or grab the golang bindings that are used by 5 people, and if you get stuck there, god help you. You'll be hitting obscure bugs in no time.
To use a Python-specific framework you're better off using Python. Well duh.
Pytorch, despite the name, is really a C++ library with well developed Python bindings. There's certainly nothing in principle about it that's Python specific.
PyTorch's C++ API is experimental and doesn't have feature parity. PyTorch is a Python lib that heavily uses C++ extensions, but I don't think it has ever been a C++ library.
That’s one thing I like about Nim. It can compile to C++ and so can directly wrap C++ code. While Nim’s ecosystem is small it’s easy enough to wrap most any C/C++ library. It’s great for OpenCV. Some folks have been updating direct PyTorch C++ api (1)!
