There is, though: Python simply doesn’t allow things to be combined as flexibly as Julia does. To quote the article:Travis B. wrote: ↑Thu Nov 23, 2023 7:00 pmThe thing is to me this seems to not be all too different from what you find in most high-level, dynamic languages (read: not Haskell or Agda). There is no special reason why Python would be more resistant to such issues aside from the fact that it's more mature than Julia.bradrn wrote: ↑Thu Nov 23, 2023 6:18 pmUnfortunately, these problems seem pretty deeply embedded in how the Julia ecosystem is structured. The explanation in this article, which I’ve also heard elsewhere, is that Julia libraries rely pretty heavily on informal interfaces. (They can’t really be formalised since the type system doesn’t allow for it.) And of course that makes it really easy for different libraries to accidentally have slight inconsistencies in how they use and implement these interfaces, which causes these endless bugs.
These problems are simply impossible to get in Python. For instance, it’s quite difficult, and definitely unidiomatic, to define a notion of ‘Euclidean distance’ in Python in such a way that it can work with new and user-defined vector types. Even numpy arrays, in my experience, often don’t work with closely related libraries, unless they explicitly go out of their way to support numpy.Yuri Vishnevsky wrote: For example, I found that the Euclidean distance from the Distances package does not work with Unitful vectors. Others discovered that Julia’s function to run external commands doesn’t work with substrings. Still others found that Julia’s support for missing values breaks matrix multiplication in some cases. And that the standard library’s @distributed macro didn’t work with OffsetArrays.
By contrast, Julia explicitly encourages programming in such a way that everything can generically work with everything else… which is a really nice idea, right up until it crashes and burns.
Fair enough. (Though surely Julia calls into external libraries too? I can’t imagine it not using BLAS/LAPACK, at least.)Travis B. wrote: ↑Thu Nov 23, 2023 7:00 pmYes, practically nothing will completely replace Fortran, as Fortran is basically as fast as you can get, aside from assembly. And yes, just like with Python, you can call Fortran from Julia need be. The key thing, though, is that Julia is basically the fastest you will get out of a truly high-level, dynamic language without calling an external library, unlike, say, Python, where code in the immediate language one is developing in is dead slow outside of external libraries (e.g. NumPy, SciPy) written in Fortran or C.bradrn wrote: ↑Thu Nov 23, 2023 6:18 pm Also: ‘a proper replacement for Fortran’ is hyperbolic. As a Forth person, it should make sense to you when I say that Fortran gets its speed from being fairly low-level. (And also a few design choices which allow for extra optimisation, e.g. disallowing pointer aliasing.) Julia has a very good JIT compiler, but it’s still a high-level language. You couldn’t, for instance, reimplement BLAS in Julia (to my knowledge).