7 ms·

New horizons for Julia

217 points by leephillips 2y ago

jshen 2y ago
I really like the direction of Julia and its managing of trade-offs. I hope it gains more traction.
affinepplan 2y ago
I know I know I know that this same refrain has probably been said nonstop since Julia's first day after launch, but the language really is getting noticeably better every single release. Each of the releases I've been around for (so 1.8-1.11, and now on nightly, 1.12) is adding meaningful new features, performance improvements, and addressing many of the oldest and sharpest pain points the `--trim` feature coming in 1.12 will still be considered experimental, and if I had to take a guess won't be considered "stable" until 1.14 or so, but I'm really excited to see it picked up around the ecosystem!
- Tarrosion 2y ago
  I can confirm this has been true since at least v0.4!
- SatvikBeri 2y ago
  We've quietly been using Julia at our hedge fund for ~4 years. It has saved us a lot of money. The syntax is easy for Math-heavy Researchers who might not have as much software engineering experience to use, but it's much faster than numpy, which we used for 5 years before. The package management is sane – not as good as Rust, but way better than Python/Javascript. We have one non-trivial macro which makes our codebase ~15% shorter, and would be hard to emulate in a lot of other languages. The REPL is really good, second only to Clojure IMO. The main thing I want to see more of is "static Julia", e.g. better support for static type-checking and binaries, and fortunately that seems to be where the language is going!
  - _benj 2y ago
    > We've quietly been using Julia at our hedge fund… This! I’ve found a lot of value in Julia for math specially in financial analysis. Julia’s DataFrame and general development workflow are excellent for research and when it comes to deployment is not too shabby either. I’m aware of pandas and the rest in Python, but for some reason Julia feels a lot more “ergonomic” for my use case.
  - 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
deleted 2y ago
[deleted]
cardanome 2y ago
Small static binaries could be an killer-feature for Julia. While I always had an eye on Julia and it is a lovely language, especially the multiply dispatch and general lispy-ness in spirit, I never really had a good use case for it. Python always was the better choice due to the stronger ecosystem and faster launch time. Rarely did I need the extra performance Julia offered. But Python is annoying to deploy so Julia starts to seem tempting, at least for smaller projects where you don't want to do a complex docker setup. Julia is for sure prioritizing the right things.
- Imustaskforhelp 2y ago
  You can use uv with uv run --script main.py and give it some requirements like numpy as well with --with numpy You can also upload it to pypi for example with name let's say for example heytest and then just do uvx heytest and it would just work. Uv is great , uv is love.
  - Imustaskforhelp 2y ago
    I have also been able to install uv easily / even create a static binary of uv
  - dleather 2y ago
    I started using UV. My first thought was "Great, Python works more like Julia now"
systems 2y ago
Julia is not a scripting language, or in other word, Julia scoping rule are not scripting friendly currently if in a file i have local s = 0 for i = 1:10 t = s + i s = t println("$s") end println("$s") and I execute this file, I will get an error ERROR: LoadError: UndefVarError: s not defined
- eigenspace 2y ago
  Note if you're doing this in the global scope, the local declaration on `s` will cause it to functionally not exist. You can write this as either s = 0 for i ∈ 1:10 t = s + i global s = t println("$s") end println("$s") or let s = 0 for i ∈ 1:10 t = s + i s = t println("$s") end println("$s") end
  - affinepplan 2y ago
    while of course you're correct on a technical level, I do tend to agree with the statement that Julia is not particularly friendly to bash-scripting-heavy workflows
    - eigenspace 2y ago
      Meh. For my purposes, Julia strikes a quite nice balance of fussiness versus permissiveness. Sure, there's things where I find it too fussy and I wish it'd go "yeah yeah I get what you mean" and there's also things where I find myself thinking "man, I really wish you had complained to me about that, it was clearly a bug / bad style!" But all-in-all, I find it's a language that mostly gets out of my way and lets me code, which I find very useful and nice for scripting. I think if one finds things like scoping rules annoying for scripting, that might just come down to just knowing and being more familiar with another language that has different rules.
      - catgary 2y ago
        See, I find it the opposite - superficially fussy, but it lets the silliest things slide. I don’t want my function to struggle with type instability in some contexts (perhaps only showing up deep in a physics simulation or motion planning algorithm) and allocate a bunch of memory, I don’t want it to compile in the first place if that’s possible.
jarbus 2y ago
Julia is still such an absolute joy to use. I have a dream that somehow, Torch.jl, which attempts to provide a julia interface to pytorch, will magically take off. Python is ok, but julia is just so fast, fun, and easy to scale.
- ssivark 2y ago
  Have you tried using PythonCall.jl (which allows you to basically use any random Python library, in principle) with Pytorch?
  - jarbus 2y ago
    I haven't, but I have used PythonCall, and it's really rough to use and constantly go back and forth between types. The main reason I love julia is because all julia packages build upon julia arrays, and don't require conversion to special arrays for that specific package.
LeroyRaz 2y ago
How does Julia compare to Python with Jax? I just love pythons ease of use, and the few times I've tried Julia it has felt clanky in comparison, and then Jax just makes everything so amazingly fast.
- DNF2 2y ago
  "Clanky"? That is a word I would use when comparing Julia and Python, but I would reverse the roles. I mean, python works well, and has almost everything, but it really feels, well, clanky.
  - thetwentyone 2y ago
    I'm currently working on a re-write of a small model from JAX to Julia and finding the Julia code so much easier to write, it's more concise, and find the debugging tools easier to work with in Julia.
- patagurbon 2y ago
  Check out Lux.jl and Reactant.jl for a modern attempt to create a Julia library with Jax’s XLA compiler backend!
  - catgary 2y ago
    Sometimes it really feels like JAX should be a more general DSL that can embed in other languages, as long as you have some way to turn structures into pytrees and functions into jaxpr’s.
    - mccoyb 2y ago
      Couldn’t agree more.
- currymj 2y ago
  for problems where Jax works well, in theory there could be a great Julia equivalent, but in practice one has not emerged. instead every 3 or so years, a brilliant solo researcher writes an even better autograd library which is ultimately abandoned. the language is at its best in other areas. for a few things (differential equations, mathematical optimization) it is actually state of the art.
acmj 2y ago
> The next major Julia release, 1.12, is likely to appear in mid-2025. It will finally include the ability to generate static binaries of a reasonable size, appropriate for distribution. I would be thrilled if Julia had this in early days, but now it is a little too late. I have jumped the boat.
- kruxigt 2y ago
  [dead]
- akkad33 2y ago
  What do you use instead
dleather 2y ago
I prefer to code in Julia almost always. It really is such a wonderful experience. Now if only I could land an industry job with my Julia skills...
catgary 2y ago
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.
currymj 2y ago
The article describes Julia as "a general-purpose programming language aimed at science, engineering, and related arenas of technical computing". I think this is about right. If you are going to solve differential equations or run some numerical weather codes or solve an integer program or simulate an electrical circuit, it would be a good idea to consider Julia rather than reaching for Fortran, C++, or MATLAB. It is a much nicer language and still very fast. My experience is that people who want to use Julia for data science and especially for deep learning, usually find that you can get the job done, but often it's easier to use PyTorch or Jax and just accept the limitations of Python.
- TheRealKing 2y ago
  The comments further above on the inherent limitations of the Julia language as a replacement for Fortran or C++ seem to contradict your opinion.
  - currymj 2y ago
    those limitations are sometimes real. However, I have read enough Fortran and C++ written by scientists, to fervently wish that their code had been written in Julia instead. In Julia, I don't think they could manage to write code so debauched. If you just do things the naive way, usually life is good and code is both readable and fast. The pitfall is type instability and memory allocation, but I think with a few basic tricks, people can learn to avoid this, especially for simpler tasks. (edit: also, if people do mess this up, they notice because their code is slow. whereas people don't notice if their code is fast but incomprehensible and impossible to maintain or extend.)
blindseer 2y ago
I'm happy to see static compilation in the works! If static compilation takes off, and people are able to build Python packages that are secretly just compiled Julia code, I can see a world where more people opt to using Julia over C or C++. Though writing Rust libraries that work as Python packages is a joy and Julia would still have competition. Julia biggest problem at the moment is growth. Julia has suffered from not having exponential growth, and has either maintained a small linear growth or has fallen in popularity. Search online on YouTube for tutorials, on Twitch for WatchPeopleCode, or on GitHub for benchmarks; and Julia is not even in the room where the conversation is happening - there just isn't any mindshare. And for good reason. There are so many ergonomic challenges when using Julia in a large codebase and in a large team. Julia has no formal interfaces, LSP suggestions that are often just wrong, and no option types. This just makes writing Julia code a drag. And it makes it quite difficult to advocate to developers experienced with languages that offer these features. Additionally, the core conceit pushed by Julia advocates is that the language is fast. This is true in controlled benchmarks but in real-world scenarios and in practice it is a real pain to write and maintain code that is fast for high velocity teams because it requires a lot of discipline and a strong understanding of memory allocation and assumptions the Julia can and cannot make. You can write code that is blazingly fast, and then you make a change somewhere else in your program and suddenly your code crawls to a halt. We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. Finding this was non-trivial. For reference, if this were uncaught our production version would have gone from 8 hours to 4 days. The lack of growth really hurts the language. Search for pretty much any topic under the sun and you'll find a Python package and possibly even a Rust crate. In Julia you are usually writing one from scratch. Packages are essential to data processing are contributor strained. If you have a somewhat unpopular open source code code you rely on that doesn't work quite work the way you want it to, you might think I'll just submit a PR but it can languish for months to a year. The Julia community needs to look at what programming languages are offering that Julia developers want and will benefit from. The software world changing very quickly and Julia needs to change too to keep up.
- kbarros 2y ago
  > We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. For those who might not be familiar, tooling can sometimes help a lot here. The ProfileView.jl package (or just calling the @profview macro in VSCode) will show an interactive flamegraph. Type instabilities are highlighted in red and memory allocations are highlighted in yellow. This will help to identify the exact line where the type instability or allocation occurs. Also, to prevent regressions, I really like using the JET.jl static analysis package in my unit tests.
cytocync 2y ago
[dead]

217 points by leephillips 2y ago

I really like the direction of Julia and its managing of trade-offs. I hope it gains more traction.

I know I know I know that this same refrain has probably been said nonstop since Julia's first day after launch, but the language really is getting noticeably better every single release. Each of the releases I've been around for (so 1.8-1.11, and now on nightly, 1.12) is adding meaningful new features, performance improvements, and addressing many of the oldest and sharpest pain points the `--trim` feature coming in 1.12 will still be considered experimental, and if I had to take a guess won't be considered "stable" until 1.14 or so, but I'm really excited to see it picked up around the ecosystem!

Tarrosion 2y ago
I can confirm this has been true since at least v0.4!
SatvikBeri 2y ago
We've quietly been using Julia at our hedge fund for ~4 years. It has saved us a lot of money. The syntax is easy for Math-heavy Researchers who might not have as much software engineering experience to use, but it's much faster than numpy, which we used for 5 years before. The package management is sane – not as good as Rust, but way better than Python/Javascript. We have one non-trivial macro which makes our codebase ~15% shorter, and would be hard to emulate in a lot of other languages. The REPL is really good, second only to Clojure IMO. The main thing I want to see more of is "static Julia", e.g. better support for static type-checking and binaries, and fortunately that seems to be where the language is going!
- _benj 2y ago
  > We've quietly been using Julia at our hedge fund… This! I’ve found a lot of value in Julia for math specially in financial analysis. Julia’s DataFrame and general development workflow are excellent for research and when it comes to deployment is not too shabby either. I’m aware of pandas and the rest in Python, but for some reason Julia feels a lot more “ergonomic” for my use case.
- 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

deleted 2y ago

[deleted]

cardanome 2y ago

Small static binaries could be an killer-feature for Julia. While I always had an eye on Julia and it is a lovely language, especially the multiply dispatch and general lispy-ness in spirit, I never really had a good use case for it. Python always was the better choice due to the stronger ecosystem and faster launch time. Rarely did I need the extra performance Julia offered. But Python is annoying to deploy so Julia starts to seem tempting, at least for smaller projects where you don't want to do a complex docker setup. Julia is for sure prioritizing the right things.

Imustaskforhelp 2y ago
You can use uv with uv run --script main.py and give it some requirements like numpy as well with --with numpy You can also upload it to pypi for example with name let's say for example heytest and then just do uvx heytest and it would just work. Uv is great , uv is love.
- Imustaskforhelp 2y ago
  I have also been able to install uv easily / even create a static binary of uv
- dleather 2y ago
  I started using UV. My first thought was "Great, Python works more like Julia now"

systems 2y ago

Julia is not a scripting language, or in other word, Julia scoping rule are not scripting friendly currently if in a file i have local s = 0 for i = 1:10 t = s + i s = t println("$s") end println("$s") and I execute this file, I will get an error ERROR: LoadError: UndefVarError: s not defined

eigenspace 2y ago
Note if you're doing this in the global scope, the local declaration on `s` will cause it to functionally not exist. You can write this as either s = 0 for i ∈ 1:10 t = s + i global s = t println("$s") end println("$s") or let s = 0 for i ∈ 1:10 t = s + i s = t println("$s") end println("$s") end
- affinepplan 2y ago
  while of course you're correct on a technical level, I do tend to agree with the statement that Julia is not particularly friendly to bash-scripting-heavy workflows
  - eigenspace 2y ago
    Meh. For my purposes, Julia strikes a quite nice balance of fussiness versus permissiveness. Sure, there's things where I find it too fussy and I wish it'd go "yeah yeah I get what you mean" and there's also things where I find myself thinking "man, I really wish you had complained to me about that, it was clearly a bug / bad style!" But all-in-all, I find it's a language that mostly gets out of my way and lets me code, which I find very useful and nice for scripting. I think if one finds things like scoping rules annoying for scripting, that might just come down to just knowing and being more familiar with another language that has different rules.
    - catgary 2y ago
      See, I find it the opposite - superficially fussy, but it lets the silliest things slide. I don’t want my function to struggle with type instability in some contexts (perhaps only showing up deep in a physics simulation or motion planning algorithm) and allocate a bunch of memory, I don’t want it to compile in the first place if that’s possible.

jarbus 2y ago

Julia is still such an absolute joy to use. I have a dream that somehow, Torch.jl, which attempts to provide a julia interface to pytorch, will magically take off. Python is ok, but julia is just so fast, fun, and easy to scale.

ssivark 2y ago
Have you tried using PythonCall.jl (which allows you to basically use any random Python library, in principle) with Pytorch?
- jarbus 2y ago
  I haven't, but I have used PythonCall, and it's really rough to use and constantly go back and forth between types. The main reason I love julia is because all julia packages build upon julia arrays, and don't require conversion to special arrays for that specific package.

LeroyRaz 2y ago

How does Julia compare to Python with Jax? I just love pythons ease of use, and the few times I've tried Julia it has felt clanky in comparison, and then Jax just makes everything so amazingly fast.

DNF2 2y ago
"Clanky"? That is a word I would use when comparing Julia and Python, but I would reverse the roles. I mean, python works well, and has almost everything, but it really feels, well, clanky.
- thetwentyone 2y ago
  I'm currently working on a re-write of a small model from JAX to Julia and finding the Julia code so much easier to write, it's more concise, and find the debugging tools easier to work with in Julia.
patagurbon 2y ago
Check out Lux.jl and Reactant.jl for a modern attempt to create a Julia library with Jax’s XLA compiler backend!
- catgary 2y ago
  Sometimes it really feels like JAX should be a more general DSL that can embed in other languages, as long as you have some way to turn structures into pytrees and functions into jaxpr’s.
  - mccoyb 2y ago
    Couldn’t agree more.
currymj 2y ago
for problems where Jax works well, in theory there could be a great Julia equivalent, but in practice one has not emerged. instead every 3 or so years, a brilliant solo researcher writes an even better autograd library which is ultimately abandoned. the language is at its best in other areas. for a few things (differential equations, mathematical optimization) it is actually state of the art.

acmj 2y ago

> The next major Julia release, 1.12, is likely to appear in mid-2025. It will finally include the ability to generate static binaries of a reasonable size, appropriate for distribution. I would be thrilled if Julia had this in early days, but now it is a little too late. I have jumped the boat.

kruxigt 2y ago
[dead]
akkad33 2y ago
What do you use instead

dleather 2y ago

I prefer to code in Julia almost always. It really is such a wonderful experience. Now if only I could land an industry job with my Julia skills...

catgary 2y ago

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.

currymj 2y ago

The article describes Julia as "a general-purpose programming language aimed at science, engineering, and related arenas of technical computing". I think this is about right. If you are going to solve differential equations or run some numerical weather codes or solve an integer program or simulate an electrical circuit, it would be a good idea to consider Julia rather than reaching for Fortran, C++, or MATLAB. It is a much nicer language and still very fast. My experience is that people who want to use Julia for data science and especially for deep learning, usually find that you can get the job done, but often it's easier to use PyTorch or Jax and just accept the limitations of Python.

TheRealKing 2y ago
The comments further above on the inherent limitations of the Julia language as a replacement for Fortran or C++ seem to contradict your opinion.
- currymj 2y ago
  those limitations are sometimes real. However, I have read enough Fortran and C++ written by scientists, to fervently wish that their code had been written in Julia instead. In Julia, I don't think they could manage to write code so debauched. If you just do things the naive way, usually life is good and code is both readable and fast. The pitfall is type instability and memory allocation, but I think with a few basic tricks, people can learn to avoid this, especially for simpler tasks. (edit: also, if people do mess this up, they notice because their code is slow. whereas people don't notice if their code is fast but incomprehensible and impossible to maintain or extend.)

blindseer 2y ago

I'm happy to see static compilation in the works! If static compilation takes off, and people are able to build Python packages that are secretly just compiled Julia code, I can see a world where more people opt to using Julia over C or C++. Though writing Rust libraries that work as Python packages is a joy and Julia would still have competition. Julia biggest problem at the moment is growth. Julia has suffered from not having exponential growth, and has either maintained a small linear growth or has fallen in popularity. Search online on YouTube for tutorials, on Twitch for WatchPeopleCode, or on GitHub for benchmarks; and Julia is not even in the room where the conversation is happening - there just isn't any mindshare. And for good reason. There are so many ergonomic challenges when using Julia in a large codebase and in a large team. Julia has no formal interfaces, LSP suggestions that are often just wrong, and no option types. This just makes writing Julia code a drag. And it makes it quite difficult to advocate to developers experienced with languages that offer these features. Additionally, the core conceit pushed by Julia advocates is that the language is fast. This is true in controlled benchmarks but in real-world scenarios and in practice it is a real pain to write and maintain code that is fast for high velocity teams because it requires a lot of discipline and a strong understanding of memory allocation and assumptions the Julia can and cannot make. You can write code that is blazingly fast, and then you make a change somewhere else in your program and suddenly your code crawls to a halt. We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. Finding this was non-trivial. For reference, if this were uncaught our production version would have gone from 8 hours to 4 days. The lack of growth really hurts the language. Search for pretty much any topic under the sun and you'll find a Python package and possibly even a Rust crate. In Julia you are usually writing one from scratch. Packages are essential to data processing are contributor strained. If you have a somewhat unpopular open source code code you rely on that doesn't work quite work the way you want it to, you might think I'll just submit a PR but it can languish for months to a year. The Julia community needs to look at what programming languages are offering that Julia developers want and will benefit from. The software world changing very quickly and Julia needs to change too to keep up.

kbarros 2y ago
> We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. For those who might not be familiar, tooling can sometimes help a lot here. The ProfileView.jl package (or just calling the @profview macro in VSCode) will show an interactive flamegraph. Type instabilities are highlighted in red and memory allocations are highlighted in yellow. This will help to identify the exact line where the type instability or allocation occurs. Also, to prevent regressions, I really like using the JET.jl static analysis package in my unit tests.

cytocync 2y ago

[dead]