Note that C++26 is supposed to include a linear algebra subset on the standard library, for me that should be something via vcpkg or conan, then again there should be less issues accessing it, provided one can eventually restrain themselves to such recent version.
The article claims tensorflow uses eigen. That's not entirely accurate, although the pre-packaged builds of tensorflow are probably configured to use it. Tensorflow can also be configured to use BLAS/LAPACK at build time and not eigen.
> BLAS and LAPACK provide linear algebra functionality[...] They're written in C, C++, Fortran, and even some assembly code. They are typically not packaged on PyPi.
Pretty good example of what I name the "Small island problem".
And the main reason why I hate language specific package manager.
Phase 1- Every language try to reimplements its own package manager because it is seen as a "must have" for any modern language.
Phase 2 - The language specific package lanager is designed as if they live on a small isolated island. They do not try to integrate with other languages nor care about system libraries like OpenBLAS.
They do not manage properly versioning, diamond dependencies or ABI for basic libraries written in C C++, Fortran, Rust,....
Phase 3- the ecosystem grows up and the entire things blow up spectacularly in production due to the previously ignored problems.
The list of reasons can be pretty long: duplicated packages, ABI issues, portability issue, lack of sandboxing, poor system integration...).
Phase 4- Someone try to fix the mess by creating one more language specific package manager and we start again Phase 1.
And the problem is never solved because it is a structural problem and not an implementation one: At scale, language specific package managers are a terrible idea.
Taking into consideration the diversity of your ecosystem is not an option: it is a necessity.
Currently, the python and the JS ecosystems are beautiful examples of how far this madness can go.
Unfortunely not every operating system on planet Earth has a package manager, nor developers have enough time to support all the ones that have such feature.
> Unfortunely not every operating system on planet Earth has a package manager,
And they do not need to.
There is already multi-platforms multi-languages package managers that do this job relatively well (Nix, flatpak, Guix, Spack (to some extend) ) and this is on that we should focus.
Note that C++26 is supposed to include a linear algebra subset on the standard library, for me that should be something via vcpkg or conan, then again there should be less issues accessing it, provided one can eventually restrain themselves to such recent version.
https://en.cppreference.com/cpp/numeric/linalg
The article claims tensorflow uses eigen. That's not entirely accurate, although the pre-packaged builds of tensorflow are probably configured to use it. Tensorflow can also be configured to use BLAS/LAPACK at build time and not eigen.
> BLAS and LAPACK provide linear algebra functionality[...] They're written in C, C++, Fortran, and even some assembly code. They are typically not packaged on PyPi.
Pretty good example of what I name the "Small island problem".
And the main reason why I hate language specific package manager.
Phase 1- Every language try to reimplements its own package manager because it is seen as a "must have" for any modern language.
Phase 2 - The language specific package lanager is designed as if they live on a small isolated island. They do not try to integrate with other languages nor care about system libraries like OpenBLAS.
They do not manage properly versioning, diamond dependencies or ABI for basic libraries written in C C++, Fortran, Rust,....
Phase 3- the ecosystem grows up and the entire things blow up spectacularly in production due to the previously ignored problems.
The list of reasons can be pretty long: duplicated packages, ABI issues, portability issue, lack of sandboxing, poor system integration...).
Phase 4- Someone try to fix the mess by creating one more language specific package manager and we start again Phase 1.
And the problem is never solved because it is a structural problem and not an implementation one: At scale, language specific package managers are a terrible idea.
Taking into consideration the diversity of your ecosystem is not an option: it is a necessity.
Currently, the python and the JS ecosystems are beautiful examples of how far this madness can go.
Unfortunely not every operating system on planet Earth has a package manager, nor developers have enough time to support all the ones that have such feature.
> Unfortunely not every operating system on planet Earth has a package manager,
And they do not need to.
There is already multi-platforms multi-languages package managers that do this job relatively well (Nix, flatpak, Guix, Spack (to some extend) ) and this is on that we should focus.
Which aren't cross platform, UNIX flavours alone doesn't count.
It sorta looks like they're trying to reinvent Debian, and kinda failing?