Hacker News
points by famouswaffles 2 days ago | 0 comments
>the problem is that the Python community at large rather prefers their C bindings or nowadays Rust, sprinkle a bit of Python FFI on top, and call them "Python" libraries.

They are Python libraries. Don't make the mistake of screwing up the cause and effect here. C, Rust etc - those are the replaceable parts of the chain. There is an official C++ pytorch library and virtually nobody uses it for ML Research. People want to code in python and build those libraries so they can.

[–] pjmlp 2 days ago
Nope, they are Python bindings to native libraries.

PyTorch in C++ naturally gets little use, because most people don't want to use C++, and although possible, e.g. CINT, very few care about C++ REPLs.

Also these libraries only exist because Python cannot deliver on its own, like Lisp or Scheme, and needs such libraries in first place.

Even BASIC has better options to do machine code and system programming than Python, starting with the original Dartmouth BASIC.

[–] famouswaffles 2 days ago
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.

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

[–] pjmlp 2 days ago
For Python libraries they would be written in Python, eventually ctypes for syscalls.

Otherwise they are bindings to native libraries.

We can keep discussing in circles.

[–] famouswaffles 2 days ago
>For Python libraries they would be written in Python, eventually ctypes for syscalls.

So if you can't call/use the 'library' from the 'native' language, it's still a library? Whatever floats your boat. Lol.

[–] samatman 2 days ago
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.

Otherwise it’s just a sparkling FFI.

[–] bob001 1 day ago
Are you arguing that JIT Python or GraalPy will be as performant in a reasonable time as Python on top of those C++/Rust libraries? If not then I don't think it matters since unless you are claiming that all the existing C++/Rust libraries can be re-written in reasonable time and with the same performance. Keep in mind that many of these libraries are using low level tricks to optimize performance. Python is the UI and while the UI is important in the end it's just the UI.