I know what bindings are. A front-end to C++ for pytorch was only released from 1.0, literally 2 years later. The relationship is very clear here. There was no native C++ library. It was an afterthought. Even in instances where there was, like Tensorflow, functionally it was still an afterthought.
replyThey are python libraries because people reached for those languages so they could continue work in python. They are there to serve python and nothing else. It's the same with Rust. It's by no means a C++ thing.
EDIT: Not saying this is always the case. Qt>Pyside is an example where it's both technically and functionally bindings, but the vast majority of the time they are serving python. Some don't even have a native library to speak of.
For Python libraries they would be written in Python, eventually ctypes for syscalls.
replyOtherwise they are bindings to native libraries.
We can keep discussing in circles.
>For Python libraries they would be written in Python, eventually ctypes for syscalls.
replySo if you can't call/use the 'library' from the 'native' language, it's still a library? Whatever floats your boat. Lol.
I think it’s actually reasonable to say that a Blub library should run on every implementation of Blub. So, GraalBlub and BlubBlub, not just CBlub.
replyOtherwise it’s just a sparkling FFI.
[dead]
reply