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.

The issue is not that the bugs are with correctness of multiple dispatch, but that multiple dispatch allows you to combine generic programming with abstract data types. Thus, one can have a generic implementation in base Julia, and someone can pass a new user data type - a combination that can easily not work. Some of the frustration also arises from types such as OffsetArrays that are included in the base distribution, but not as well supported and tested as the regular Arrays type. Thus, the discussion here tends to focus on defining interfaces, and of course on better testing of uncommonly used data types.

In general, we've not had a formal roadmap - but we present a "State of Julia" talk at JuliaCon every year. But very broadly, the list (of the top of my head) includes: improving a lot of the underlying compiler infrastructure overall, improving support differentiable programming, improving garbage collection, support for GPUs from multiple vendors (too many of those now), supporting apple silicon, type system support for tools like JET.jl.

NEWS.md is generally updated during the course of a release cycle, which eventually becomes release notes, and then post release, we put together a highlights blog post. https://github.com/JuliaLang/julia/blob/master/NEWS.md

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.

A detailed discussion is on Julia discourse: https://discourse.julialang.org/t/discussion-on-why-i-no-lon...

Bugs are everywhere - including Python and R libraries. You would not design a safety critical system in Python using libraries and codepaths that are not heavily tested. Even then, you still have to carefully design testsuites that give you confidence that what you are computing is what is expected.

See these talks on how a collision avoidance system was designed with Julia. https://www.youtube.com/watch?v=rj-WhTL_VXE https://www.youtube.com/watch?v=19zm1Fn0S9M

Yuri's criticism was not that Julia has correctness bugs as a language, but that certain libraries when composed with common operations had bugs (many of which are now addressed).

I will recommend following the discussion on the Julia discourse here that is focussed on productively and constructively addressing the issues (while also discussing them in the right context): https://discourse.julialang.org/t/discussion-on-why-i-no-lon...

Just like any other open source project, Julia has packages that get well adopted, well maintained, and packages that get abandoned, picked up later, alternatives sprout and so on. The widely used packages usually do not have this problem. Overall the trend is that the user base and contributor base are growing.

I think Keno's comment above pretty much articulates my thoughts as well. I have met Yuri on several occasions and have been thrilled to see his contributions. I find the post constructive and it will certainly help make Julia better, and hope Yuri will be back at a later date.

Some of the issues linked are JuliaStats issues, and there's a lot happening to improve it, which should become more visible over the next few months. Example: https://discourse.julialang.org/t/pushing-julia-statistics-d...

Julia really pushes on language and compiler design in ways many statically typed languages do not. There is real wok to be done at the frontiers, and also investment in tooling built on top of that. It is all happening. The package ecosystem takes time to mature - Julia has a deliberate release process, the key packages have adopted a more deliberate release process, but stuff out in the long tail naturally tends to move fast - as it should.

Ask them to download Julia and try it, and file an issue if it is not fast enough. We try to have the latest available.

See for example: https://github.com/JuliaLinearAlgebra/RecursiveFactorization...

"Small" is difficult, and it is actually in many cases, harder than "big". Small needs language support, GC support, runtime support, and is delicate - any one thing can throw off performance. You can't hide behind library calls. In Julia, since we can orchestrate everything, from the abstractions all the way down to the instructions, making small problems work well has been possible.

A single grad student can make large problems work (my thesis was large linear algebra and I could just hack away on enough C and MPI to get it done). In our early days on Julia, we realized that 90% of the world actually needs small linear algebra and it is a tantalizingly difficult problem. The work done in the Julia community over the years has made it all possible through a collaboration across lots of different teams and disciplines.

It would be great if you can file an issue. We usually do CI for doctests on base julia itself, and naturally need to do more of it.

In a way - because the original blog post was https://julialang.org/blog/2012/02/why-we-created-julia/

We've done such release highlights for the last 3 releases, and certainly hope to continue!

https://julialang.org/blog/2021/11/julia-1.7-highlights/

https://julialang.org/blog/2021/03/julia-1.6-highlights/

https://julialang.org/blog/2020/08/julia-1.5-highlights/

The SciML tutorials are a good start: https://github.com/SciML/SciMLTutorials.jl

And also the 18.337 lecture notes (probably also has videos available): https://github.com/mitmath/18337

What do you mean by "more" people? Perhaps you mean people who know? Anyone who solves a differential equation in Julia is using the SciML ecosystem of packages. The Julia ecosystem is about 1M users, and lots of people in that ecosystem use these tools.

There's over 100 dependent packages: https://juliahub.com/ui/Packages/OrdinaryDiffEq/DlSvy/5.64.1...

In general, the community has discussed reviving the project (or at least the ideas and some of its codebase). Julia computing will also be contributing as part of that revival.

Modia.jl is built by Hilding Elmquist, Martin Otter and their collaborators. These are some of the best folks in the world - Hilding's thesis in 1978 described equation oriented modeling. It had to wait until computers became powerful enough in the 90s to become broadly usable.

https://people.inf.ethz.ch/fcellier/Res/Soft/Dymola_engl.htm...

We've had the benefit of learning from them and their presentations at JuliaCon and collaborating. More is coming. In the meanwhile - do see this JuliaCon talk by Hilding:

https://www.youtube.com/watch?v=hVg1eL1Qkws

The way to do this is to find non-domain specific tasks in these projects, and make useful contributions to the team - and slowly learning as you go along. Website, CI, benchmarking, helping out new users, pointing out unclear docs, writing a tutorial as you learn, etc. are all great ways to get involved.

Scientific computing has always been around, but as you allude, a bit in the background. It used to be matlab/mathematica on your desktop or a supercomputer that very few could get access to and program. With cloud computing, GPUs, ability to get terabytes of RAM on a single compute node, and all the exciting developments in CPUs despite skirting the edge of Moore's Law - a lot of opportunities are showing up.

You can now simulate science in ways like never before. Today, the median scientist can easily rent a cluster of hundreds of nodes for a few hundred dollars an hour. It is increasingly the case that you can actually simulate entire products in silico before you do anything in the lab. SciML is a large part of that story because we are able to use ML to approximate science and speed it up even more.

I like to think about it as follows - 10x faster CPUs, 100x from GPUs when possible, 100x from ML when possible, 100x through easier access to parallel computing on cloud. So your best case speedup compared to a decade ago is easily 10^7x. Because of this huge space for improvement, we can easily find 1000x improvements in so many cases.

And this is what we as software engineers can do to change the world - by simulating science, building new batteries, designing new drugs, solving power infrastructure, getting climate right and its impact on our cities, food production, and so on and so forth.

Bret Victor captures this really well in his essay: http://worrydream.com/ClimateChange/ and at Julia Computing, we are doing a lot of what it outlines, and really grateful that ARPA-e and DARPA are funding all this hard science and improvements to Julia and its ecosystem.

Thanks for the explanation. I feel that Julia has always been well received on HN ever since we publicly announced it in 2012. I believe that post v1, there are just more users out there and more blogs are being written, more companies are using it, more universities are teaching it, and hence more stories are making their way to HN.

Nowadays, I find new Julia stories and posts when they show up on HN (as opposed to a few years ago when all you had to do was follow juliabloggers).

Julia Computing is about 40 people, and that is a recent thing.

It has been reported that Julia runs just fine under Rosetta.

https://github.com/JuliaLang/julia/issues/36617#issuecomment...

Yes, you can use PackageCompiler for your collection of packages. We are also exploring doing this in the background when you add more packages.

The reason why we can't distribute precompiled .ji files at a package level is because of the way the package resolver works. It depends on the exact versions of dependencies of every package - and even for the same version of an end-user package, there can be slightly different versions of the dependencies installed depending on constraints imposed by other packages.

One major improvement coming in 1.6 is multi-threaded precompilation, and it will leverage all the cores you have.

That's a completely reasonable viewpoint. Many users of Julia and contributors start out experimenting with it and then end up bringing it into their work when they feel comfortable with it. I hope you will have the same experience one day.

Nobody is spinning anything here. Julia's compilation time is a known quantity. See my comment in https://news.ycombinator.com/item?id=24750559 about the different phases of Julia's compilation and execution (from a user's perspective).

Obviously, if you are not working on a problem that doesn't need Julia's speed (and makes it worth paying the compilation cost), and you are more comfortable with a different tool, you should use that. You may in fact be better off using Python, or shell scripting or even Excel.

Precompilation time in Julia is akin to `make` in a project with C code. You only compile the library once and use it repeatedly, until you update it. Is it a dealbreaker? Perhaps it is for you (assuming you are using precompilation in the right context). It is not for many who work with Julia day in and day out, and it is something that we continue to improve.