4 ms·

I’m kind of sad, because I think I have completed the journey from advocating for Julia at my first job to becoming a full-blown hater. I have complaints about

I’m kind of sad, because I think I have completed the journey from advocating for Julia at my first job to becoming a full-blown hater. I have complaints about the type system and the general failure of a good autograd library to emerge as the standard/default. But my main complaint about Julia is its general approach to memory management. You are encouraged to think about how memory is being allocated e.g. by using StaticArrays for smaller, immutable arrays, or pre-allocating the arrays and operating on them in-place. But you don’t actually have control over allocations, and it’s easy for some type instability to cause unnecessary allocations - even after you stick a bunch of type annotations which should give the compiler sufficient information to force type stability or at least crash/fail to type check. At this point I think people are better off investing their time/efforts into Rust for computationally heavy workloads on the CPU (polars for data frame stuff, ndarray for numpy functionality, Enzyme for autodiff) and using torch/jax for GPU-centric work (also, it’s significantly easier to write python bindings for rust libraries than C++ or Julia libs).

kjrfghslkdjfl 2y ago
> But my main complaint about Julia is its general approach to memory management. I'm not a full-blown hater, but I have problems with that as well. Specifically, you have no control about it whatsoever, you're just promised that "if you do things right, it'll be amazing". And it is! The problem is that any tiny minuscule mistake causes catastrophic failure of performance due to allocations. Since the good performance depends on type stability, and type stability propagates, any mistake anywhere will propagate everywhere. Think: if a variable becomes type unstable due to a programmer mistake, any function that consumes it generally might become type unstable as well, and any function that consumes the output of that function as well, etc. The upshot is that this forces you to think more carefully about your types and data structures. Programming in Julia extensively has made me a better programmer. I'm not a C++ expert, but I believe that in C++ these kind of mistakes always end up being localized.
- catgary 2y ago
  I was a Haskell programmer in grad school, and Julia was how I learned “oh, some times the programmer does know better than the type system/compiler”. I think the way they approached multiple dispatch in the language (and the resulting allocations due to type instability) is really the original sin of the language, and I just don’t think it can be fixed, so I can’t help but feel any effort to improve Julia is a waste of time.
- DNF2 2y ago
  That is not really correct. Type instabilities tend to disappear at function boundaries, which is one of the reasons why using functions is so heavily promoted in Julia, it helps keep type instabilites 'localized'.
kbarros 2y ago
Julia is my tool of choice for writing numerical code where performance is critical. I work in computational physics, and have found Julia and its ecosystem to be far nicer than Rust in this space. It's true that accidental dynamic behaviors are a real concern and can be a performance killer. Fortunately, the language has nice tooling. In VSCode, I often use the visual profiling tool `@profview` to get a flame graph. Anything dynamic gets highlighted in red, and is quick to diagnose. There also exist nice static analysis packages like JET.jl. During development, one can use `report_opt` to statically rule out accidental dynamical behaviors. Such checks can also be incorporated into a project's unit tests. In practice, it's not much of an issue for me anymore. But to be fair, there is a big learning curve for new Julia users. See, e.g., https://docs.julialang.org/en/v1/manual/performance-tips/ https://docs.julialang.org/en/v1/manual/performance-tips/
- catgary 2y ago
  Those tools didn’t actually exist the year or so I was writing Julia professionally (and that was only 3 years ago) so it’s nice to see the language coming along. At the same time, I would expect the Rust ecosystem to overtake Julia’s in that domain in the next couple of years. Polars is already nicer than pandas, I’ve seen a some promising work on numpy-style tensor libraries, and I’m pretty impressed by the progress with getting enzyme integrated into Rust (I could never make it work with Julia). Here’s a nice example repo I saw recently: https://github.com/ChemAI-Lab/molpipx/ https://github.com/ChemAI-Lab/molpipx/
  - thunkingdeep 2y ago
    Not the person you’re respond to, but Rust is never going to have a REPL and is likely to never compile very quickly. For a lot of numerical and scientific use cases that’s a fundamentally restraining factor. WRT performance, you’re ofc correct but that’s not always as paramount as it may seem if you need to tweak the data dozens or hundreds or thousands of time. In that case, having to wait more than say 5 seconds or so is prohibitively annoying. I think something in between Zig and Rust will emerge someday as a sort of optimal compromise between compile speed, safety, and programmability wrt memory and performance tradeoffs.
npalli 2y ago
You were going through some good points until you hit Rust and then the entire argument seemed suspect. Rust has none of the interactivity of the REPL or dynamism. Complete pain for a normal scientist programmer. Given that security is not a burning need in this area, even C++ is superior as the entire computing infra is very much C++ based.
- catgary 2y ago
  Oh, I would advocate for writing high quality libraries/components in Rust and then using Maturin to generate Python bindings for interactivity, [1] is an example of that workflow and it looks quite smooth. [1]https://github.com/ChemAI-Lab/molpipx/ https://github.com/ChemAI-Lab/molpipx/
  - DNF2 2y ago
    Then you are back to the "two language problem". I'm sure that's not a problem for you and for many others, but there is a reason it has its own, widely known name. It really is a problem for people who are mostly not software developers, but instead engineers or researchers.
    - catgary 2y ago
      Right, I guess my take on Julia is that it shows the concessions necessary to make a language “approachable” for scientists/engineers will inevitably lead to a language that is poorly suited for developing large, robust software projects.
  - snicker7 2y ago
    An interpreter is an optimization barrier relative to native composition.
- Imustaskforhelp 2y ago
  https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.md https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.m... There is this if we really want a rust repl

kjrfghslkdjfl 2y ago

> But my main complaint about Julia is its general approach to memory management. I'm not a full-blown hater, but I have problems with that as well. Specifically, you have no control about it whatsoever, you're just promised that "if you do things right, it'll be amazing". And it is! The problem is that any tiny minuscule mistake causes catastrophic failure of performance due to allocations. Since the good performance depends on type stability, and type stability propagates, any mistake anywhere will propagate everywhere. Think: if a variable becomes type unstable due to a programmer mistake, any function that consumes it generally might become type unstable as well, and any function that consumes the output of that function as well, etc. The upshot is that this forces you to think more carefully about your types and data structures. Programming in Julia extensively has made me a better programmer. I'm not a C++ expert, but I believe that in C++ these kind of mistakes always end up being localized.

catgary 2y ago
I was a Haskell programmer in grad school, and Julia was how I learned “oh, some times the programmer does know better than the type system/compiler”. I think the way they approached multiple dispatch in the language (and the resulting allocations due to type instability) is really the original sin of the language, and I just don’t think it can be fixed, so I can’t help but feel any effort to improve Julia is a waste of time.
DNF2 2y ago
That is not really correct. Type instabilities tend to disappear at function boundaries, which is one of the reasons why using functions is so heavily promoted in Julia, it helps keep type instabilites 'localized'.

kbarros 2y ago

Julia is my tool of choice for writing numerical code where performance is critical. I work in computational physics, and have found Julia and its ecosystem to be far nicer than Rust in this space. It's true that accidental dynamic behaviors are a real concern and can be a performance killer. Fortunately, the language has nice tooling. In VSCode, I often use the visual profiling tool `@profview` to get a flame graph. Anything dynamic gets highlighted in red, and is quick to diagnose. There also exist nice static analysis packages like JET.jl. During development, one can use `report_opt` to statically rule out accidental dynamical behaviors. Such checks can also be incorporated into a project's unit tests. In practice, it's not much of an issue for me anymore. But to be fair, there is a big learning curve for new Julia users. See, e.g., https://docs.julialang.org/en/v1/manual/performance-tips/ https://docs.julialang.org/en/v1/manual/performance-tips/

catgary 2y ago
Those tools didn’t actually exist the year or so I was writing Julia professionally (and that was only 3 years ago) so it’s nice to see the language coming along. At the same time, I would expect the Rust ecosystem to overtake Julia’s in that domain in the next couple of years. Polars is already nicer than pandas, I’ve seen a some promising work on numpy-style tensor libraries, and I’m pretty impressed by the progress with getting enzyme integrated into Rust (I could never make it work with Julia). Here’s a nice example repo I saw recently: https://github.com/ChemAI-Lab/molpipx/ https://github.com/ChemAI-Lab/molpipx/
- thunkingdeep 2y ago
  Not the person you’re respond to, but Rust is never going to have a REPL and is likely to never compile very quickly. For a lot of numerical and scientific use cases that’s a fundamentally restraining factor. WRT performance, you’re ofc correct but that’s not always as paramount as it may seem if you need to tweak the data dozens or hundreds or thousands of time. In that case, having to wait more than say 5 seconds or so is prohibitively annoying. I think something in between Zig and Rust will emerge someday as a sort of optimal compromise between compile speed, safety, and programmability wrt memory and performance tradeoffs.

npalli 2y ago

You were going through some good points until you hit Rust and then the entire argument seemed suspect. Rust has none of the interactivity of the REPL or dynamism. Complete pain for a normal scientist programmer. Given that security is not a burning need in this area, even C++ is superior as the entire computing infra is very much C++ based.

catgary 2y ago
Oh, I would advocate for writing high quality libraries/components in Rust and then using Maturin to generate Python bindings for interactivity, [1] is an example of that workflow and it looks quite smooth. [1]https://github.com/ChemAI-Lab/molpipx/ https://github.com/ChemAI-Lab/molpipx/
- DNF2 2y ago
  Then you are back to the "two language problem". I'm sure that's not a problem for you and for many others, but there is a reason it has its own, widely known name. It really is a problem for people who are mostly not software developers, but instead engineers or researchers.
  - catgary 2y ago
    Right, I guess my take on Julia is that it shows the concessions necessary to make a language “approachable” for scientists/engineers will inevitably lead to a language that is poorly suited for developing large, robust software projects.
- snicker7 2y ago
  An interpreter is an optimization barrier relative to native composition.
Imustaskforhelp 2y ago
https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.md https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.m... There is this if we really want a rust repl