9 ms·
> It’s pretty common to see posts on the Julia Discourse saying “XYZ library doesn’t work”, followed by a reply from one of the library maintainers stating some
by patrick451 4y ago
> It’s pretty common to see posts on the Julia Discourse saying “XYZ library doesn’t work”, followed by a reply from one of the library maintainers stating something like “This is an upstream bug in the new version a.b.c of the ABC library, which XYZ depends upon. We’ll get a fix pushed ASAP.”
And
> First of all, it’s not in the Flux documentation. Instead it’s in the documentation for a separate component library – Zygote. So you have to check both, and you have to know to check both.
People love to rave about how the julia ecosystem is made up of tons of tiny composable libraries instead of large monolithic libraries like scipy. To me, that sounds like a major headache, and the quotes above are partly why. I'd rather read docs for one library than two. The chances that the maintainers of a large monolithic library break internal compatibility is way smaller than the chance that two disconnected projects become incompatible.
- rg111 4y ago> People love to rave about how the julia ecosystem is made up of tons of tiny composable libraries instead of large monolithic libraries like scipy. To me, that sounds like a major headache Absolutely agree. First and foremost, I need to get my work done. I do not want to learn all those libraries. The API design, its quality, philosophy (or lack thereof) of framework will be different across all the frameworks. And I am not sure I want too many libraries in my codebase. It is a whole different level of technical debt.