ViralBShah

Startup time for plots is down to <0.5s with Julia 1.9 (in beta).

Two tradeoffs to be aware of:

1. Slightly longer compile times at package install time, but that is ok since it is a one time cost.

2. During package development, building a pkgimage every time will lead to longer compile times because of native code generation. That is easily disabled during development with `julia --pkgimages=no`.

The popular packages are already preparing for this.

While that is an accurate statement, my go-to package where compile time and startup time was a huge hurdle, Plots.jl, just works instantaneously now. That is the case for many packages already, and I suspect that after 1.9 releases, it will quickly become more commonplace.

The Julia compilation model is fairly complex, due to the Julia user's wish for dynamic capabilities combined with common features in statically typed languages.

Although it may appear so, it was not low hanging fruit - it took a lot of effort building incrementally over several releases by a number of contributors.

Correction: It is not that every new issue is triaged on the triage call. Issues are triaged by a group of people with triage access - and the triage call focusses on issues that have the `triage` label.

My comments have been mainly to address the nature of the conversation here and to provide some balance. Specifically, most readers of HN are not deeply steeped in the nature of issues, and the overly broad language in some of the comments can easily give the wrong impression.

It is easy to pick a subset of bugs and weave a particular narrative. You have filed several issues, many of which are still open, and many have been addressed. Thousands of bugs are fixed for every release, including many you have filed - and Julia is better as a result.

Should Julia be better tested, yes it should be. Should we have better tooling, of course we should. Can the triage process be improved, yes. Should code coverage get to 100% - it has steadily increased over time. None of Julia's dependent libraries have 100% code coverage. Many of those projects are even larger than Julia itself. Can every possible bug identified be fixed - we would like to - but eventually there is limited developer time and everything has to be prioritized.

I will once again mention that the triage process is not a secret process. I welcome you to join some of the triage calls to give higher visibility to issues that you feel should be fixed (but are unable to provide PRs yourself for).

It is still planned, but I'll defer to Keno and others to chime in on the details.

If you look at the linked issue, you will see that it is a type intersection issue (a real language issue) mischaracterized as a control-flow bug. Many readers here seem to see that and believe that if statements in Julia are broken - no that is not the case.

I carefully mentioned that the issues (with the exception of a type intersection bug which is in the language, but was characterized as a control flow bug) are not core language issues. Julia ships with a very large standard library, and people often lump all issues in base Julia as "language issues".

I know you have yourself filed dozens of issues, many of which have been fixed. I feel it is unfair to characterize years of work by a community of people as: "Julia does not care about correctness". There's an open triage meeting that happens every other week, where all new issues are discussed and triaged. There is a fairly detailed and well-defined release process. I don't believe people are holding back on filing bugs, because they are waiting for us to solicit.