I've been hearing about improvements for the last 8 years. It has been a constant complaint and a constant broken promise.

Since 1.0 it has gotten way better. There's still work to do (obviously) but there has been continual improvement.

I think Jevon's paradox is also hitting to some extent, coupled with the ecosystem getting bigger, so a typical project may have more transitive dependencies behind it. The functionality is going up, and the speed of compilation is going up, but the total latency is staying similar or increasing, in my experience.

that's definitely possible. I'm somewhat hopeful that some changes in 1.9 will let us cut back on transitive dependencies a lot, but it will take a few months to know for sure.

My concern for TTFX is the case when X is something infrequent but sensitive to latency? This a ridiculous example but when it is time for the anti-collision feature on my car to kick in, I want it to run, not compile. I think the right answer is to run a bunch of tests to get all the paths compiled and then build a new system image. But I haven't found a ton of guidance on how to do that. Seems like a perfect pipeline task.

That’s the idea. Here’s an example: https://discourse.julialang.org/t/a-julia-dataanalysis-sysim...

I'm not sure that there's been any "promises" to break. Folks have been saying that it's possible but it'll just take time and effort.

Indeed, every couple of years I try julia again, and every time it's still slow as molasses, all the while being told it's massively improved. One of the most annoying aspects of slow TTFX is when X is your language server. It takes like 10 minutes or something ridiculous for completions to start working after opening a moderately complex file. I had the same experience in vscode and emacs.

For others who feel they've been gaslit by the julia community, this blog post [1] resonated with me, especially the 2022 update.

[1] http://danluu.com/julialang/

Would it not be better at this point to move on?

We bring up these posts every time Julia is mentioned on HN. I've become reticent to respond to these comments. It seems like any response that does not sound like it came from a customer service representative, e.g. "Thank you for expressing your concerns. We acknowledge there are issues, and we are working on it.", will get interpreted as being dismissive or arrogant. I frankly prefer to hear technical responses to the critiques and about how specific issues are being addressed even if they may not be to my satisfaction. Still though, it is important to continue a conversation about this. We should encourage a dialog rather than suppress it.

What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change.

On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow"

On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations.

I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments.

Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts.

[1] https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527