A bit early this month. Enjoy the holidays.
A monthly newsletter, mostly on Julia internals: a biased, incomplete, editorialized list, with contributions from the community. Subscribe by email on Discourse.
Indexing into unicode strings is complicated. Do you want O(1) indexing capabilities or only fast iteration? Do you want to get the byte in the utf8 representation or a unicode codepoint or a self-contained human-readable glyph? Here is a discourse discussion on possible improvements to the indexing API for julia strings.
Each function in Julia is the single instance of a singleton type assigned to it. This permits dispatching in higher-order functions and high-performance functional programming (as methods can dispatch and specialize on typeof(func)). The occasional need to construct an instance of these singleton types is discussed on discourse (with links to previous discussions). Relatedly, there is a desire to add an instancemethods function that gives all methods defined for a function when only the function singleton type is available (skipping the need to instantiate the function).
A discussion on the #internals channel on slack on customizing the compilation of methods by creating your own AbstractInterpreter. (Julia’s compiler & type-inference infrastructure has been evolving to be much friendlier to external modification, e.g. to support Difractor & Enzyme for autodiff or GPUCompiler & StaticCompiler for generating machine code for “weird” targets).
Compilers frequently need hash tables of simple structs (e.g. containing a couple of integers or pointers). There is a neat super-fast super-simple hashing algorithm used in Firefox that then found its way to the Rust compiler, that is now being considered in Julia (see here and here).
A new hasdocs function that checks whether a symbol has a docstring.
Potentially a very exciting development in the compiler that might make it possible to optimize away some array allocations (early-stage and incomplete yet, not yet providing speedup). New Julia programmers quickly learn that avoiding heap allocations is one of the best ways to make your code faster. However, arrays in Julia are always heap allocated because the compiler currently does not know how to stack allocate objects whose size is dynamic and not encoded in its type. See this JuliaCon Einhoven talk on custom allocators in Julia for why stack allocations are fast (and usually not even counted in benchmarks) and why heap allocations are slow. This blog post discusses good ways to benchmark these capabilities.
Better capabilities to study and profile the performance of the garbage collector in Julia here and here.
There has been a longstanding complaint that Julia is using nothing in a way that can be confusing - e.g. a search into a collection might return nothing to represent that the searched-for element does not exist or it might return nothing to represent that the searched-for element is actually nothing itself. This is related to the complaint that Base does not use an Optional type in its API. Anyway, the standard workaround is to use Some and some of the helper methods are getting some improvements to type-stability now.
Using ] add … to add a package to a Project.toml now automatically also provides a compat entry as well.
Compiling into WebAssembly from Julia is getting better and better. Still experimental though.
Fidgeting with the max_methods constant (globally or per module) can let you trade type inference precision for type inference performance (and vice versa). It was globally lowered long time ago. A fun experiment of setting it extremely low was done at the start of the year. Playing with it was one of the core early ideas for optimizing inference performance. Further related ideas about changing the way inference is done can be seen here. Two years ago it became possible to modify max_methods per module so that package authors can fine-tune the inference time-precision tradeoff for their packages.
A pretty wild old discussion on the possibility to change the (rather special) rules for Tuple subtyping comparisons.
Wouldn’t it be nice to be able to write func^n to create an iterated function…
There is some revived interest in profile-guided optimization and link-time optimization for Julia.
A truly wonderful way to add animations of your terminal to Documenter.jl pages with Asciicast.jl
A new string templating engine - Oteraengine.jl. Consider Moustache.jl as another alternative.
For working with repeated decimal notation for fractions, now we have RepeatedDecimalNotations.jl.
A wonderful github CI action to run your tests against oldest possible compatible packages. Provides for a great way to check for outdated lower bounds on your [compat] entries. Used by SciML and other parts of the ecosystem already.
Consider subscribing to the French community newsletter (much of the shared materials are in English).
Consider subscribing to the community calendar to be informed of upcoming virtual meetings and talks.
Consider attending the triage meetings of the julia core contributors (organized on slack) – being a fly on the wall can be a great way to learn the nitty-gritty details of current priorities and development work. These are organized on the triage channel in slack.
The recordings from the JuliaCon Eindhoven talks are online.
Jeff’s talk at JuliaCon Eindhoven was very informative about the progress in ahead-of-time compilation of small binaries in Julia.
Chris’s talk at JuliaCon Eindhove on NonlinearSolve.jl is a great update on SciML’s unification of an API (and a set of best-in-class GPU-capable algorithms) for differential equations, linear solvers, nonlinear solvers, integrators, and optimizers.
A neat blogpost on solving the “N Queens” problem purely in Julia’s type domain (no runtime code).
Start planning about submitting abstracts to JuliaCon 2024 (this time in Europe)
You can engage in the discussion of this newsletter on Discourse