3 ms·

I am curious, have you run into any of the issues with Julia discussed here [0] (also discussed on HN [1])? Those problems would seem particularly troubling at

by t_mann 2y ago

I am curious, have you run into any of the issues with Julia discussed here [0] (also discussed on HN [1])? Those problems would seem particularly troubling at a hedge fund to me, if you have to question the accuracy of your results after chaining multiple complex models together. Curious about your stance on / experience with correctness issues in Julia. [0] https://yuri.is/not-julia/ https://yuri.is/not-julia/ [1] https://news.ycombinator.com/item?id=31396861 https://news.ycombinator.com/item?id=31396861

SatvikBeri 2y ago
We've run into issues with Arrow – it or its dependencies would frequently break on updates, and we stopped using it. But none of the other issues mentioned in the article have ever come up for us. In particular, a lot of the problems come from using OffsetArrays.jl, which is a library designed to let you use different starting indices for an array, which we just don't use. It's worth noting that we initially migrated ~15kloc of numpy data/numeric pipelines to Julia, and mostly found the same values, with the exception of something that turned out to be a bug in a Python library. I would say that the biggest Julia annoyance we've run into has to do with the way the Expr type is implemented, particularly the fact that it's mutable, which makes some of the metaprogramming we want to do substantially harder. But that's not a bug per se, just a design choice I don't like.
- kruxigt 2y ago
  [dead]
affinepplan 2y ago
I won't pretend that Julia doesn't have its fair share of `wats`, but in my experience they tend to be in one of two categories * usage of `OffsetArrays.jl` (really, just avoiding this package fixes most of the issues) * hideously cursed syntax that should only pass a code review if your name is Lovecraft, but for some reason the parser allows it if you don't do either of those things (which at least personally speaking, I don't) then I don't think the rate of "correctness issues" is any higher or lower than I experience in other ecosystems. In fact, it's probably lower Don't forget that other languages are not immune... I love the `polars` library as well but in my two years of using it I've encountered organically two separate "correctness" bugs. It's just par for the course for any big code surface
TheRealKing 2y ago
Adding to the list is the tragedy of Julia programming language's type system: https://medium.com/@393069484/a-tragedy-of-julias-type-system-702e2346edd8 https://medium.com/@393069484/a-tragedy-of-julias-type-syste...
- affinepplan 2y ago
  there exist many high quality criticisms of Julia's type system, but this article does not contain them if I'm being totally honest. I think this writeup here https://viralinstruction.com/posts/badjulia/#the_type_system_works_poorly https://viralinstruction.com/posts/badjulia/#the_type_system... contains more valid gripes about the type system than the one you linked.
  - ningcongchen 2y ago
    Using Union as an example is more understandable than using abstract types. I can also explain why abstract types are broken, but that would involve a complex interaction of subtyping and abstract interpretation. In addition, I believe that abstract types are not that horrible since in industry we use OOP any way (https://github.com/Suzhou-Tongyuan/ObjectOriented.jl https://github.com/Suzhou-Tongyuan/ObjectOriented.jl). I coworked with the author of this package several years ago. Currently, he is developping a different branch of Julia compiler. Since OOP makes eveything easier to design (from linter to static compiler), and programmers prefer OOP over abstract types, I personally don't think they will cause huge problems.

by t_mann 2y ago

SatvikBeri 2y ago

We've run into issues with Arrow – it or its dependencies would frequently break on updates, and we stopped using it. But none of the other issues mentioned in the article have ever come up for us. In particular, a lot of the problems come from using OffsetArrays.jl, which is a library designed to let you use different starting indices for an array, which we just don't use. It's worth noting that we initially migrated ~15kloc of numpy data/numeric pipelines to Julia, and mostly found the same values, with the exception of something that turned out to be a bug in a Python library. I would say that the biggest Julia annoyance we've run into has to do with the way the Expr type is implemented, particularly the fact that it's mutable, which makes some of the metaprogramming we want to do substantially harder. But that's not a bug per se, just a design choice I don't like.

kruxigt 2y ago
[dead]

affinepplan 2y ago

I won't pretend that Julia doesn't have its fair share of `wats`, but in my experience they tend to be in one of two categories * usage of `OffsetArrays.jl` (really, just avoiding this package fixes most of the issues) * hideously cursed syntax that should only pass a code review if your name is Lovecraft, but for some reason the parser allows it if you don't do either of those things (which at least personally speaking, I don't) then I don't think the rate of "correctness issues" is any higher or lower than I experience in other ecosystems. In fact, it's probably lower Don't forget that other languages are not immune... I love the `polars` library as well but in my two years of using it I've encountered organically two separate "correctness" bugs. It's just par for the course for any big code surface

TheRealKing 2y ago

Adding to the list is the tragedy of Julia programming language's type system: https://medium.com/@393069484/a-tragedy-of-julias-type-system-702e2346edd8 https://medium.com/@393069484/a-tragedy-of-julias-type-syste...

affinepplan 2y ago
there exist many high quality criticisms of Julia's type system, but this article does not contain them if I'm being totally honest. I think this writeup here https://viralinstruction.com/posts/badjulia/#the_type_system_works_poorly https://viralinstruction.com/posts/badjulia/#the_type_system... contains more valid gripes about the type system than the one you linked.
- ningcongchen 2y ago
  Using Union as an example is more understandable than using abstract types. I can also explain why abstract types are broken, but that would involve a complex interaction of subtyping and abstract interpretation. In addition, I believe that abstract types are not that horrible since in industry we use OOP any way (https://github.com/Suzhou-Tongyuan/ObjectOriented.jl https://github.com/Suzhou-Tongyuan/ObjectOriented.jl). I coworked with the author of this package several years ago. Currently, he is developping a different branch of Julia compiler. Since OOP makes eveything easier to design (from linter to static compiler), and programmers prefer OOP over abstract types, I personally don't think they will cause huge problems.