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.
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.