This month in Julia world - 2024-10

A monthly newsletter, mostly on julia internals, digestible for casual observers. A biased, incomplete, editorialized list of what I found interesting this month, with contributions from the community.

“Internals” Fora and Core Repos (Slack/Zulip/Discourse/Github):

Compiler Internals:

Garbage Collector Internals:

Dustbin of History:

  • For those interested in archeology, this is not the first attempt to run a julia newsletter.

In search of contributors and new maintainers (specify novice/moderate/expert and internals/domain background necessary):

Ecosystem Fora, Maintenance, and Colab Promises (Slack/Zulip/Discourse/Github):

  • Tensorial is a great new package for tensor math. Also discussed on slack, including in terms of how it compares to other Julia tools.

  • A wonderful new docstring linter for julia: CheckDoc

  • New experimental package to check that a struct is defined with inferable concrete types: CheckConcreteStructs

  • Fun workarounds for broadcast nesting and general discussion of broadcast hacks on slack.

  • Hackable belief propagation algorithm implementations in Julia: BeliefPropagation.jl

  • CodingTheory is a new package built on top of Oscar for work with classical and quantum error-correction codes.

  • Another magic trick from Lilith: having your Julia session lazily autoload commonly used packages BasicAutoloads.jl

Julia Autodiff ecosystem (enough topics for its own category this month):

  • The DifferentiationInterface.jl (DI.jl) repository has been transferred to the JuliaDiff organization to ensure continued maintenance.

  • DI.jl: A breaking release v0.6 was tagged. Thanks to recent changes, it is now possible to pass non-differentiated arguments (first constants, and soon caches/buffers) to the function, in addition to the one active argument.

  • DI.jl: Testing for StaticArrays has been drastically improved and allocations have been nearly eliminated with ForwardDiff & forward mode Enzyme for functions working on SArrays. There’s some concern how sustainable this is though, as the sensitive and fragile performance requirements for most StaticArrays use cases may be very easy to break in one or multiple backends.

  • DI.jl: Mainly for fun, we tried to interface DI with JAX in DifferentiationInterfaceJAX.jl. There is still some overhead from Julia-Python tensor conversion with DLPack.jl, any help is welcome.

  • Reactant.jl can take a Julia function, compile it in MLIR, do a plethora of optimization and autodifferentiation tricks on it, and compile it to a very wide variety of accelerators.

  • What does compile in ReverseDiff mean?

Notes from other ecosystems:

Soapboxes (blogs/talks):

Please feel free to post below with your own interesting finds, or in-depth explanations, or questions about these developments.

If you would like to help with the draft for next month, please drop your short, well formatted, linked notes in this shared document. Some of it might survive by the time of posting

83 Likes

Keno doesn’t fail to impress me.

As I thought of having generalized metaprogramming become a documented feature, well Keno has a plan on that.

The interface proposal seems quite okay to me, though its functionality as proposed would be limited to preventing method errors as opposed to guaranteeing correct behaviors that some languages have (which might depend on, for example, to be able to express that f(a,b) = f(b,a), which could theoretically be doable even if not in the current patch plan)

As for the world age, I don’t understand much, but given some useful things, I’m interested in it.

Other stuffs are awesome too.

I’m seeing a bright future for Julia.

1 Like

The proposal here is to allow the creation of “subpackages” that are namespaced under the “main package,” with their versions locked to that of the main package. To bump the version of the entire “ecosystem,” you would only need to update the version of the main package.
The subpackages would:

  • Be individually loadable, for example, with using OrdinaryDiffEq::AdamsBashforthMoulton (syntax subject to change).

I prefer smaller independent packages and don’t miss importing subpackages in Python, but sometimes an install does get big enough to justify it, and here it sounds like there’s also an option to load everything. A very enticing possibility is a “main package” that just collects independently developed packages that are often used together and are confirmed compatible for those versions. Besides the convenient install, I’ve seen a few newcomer complaints that useful packages are scattered and incrementally discovered, and I have to agree that any informal recommendations quickly go out of date with no indication; a package would at least show the versions.

2 Likes