Our great sponsors
-
-
DifferentialEquations.jl
Multi-language suite for high-performance solvers of differential equations and scientific machine learning (SciML) components. Ordinary differential equations (ODEs), stochastic differential equations (SDEs), delay differential equations (DDEs), differential-algebraic equations (DAEs), and more in Julia.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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
This lists some of its unique abilities:
https://docs.sciml.ai/DiffEqDocs/stable/
The routines are sufficiently generic, with regard to Julia’s type system, to allow the solvers to automatically compose with other packages and to seamlessly use types other than Numbers. For example, instead of handling just functions Number→Number, you can define your ODE in terms of quantities with physical dimensions, uncertainties, quaternions, etc., and it will just work (for example, propagating uncertainties correctly to the solution¹). Recent developments involve research into the automated selection of solution routines based on the properties of the ODE, something that seems really next-level to me.
[1] https://lwn.net/Articles/834571/