5 ms·

How's the Julia ecosystem these days? I used it for a couple of years in the early days (2013-2016ish) and things initially felt like they were going somewhere,

How's the Julia ecosystem these days? I used it for a couple of years in the early days (2013-2016ish) and things initially felt like they were going somewhere, but since then I haven't seen it make much inroads. Any thoughts from someone more plugged in to the community today?

pjmlp 1y ago
Going well, regardless of the regular doom and gloom comments on HN. https://juliahub.com/case-studies https://juliahub.com/case-studies
- doctoboggan 1y ago
  One of those case studies is me at my former company. We ended up moving away from Julia
  - pjmlp 1y ago
    Because of Julia flaws, or management decisions completely unrelated to the tooling?
    - doctoboggan 1y ago
      We were a startup and I was the "management", but it was mostly for HR reasons. The original dev who convinced me to try Julia ended up leaving, and when we pivoted to a new niche that required a rethinking of the codebase, we took the opportunity to re-write in C# (mostly because a we _needed_ C# to develop a plugin, and it would simplify things if everything was C#).
      - pjmlp 1y ago
        Thanks for the clarification.
  - deleted 1y ago
    [deleted]
- ofrzeta 1y ago
  There's only one case study from 2025, though.
  - pjmlp 1y ago
    "Keep it steady and slow" Python started in 1989, it also took its time.
    - ofrzeta 1y ago
      It's not steady, though, when there are 9 projects in 2023, 5 projects in 2024 and 1 project in 2025 (until now). Maybe steady but a steady decrease. I don't want to exaggerate the importance of the case study quantity but overall it's not that promising. Are you using Julia?
      - pjmlp 1y ago
        No, neither am I using Python, so is Python in danger because I am not using it?
SatvikBeri 1y ago
My company (a hedge fund) has been using Julia for our major data/numeric pipelines for 4 years. It's been great. Very easy to translate math/algorithms into code, lots of syntactical niceties, parallelism/concurrency is easy, macros for the very rare cases you need them. It's easy to get high performance and possible to get extremely high performance. It does have some well-known issues (like slow startup/compilation time) but if you're using it for long-running data pipelines it's great.
- nextos 1y ago
  What kind of library stack do you use? Julia has lots of interesting niche libraries for online inference, e.g. Gen.jl, which can be quite relevant for a hedge fund. If you can't talk about library stacks, it'd be at least interesting to hear your thoughts about how you minimize memory allocation.
  - SatvikBeri 1y ago
    Very little actually, we try to minimize dependencies, especially for the core inference engine. We just have some basic stuff like Statistics and LinearAlgebra. We use a lot more libraries for offline analysis, but even there it's just popular stuff like DataFrames combined with our own code. We control memory allocation the boring, manual way – we preallocate all our arrays, and then just modify them, so that we have very little continued allocation in production.
TimorousBestie 1y ago
My shop just moved back to Julia for digital signal processing and it’s accelerated development considerably over our old but mature internal C++ ecosystem.
- csvance 1y ago
  Mine did the same for image processing but coming from python/numpy/numba. We initially looked at using Rust or C++ but I'm glad we chose to stick it out with Julia despite some initial setbacks. Numerical code flows and read so nicely in Julia. It's also awesome seeing the core language continuously improve so much.
- zerr 1y ago
  How do you deploy it?
  - TimorousBestie 1y ago
    StaticCompiler.jl is the main workhorse.
- nextos 1y ago
  Can you elaborate on what libraries, platform, and tooling you use?
__atx__ 1y ago
I do wonder in particular about the startup time "time-to-plot" issue. I last used Julia about 2021-ish to develop some signal processing code, and restarting the entire application could have easily taken tens of seconds. Both static precompilation and hot reloading were in early development and did not really work well at the time.
- moelf 1y ago
  on a macMini (i.e. fast RAM), time to display: - Plots.jl, 1.4 seconds (include package loading) - CairoMakie.jl, 4 seconds (including package loading) julia> @time @eval (using Plots; display(plot(rand(3)))) 1.477268 seconds (1.40 M allocations: 89.648 MiB, 2.70% gc time, 7.16% compilation time: 5% of which was recompilation)
- j_maffe 1y ago
  That was fixed in 1.9. Indeed it makes a huge difference now that you can quickly run for the first time.
  - jakobnissen 1y ago
    This was absolutely not "fixed" in 1.9, what are you talking about. It was improved in 1.9, but that's it. Startup time is still unacceptably slow - still tens of seconds for large codebases. Worse, there are still way too many compilation traps. Splatted a large collection into a function? Compiler chokes. Your code accidentally moves a value from the value to the type domain? You end up with millions of new types, compiler chokes. Accidentally pirate a method? Huge latency. Chose to write type unstable code? Invalidations tank your latency.
    - almostgotcaught 1y ago
      > what are you talking about. It's the most annoying thing about hn that people will regularly declare/proclaim some thing like this as if it's a Nobel prize winning discovery when it's actually just some incremental improvement. I have no idea how this works in these people's lives - aren't we all SWEs where the specifics actually matter. My hypothesis is these people are just really bad SWEs.
electroly 1y ago
Disclaimer: I am not plugged into the community. The other day that old article "Why I no longer recommend Julia" got passed around. On the very same day I encountered my own bug in the Julia ecosystem, in JuliaFormatter, that silently poisoned my results. I went to the GitHub issues and someone else encountered it on the same day. I'm sure they will fix it (they haven't yet, JuliaFormatter at this very moment is a subtle codebase-destroyer) but as a newcomer to the ecosystem I am not prepared to understand which bog standard packages can be trusted and which cannot. As an experiment I switched to R and the language is absolute filth compared to Julia, but I haven't seen anyone complain about bugs (the opposite, in fact) and the packages install fast without needing to ship prebuilt sysimages like I do in Julia. Those are the only two good things about R but they're really important. I think Julia will get there once they have more time in the oven for everything to stabilize and become battle hardened, and then Julia will be a force to be reckoned with. An actually good language for analysis! Amazing!
- postflopclarity 1y ago
  just to be fair, the very first words in the README for JuliaFormatter is a warning that v2 is broken, and users should stick to v1. so it is not a "subtle" codebase-destroyer so much as a "loud" codebase-destroyer.
  - electroly 1y ago
    That's fair, and my bug was in 2.x, but it doesn't really make me feel better. If anything, I feel worse knowing this is OffsetArrays again--the ecosystem made cross-cutting changes that it doesn't have the manpower to absorb across the board, so everything is just buggy everywhere as a result. This is now a pattern. The codebase destruction warning was not super loud, though. Obviously I missed it despite using JuliaFormatter constantly. It doesn't get printed when you install the package nor when you use it. It's not on the docs webpage for JuliaFormatter. 2.x is still the version you get when you install JuliaFormatter without specifying a version. The disclaimer is only in the GitHub readme, and I was reading the docs. What other packages have disclaimers that I'm not seeing because I'm "only" reading the user documentation and not the GitHub developer readme?
currymj 1y ago
for many types of scientific computing, there's a case to be made it is the best language available. often this type of computing would be in scientific/engineering organizations and not in most software companies. this is its best niche, an important one, but not visible to people with SWE jobs making most software. it can be used for deep learning but you probably shouldn't, currently, except as a small piece of a large problem where you want Julia for other reasons (e.g. scientific machine learning). They do keep improving this and it will probably be great eventually. i don't know what the experience is like using it for traditional data science tasks. the plotting libraries are actually pretty nicely designed and no longer have horrible compilation delays. people who like type systems tend to dislike Julia's type system. they still have the problem of important packages being maintained by PhD students who graduate and disappear. as a language it promises a lot and mostly delivers, but those compromises where it can't deliver can be really frustrating. this also produces a social dynamic of disillusioned former true believers.
- gugagore 1y ago
  > people who like type systems tend to dislike Julia's type system. This is true. As far as I understand it, there is not a type theory basis for Julia's design (type theory seems to have little to say about subtyping type lattices). Relatedly, another comment mentioned that Julia needs sum types.
  - pjmlp 1y ago
    It is the same type theory that has powered Common Lisp and Dylan.
    - gugagore 1y ago
      We're not using "type theory" the same way, I think. I'm thinking in terms of - simply typed lambda calculus - System F - dependent type theory (MLTT) - linear types - row types - and so on But it's subtle to talk about. It's not like there is a single type theory that underlies Typescript or Rust, either. These practical languages have partial, (and somewhat post-hoc) formalizations of their systems.
csvance 1y ago
In my experience starting with Julia in 2025, the main thing missing from the ecosystem tends to be boring glue type packages, like a production grade gRPC client/server. I heard HTTP.jl is also slow, but I havn't sufficiently dug into this myself. At least we have an excellent ProtoBuf implementation so you can roll your own performant RPC protocol. As for the actual numerical stuff I tend to roll my own implementations of most algorithms to better control relevant tradeoffs. There are sometimes issues where a particular algorithm is implemented by a Julia package, but has performance issues / bugs in edge cases. For example, in my testing I wasn't able to get ImageContrastAdjustment CLAHE to run very fast and it had an issue where it throws an exception with an image of all zeros. You also can't easily call the OpenCV version as CLAHE is implemented in OpenCV using an object which doesn't have a binding available in Julia. After not getting anywhere within the ecosystem I just wrote my own optimized CLAHE implementation in Julia which I'm very happy with, this is truly where Julia shines. It's worth noting however that there are many excellent packages to build on such as InterprocessCommunication, ResumableFunctions, StaticArrays, ThreadPinning, Makie, and more. If you don't mind filling in some gaps here and there its completely serviceable. As for the core language and runtime we are deploying a Julia service to production next release and haven't had any stability/GC/runtime issues after a fairly extensive testing period. All of the Python code we replaced led to a ~40% speedup while improvements to numerical precision led to measurably improved predictions. Development with Revise takes some getting used to but once you get familiar with it you will miss it in other languages. All in all it feels like the language is in a good place currently and is only getting better. I'd like to eventually contribute back to help with some of the ecosystem gaps that impacted me.

pjmlp 1y ago

Going well, regardless of the regular doom and gloom comments on HN. https://juliahub.com/case-studies https://juliahub.com/case-studies

doctoboggan 1y ago
One of those case studies is me at my former company. We ended up moving away from Julia
- pjmlp 1y ago
  Because of Julia flaws, or management decisions completely unrelated to the tooling?
  - doctoboggan 1y ago
    We were a startup and I was the "management", but it was mostly for HR reasons. The original dev who convinced me to try Julia ended up leaving, and when we pivoted to a new niche that required a rethinking of the codebase, we took the opportunity to re-write in C# (mostly because a we _needed_ C# to develop a plugin, and it would simplify things if everything was C#).
    - pjmlp 1y ago
      Thanks for the clarification.
- deleted 1y ago
  [deleted]
ofrzeta 1y ago
There's only one case study from 2025, though.
- pjmlp 1y ago
  "Keep it steady and slow" Python started in 1989, it also took its time.
  - ofrzeta 1y ago
    It's not steady, though, when there are 9 projects in 2023, 5 projects in 2024 and 1 project in 2025 (until now). Maybe steady but a steady decrease. I don't want to exaggerate the importance of the case study quantity but overall it's not that promising. Are you using Julia?
    - pjmlp 1y ago
      No, neither am I using Python, so is Python in danger because I am not using it?

SatvikBeri 1y ago

My company (a hedge fund) has been using Julia for our major data/numeric pipelines for 4 years. It's been great. Very easy to translate math/algorithms into code, lots of syntactical niceties, parallelism/concurrency is easy, macros for the very rare cases you need them. It's easy to get high performance and possible to get extremely high performance. It does have some well-known issues (like slow startup/compilation time) but if you're using it for long-running data pipelines it's great.

nextos 1y ago
What kind of library stack do you use? Julia has lots of interesting niche libraries for online inference, e.g. Gen.jl, which can be quite relevant for a hedge fund. If you can't talk about library stacks, it'd be at least interesting to hear your thoughts about how you minimize memory allocation.
- SatvikBeri 1y ago
  Very little actually, we try to minimize dependencies, especially for the core inference engine. We just have some basic stuff like Statistics and LinearAlgebra. We use a lot more libraries for offline analysis, but even there it's just popular stuff like DataFrames combined with our own code. We control memory allocation the boring, manual way – we preallocate all our arrays, and then just modify them, so that we have very little continued allocation in production.

TimorousBestie 1y ago

My shop just moved back to Julia for digital signal processing and it’s accelerated development considerably over our old but mature internal C++ ecosystem.

csvance 1y ago
Mine did the same for image processing but coming from python/numpy/numba. We initially looked at using Rust or C++ but I'm glad we chose to stick it out with Julia despite some initial setbacks. Numerical code flows and read so nicely in Julia. It's also awesome seeing the core language continuously improve so much.
zerr 1y ago
How do you deploy it?
- TimorousBestie 1y ago
  StaticCompiler.jl is the main workhorse.
nextos 1y ago
Can you elaborate on what libraries, platform, and tooling you use?

__atx__ 1y ago

I do wonder in particular about the startup time "time-to-plot" issue. I last used Julia about 2021-ish to develop some signal processing code, and restarting the entire application could have easily taken tens of seconds. Both static precompilation and hot reloading were in early development and did not really work well at the time.

moelf 1y ago
on a macMini (i.e. fast RAM), time to display: - Plots.jl, 1.4 seconds (include package loading) - CairoMakie.jl, 4 seconds (including package loading) julia> @time @eval (using Plots; display(plot(rand(3)))) 1.477268 seconds (1.40 M allocations: 89.648 MiB, 2.70% gc time, 7.16% compilation time: 5% of which was recompilation)
j_maffe 1y ago
That was fixed in 1.9. Indeed it makes a huge difference now that you can quickly run for the first time.
- jakobnissen 1y ago
  This was absolutely not "fixed" in 1.9, what are you talking about. It was improved in 1.9, but that's it. Startup time is still unacceptably slow - still tens of seconds for large codebases. Worse, there are still way too many compilation traps. Splatted a large collection into a function? Compiler chokes. Your code accidentally moves a value from the value to the type domain? You end up with millions of new types, compiler chokes. Accidentally pirate a method? Huge latency. Chose to write type unstable code? Invalidations tank your latency.
  - almostgotcaught 1y ago
    > what are you talking about. It's the most annoying thing about hn that people will regularly declare/proclaim some thing like this as if it's a Nobel prize winning discovery when it's actually just some incremental improvement. I have no idea how this works in these people's lives - aren't we all SWEs where the specifics actually matter. My hypothesis is these people are just really bad SWEs.

electroly 1y ago

Disclaimer: I am not plugged into the community. The other day that old article "Why I no longer recommend Julia" got passed around. On the very same day I encountered my own bug in the Julia ecosystem, in JuliaFormatter, that silently poisoned my results. I went to the GitHub issues and someone else encountered it on the same day. I'm sure they will fix it (they haven't yet, JuliaFormatter at this very moment is a subtle codebase-destroyer) but as a newcomer to the ecosystem I am not prepared to understand which bog standard packages can be trusted and which cannot. As an experiment I switched to R and the language is absolute filth compared to Julia, but I haven't seen anyone complain about bugs (the opposite, in fact) and the packages install fast without needing to ship prebuilt sysimages like I do in Julia. Those are the only two good things about R but they're really important. I think Julia will get there once they have more time in the oven for everything to stabilize and become battle hardened, and then Julia will be a force to be reckoned with. An actually good language for analysis! Amazing!

postflopclarity 1y ago
just to be fair, the very first words in the README for JuliaFormatter is a warning that v2 is broken, and users should stick to v1. so it is not a "subtle" codebase-destroyer so much as a "loud" codebase-destroyer.
- electroly 1y ago
  That's fair, and my bug was in 2.x, but it doesn't really make me feel better. If anything, I feel worse knowing this is OffsetArrays again--the ecosystem made cross-cutting changes that it doesn't have the manpower to absorb across the board, so everything is just buggy everywhere as a result. This is now a pattern. The codebase destruction warning was not super loud, though. Obviously I missed it despite using JuliaFormatter constantly. It doesn't get printed when you install the package nor when you use it. It's not on the docs webpage for JuliaFormatter. 2.x is still the version you get when you install JuliaFormatter without specifying a version. The disclaimer is only in the GitHub readme, and I was reading the docs. What other packages have disclaimers that I'm not seeing because I'm "only" reading the user documentation and not the GitHub developer readme?

currymj 1y ago

for many types of scientific computing, there's a case to be made it is the best language available. often this type of computing would be in scientific/engineering organizations and not in most software companies. this is its best niche, an important one, but not visible to people with SWE jobs making most software. it can be used for deep learning but you probably shouldn't, currently, except as a small piece of a large problem where you want Julia for other reasons (e.g. scientific machine learning). They do keep improving this and it will probably be great eventually. i don't know what the experience is like using it for traditional data science tasks. the plotting libraries are actually pretty nicely designed and no longer have horrible compilation delays. people who like type systems tend to dislike Julia's type system. they still have the problem of important packages being maintained by PhD students who graduate and disappear. as a language it promises a lot and mostly delivers, but those compromises where it can't deliver can be really frustrating. this also produces a social dynamic of disillusioned former true believers.

gugagore 1y ago
> people who like type systems tend to dislike Julia's type system. This is true. As far as I understand it, there is not a type theory basis for Julia's design (type theory seems to have little to say about subtyping type lattices). Relatedly, another comment mentioned that Julia needs sum types.
- pjmlp 1y ago
  It is the same type theory that has powered Common Lisp and Dylan.
  - gugagore 1y ago
    We're not using "type theory" the same way, I think. I'm thinking in terms of - simply typed lambda calculus - System F - dependent type theory (MLTT) - linear types - row types - and so on But it's subtle to talk about. It's not like there is a single type theory that underlies Typescript or Rust, either. These practical languages have partial, (and somewhat post-hoc) formalizations of their systems.

csvance 1y ago

In my experience starting with Julia in 2025, the main thing missing from the ecosystem tends to be boring glue type packages, like a production grade gRPC client/server. I heard HTTP.jl is also slow, but I havn't sufficiently dug into this myself. At least we have an excellent ProtoBuf implementation so you can roll your own performant RPC protocol. As for the actual numerical stuff I tend to roll my own implementations of most algorithms to better control relevant tradeoffs. There are sometimes issues where a particular algorithm is implemented by a Julia package, but has performance issues / bugs in edge cases. For example, in my testing I wasn't able to get ImageContrastAdjustment CLAHE to run very fast and it had an issue where it throws an exception with an image of all zeros. You also can't easily call the OpenCV version as CLAHE is implemented in OpenCV using an object which doesn't have a binding available in Julia. After not getting anywhere within the ecosystem I just wrote my own optimized CLAHE implementation in Julia which I'm very happy with, this is truly where Julia shines. It's worth noting however that there are many excellent packages to build on such as InterprocessCommunication, ResumableFunctions, StaticArrays, ThreadPinning, Makie, and more. If you don't mind filling in some gaps here and there its completely serviceable. As for the core language and runtime we are deploying a Julia service to production next release and haven't had any stability/GC/runtime issues after a fairly extensive testing period. All of the Python code we replaced led to a ~40% speedup while improvements to numerical precision led to measurably improved predictions. Development with Revise takes some getting used to but once you get familiar with it you will miss it in other languages. All in all it feels like the language is in a good place currently and is only getting better. I'd like to eventually contribute back to help with some of the ecosystem gaps that impacted me.