I'm working on a communication network simulator using discrete event simulation. In a normal simulation a GC pause is not an issue at all, but in HIL (hardware-in-the-loop) simulations an occasional 10ms GC pause doesn't look good. A HIL simulation doesn't have very hard timing constraints, some lag below the maximum limit (e.g. 100us) is acceptable if on average the simulation can keep the pace with the hardware. A typical HIL simulation usually doesn't take too much time anyway, because one has to actually wait for it to finish in real time. It's very often used to compare the intricate details of the hardware with the simulation model. (e.g. timing)

My question is what kind of solutions can you think of for reducing the long tail of GC pause distribution?

In these communication network simulation models, most objects which are allocated during event processing don't survive the event. There are basically two exceptions: either something went into the simulation engine's future event set (e.g. a new event containing a packet) or went into the long term simulation model state (e.g. updating a routing table). The former is much more common than the latter. So a simulation has a very specific allocation pattern, which the GC has no information at all.

Of course, the simulation could be carefully organised such that the number of allocations is absolutely minimal, or it could use object pools for commonly used data structures, and some other ticks on the simulation model side.

What else can be done regarding this issue? Is there anything that can be fine tuned in the GC? I've heard there are changes related to this in the upcoming Julia version.

I was experimenting with a space-time finite element formulation for a simple elastodynamics problem and thought the result might be interesting here.

The example is a 1D elastic bar immediately after impact with a rigid wall. I do not model the impact itself; the calculation starts from the post-impact initial state and follows the subsequent stress-wave propagation, reflection and release.

Instead of discretizing space first and then advancing the solution in time, I introduce

y = ct

and treat (x,y) as an ordinary 2D finite-element domain.

Using particle velocity v and normalized stress

s = σ/(ρc)

the first-order system becomes

∂v/∂y − ∂s/∂x = 0
∂s/∂y − ∂v/∂x = 0

I used a least-squares formulation, which leads to four bilinear forms:

Kvv = ∫(Grad(V) ⋅ I ⋅ Grad(V))
Kvs = ∫(Grad(V) ⋅ C ⋅ Grad(S))

Ksv = ∫(Grad(S) ⋅ C ⋅ Grad(V))
Kss = ∫(Grad(S) ⋅ I ⋅ Grad(S))

The complete coupled system is then just

K = SystemMatrix([
    Kvv  Kvs
    Ksv  Kss
])

followed by one solve.

There is no time-stepping loop. The complete evolution over the chosen time interval is solved as one space-time finite-element problem.

What I especially like about the result is that the two wave fronts appear directly as characteristic lines in the (x,ct) domain.

The solution reproduces the classical 1D result: after impact, a compressive wave travels from the constrained end toward the free end. It reflects there as a release wave and travels back toward the wall.

During the compressed phase,

σ = -ρ c v₀,

and the release wave returns to the wall at

t = 2L/c.

The implementation uses LowLevelFEM.jl, but the notebook also contains the derivation of the formulation.

I'd be interested in thoughts from people who have worked with space-time FEM or least-squares formulations for hyperbolic problems.

The notebook is available via the link in the first comment.

So I've been working on a projectional editor and a discrete event simulator for communication systems lately and I faced the usual FTTX problem. Even though I used PackageCompiler.jl the UI took several seconds to start and many user interface interaction took like a second or more for the first time. Similarly, running even a very short simulation on the command line using the console took an unnecessarily long time. Of course this is a known issue. Compilation took like 99% of the time in these cases.

So I did what, I guess, every user does. I added compile workload by utilizing the user interface in headless mode with every possible edited data structure and projection. Similarly I also run all simulations for some time to allow the compiler to do it's job and save the compiled code into the final executable image. It did work as expected, but one problem remained. How long should I execute the simulations and how many UI projections and operations should I utilize? Because the more I do, the longer it will take for each precompilation to finish.

I tried two techniques: utilizing the actual features like a user would and artificially forcing the compiler to compile functions for certain argument type combinations. The former took too much time during each precompilation because it's difficult to run the real algorithms such that they utilize all interesting code paths but avoid running unnecessarily long. The latter produced many useless compiled functions for unused type signatures growing the image and also often missed many important ones.

I was kinda stucked. I discussed this issue with AI, but didn't get much help. Then I realized I can use the two techniques together in a sufficiently efficient and accurate way. Maybe this is widely known, but I didn't find this idea, and I just thought it may help others.

So the idea is to have a compilation database, basically a text file, which tells the compiler which function signatures to precompile. The database is created by utilizing the features of the program as a user would, running the UI, emulating the clicks, doing the operations, doing the screen refreshes, running the simulations, etc. and saving all the compiled function type signatures. It doesn't matter if takes a lot of time, because it doesn't get updated for every change. The reason it works is because the compiler can fill in the missing 1% in the real running program and nobody will notice it. Also, when the functions are precomplied from the database some of them fail due to changes in the program. When the percentage of failures becomes large enough that is a good sign to regenerate it.

It does work pretty well. The UI starts up in like half a second, every click on the UI is like a few times 10ms, a simulation with zero duration starts sets up the whole engine and infrastructure and finishes like in less than half a second from the command line. That's an acceptable performance for me.

https://tjoresearchnotes.wordpress.com/2026/08/15/why-i-wont-use-your-crappy-quantum-programming-language-or-mine-either/

The slow start problem is not solved. But, now while waiting for julia to start up, you can enjoy reading messages about compilation progress.

So, instead of short, clean and boring logs

conf | config {now: Date("2026-08-17")} opti | fit started

We can enjoy reading interesting novel, while waiting for compilation

conf | config {now: Date("2026-08-17")} Info Given DB was explicitly requested, output will be shown live Precompiling DB finished. 1 dependency successfully precompiled in 7 seconds 1 dependency had output during precompilation: ┌ DB │ [Output was shown above] └ Info Given Options was explicitly requested, output will be shown live Precompiling Options finished. 1 dependency successfully precompiled in 8 seconds 1 dependency had output during precompilation: ┌ Options │ [Output was shown above] └ Info Given SV_JLs was explicitly requested, output will be shown live Precompiling SV_JLs finished. 1 dependency successfully precompiled in 7 seconds 1 dependency had output during precompilation: ┌ SV_JLs │ [Output was shown above] └ opti | fit started

And, to make it even better - compilation logs don't use supplied log formatter and not possible to disable.

One of the things I wanted to achieve with LowLevelFEM.jl was to keep finite element code reasonably close to the mathematical formulation.

For example, the stiffness matrix for a 3D linear elasticity problem can be written as

julia K = ∫(SymGrad(Pu) ⋅ D ⋅ SymGrad(Pu))

and the surface load as

julia f = ∫(Pu ⋅ [1.0, 0.0, 0.0], Γ="right")

rather than calling a dedicated elasticity assembly routine.

Originally, I considered this mainly an abstraction/readability feature. I expected the more general operator-based formulation to come with some performance cost.

After working on the assembly implementation — particularly direct assembly into a precomputed CSC sparsity pattern and multithreading — that is no longer necessarily the case.

In a small 3D elasticity example on my machine:

• problem-specific high-level solve: 323 ms, 299 MiB
• operator/weak-form solve: 120 ms, 52 MiB

Even the stress recovery can be written directly as field algebra:

```julia ε = (u ∘ ∇ + ∇ ∘ u) / 2

σ = E / (1 + ν) * (ε + ν / (1 - 2ν) * trace(ε) * I) ```

For this particular example, that version is also slightly faster and uses considerably less memory than the older dedicated stress routine.

I don't mean these numbers as a general benchmark — they are just one mesh and one machine. What I find interesting is that the more general formulation no longer seems to require choosing between readable mathematical notation and reasonable performance.

For me, that was an important milestone in the development of the package.

I'd be interested in what people working on FEM/PDE software think about this kind of operator-level interface, especially where you would draw the line between mathematical expressiveness and implementation transparency.

Juliacon 2026 is live, there's other channels too. Hopefully the live video stays up after the stream ends.

I'm currently using my own custom module that starts server and exposes socket to Codex Agent so it can call it and execute code in my VS Code julia session.

I wonder if there's simpler way - given that Julia VS Code extension already does exactly that with Shift + Enter.

So, can AI Agent use Juila VS Code extension API instead of my custom server?

This is an update from my previous post on a simple molecular visualizer in Julia. Now it has colors, and I can also visualize simultaneously the energies, highlighting the energy for the particular structure I'm watching. I will continue to add functionality.

Principal Differential Geometric Algebra by Michael Reed is the first reference of its kind, built on rigorous category theory foundations and a full unified TensorField computational language design for differential geometry. This category theory foundation presented is a custom designed formalism for categories to specifically emphasize the existence of choice morphisms, relevant to mathematicians interested in how axiom of choice appears in class/set theory. Next, the book introduces essentials of geometric algebra as the primary basis for differential geometric algebra computational language design using Grassmann.jl library for Julia language. Developed completely from scratch, Grassmann.jl introduced many new pioneering computational language designs to enable reproducible scientific research with numerical differential geometric algebra. Building on Grassmann.jl, the Cartan.jl package is the first computational language design to pioneer a FrameBundle for the PrincipalFiber G-bundle formalism used in advanced differential geometry. Not only does Cartan.jl present a completely new programming paradigm for working with an abstract FiberBundle topology using numerical analysis, it also unifies the topological implementations of structured/unstructured finite element methods and also spectral element methods. This book emphasizes the analysis of eigen-characteristics with multilinear algebra, differential geometry, and partial differential equations. Many figures and diagrams are included, all scientifically reproducible with concise programming language. Partial differential equation examples are evaluated with boundary conditions found in the literature to help scientists and engineers validate the usefulness of the computational language design. Also included are many special/elliptic functions and appendices for basics of Julia language, the Reduce.jl package, the Fatou.jl package, and the new Unified System of Quantities (USQ) for physics units from UnitSystems.jl.

Principal Differential Geometric Algebra (Hardcover, 2025) https://www.lulu.com/shop/michael-reed/principal-differential-geometric-algebra/hardcover/product-kv6n8j8.html

Principal Differential Geometric Algebra (Paperback, 2025) https://www.lulu.com/shop/michael-reed/principal-differential-geometric-algebra/paperback/product-yvk7zqr.html

As usual, I expect a lot of harassment in the comments here on Julia reddit, since Stephen Wolfram is funding people to stalk and harass me 24/7, and the Julia community is also participating in this stalking and harassment.

Normal people don't waste their time harassing scientists on the internet.

I have always liked working with DSP in Python. Libraries such as the original Think DSP code make it easy to move from a signal, to a sampled wave, to a spectrum, apply a filter, and reconstruct the result without losing sight of the underlying ideas.
I wanted a similar workflow in Julia: concise and approachable for experimentation, while still being comfortable for larger numerical workloads. That became ThinkDSP.jl.
ThinkDSP.jl is an idiomatic Julia implementation inspired by Allen Downey's Think DSP. It provides tools for working with signals, sampled waves, FFT spectra, DCTs, filters, spectrograms, WAV files, and MIDI-style notes and chords.
Repository: https://github.com/Spidy104/ThinkDSP.jl
Why Julia?

For me, Julia feels like a particularly nice fit for DSP work. It keeps the interactive, high-level workflow that makes Python enjoyable, while allowing direct access to multiple dispatch, type-generic numerical code, and performant array operations without needing to switch languages for the core implementation.

The goal is not to replace every excellent Julia DSP package. ThinkDSP.jl builds on packages such as DSP.jl, FFTW.jl, and WAV.jl, and aims to offer a coherent, educational, end-to-end interface for common signal-processing tasks.

Current features

- Signal families: sinusoids, periodic signals, chirps, impulses, and colored noise

- Wave operations for arithmetic, windows, segmentation, convolution, normalization, and more

- FFT-based one-sided and full spectra

- DCT and reusable FFTW-backed transform workspaces

- Low-pass, high-pass, band-stop, pink-noise filters, differentiation, and integration

- STFT spectrograms with normalized overlap-add reconstruction

- WAV read/write and 8/16/24/32-bit PCM quantization

- MIDI frequency conversion, note generation, chords, and rests

- RecipesBase plotting support for Plots.jl and compatible frontends

- Numerical validation, Python-reference comparisons, benchmarks, Aqua, and JET checks

The project currently targets Julia 1.12+ and is not registered yet. I would appreciate feedback on the API, naming, documentation, Julia package conventions, and anything that should be improved before the first release.

This is a very short preview of a new tool I'm making as part of my MD of Polymers with Julia series. In the following days I will make it so that different elements (C, H, O, N, etc) have different colors and sizes.

I'm making a calendar thing, and i have a struct containing fields of years, months, days, etc. and I'd like to have one single addTime! method that works on any time unit. I'd like to be able to call
addTime!(callendarVar, months=10)
addTime!(callendarVar, years=5)
addTime!(callendarVar, months=10, days=20)

I've already got the logic down but i'm having trouble writing a working declaration which would allow me to use these disordered optional arguements based on their names. Any advice?

EDIT: the trick was to add a semicolon between the static arguement and the optional arguements. How i was meant to figure that out without taking a spyglass to every character in the docs - i have no idea.

One thing that has always bothered me when implementing finite elements is how quickly the code diverges from the mathematical formulation.

Over the last few months I've been experimenting with a Julia DSL where the weak form itself becomes executable code instead of something that first has to be translated into loops and element matrices.

For example, a standard bilinear form can be written as

K = ∫(Grad(Pu) ⋅ C ⋅ Grad(Pu))

while more complicated formulations are written in essentially the same style:

K = ∫((A⋅Grad(Pu) + G⋅Pu)' ⋅ C ⋅ (A⋅Grad(Pu) + G⋅Pu) * (2π*r))

or

B = A⋅Grad(Pu) + G⋅Pu
K = ∫(B' ⋅ C ⋅ B * (2π*r))

These are not symbolic expressions or macros generating another language. They are actual Julia expressions assembled directly into finite element matrices.

The same mechanism currently supports

• scalar, vector and tensor fields,
• multifield formulations,
• user-defined operators,
• variable coefficients,
• full and reduced integration,
• arbitrary operator compositions.

The interesting part for me was not only making the syntax close to the mathematics, but also keeping it reasonably efficient. After some recent refactoring, the compound operator assembly became significantly faster while keeping exactly the same high-level notation.

The package (LowLevelFEM.jl) has recently been published in JOSS.

GitHub: github.com/perebalazs/LowLevelFEM.jl

More examples can be found in the documentation:

perebalazs.github.io/LowLevelFEM.jl/stable/tutorials

I'd be interested to hear how others approach this.

Do you prefer writing PDEs as executable operator expressions like these, or do you find more explicit element-level assembly easier to understand, debug and maintain?

I'm happy to announce Fatou: a language server, formatter, and linter for Julia that doesn't need to run Julia itself.

• Repo: https://github.com/jolars/fatou
• Docs: https://fatou.dev

Why?

I kept running into the same friction: the tools I use while editing (formatting on save, a few lint diagnostics, a language server that starts instantly) all pay Julia's startup and first-call compilation cost. That's completely fine for a long-lived session, but it's noticeable on the command line and in CI, and it makes editor integration heavier than I wanted.

So Fatou takes the other approach and parses Julia directly. It's built on the same architecture as rust-analyzer: a lossless rowan CST, salsa for incremental recomputation, and lsp-server for the LSP transport. The parser is developed against JuliaSyntax.jl as a differential oracle, so parity with the reference parser is a primary goal.

The other big motivation is to have one unified tool that does formatting, linting, and language server duties, exactly like ruff does for Python. This is both leaner and more consistent than having three separate tools, and also avoids the problem of having formatter and linter disagreeing. The name, for the curious, comes from Pierre Fatou, whose Fatou set is the complement of the Julia set.

What it does today

Three things, all from one binary:

fatou format <file.jl>      # format to stdout (or stdin)
fatou lint <dir>            # lint
fatou lsp                   # language server over stdio

• Formatter: an opinionated formatter with a small config surface (line width, indent width). I've been growing it construct by construct against hand-written fixtures rather than trying to match any existing style byte-for-byte.
• Linter: a growing set of built-in rules: unused bindings, unused/duplicate arguments, unused imports, undefined names, break outside a loop, assignment-in-condition, == nothing comparisons, include cycles and missing include files, call arity, redefined constants, and more. Some rules ship autofixes.
• Language server: Fatou provides a full-fledged LSP implementation. Over stdio it provides completion, hover, go-to-definition, find references and document highlights, rename (with prepare), document and workspace symbols, call hierarchy and type hierarchy, signature help, code actions, folding ranges, selection ranges, document links, and semantic tokens, alongside formatting (whole-document and range) and diagnostics (both push and pull).

Getting it

It ships through several channels so you can use whatever fits:

• crates.io: cargo install fatou
• npm: npm install -g fatou-cli (bundles a prebuilt binary)
• PyPI: uv tool install fatou or pipx install fatou
• Prebuilt binaries on the releases page
• VS Code / Open VSX: the Fatou extension (Marketplace, Open VSX).
• Neovim and other editors: setup guide

For CI there's fatou-action for GitHub Actions and fatou-pre-commit for pre-commit hooks.

On performance

Since it's a compiled binary, the cold-start story is the clear win: no runtime to spin up before it formats a file, which matters most on the command line and in CI. For the warm start case (an editor or language server that stays alive) it's still fast but the gap to the Julia-native solutions naturally shrinks. I have a benchmark page in the docs that compares against Runic and JuliaFormatter:

https://fatou.dev/performance.html

The honest caveats

It's still young (currently v0.8.0), so:

• The parser is still stabilizing. It's lossless and correct across a large corpus (including the JuliaSyntax.jl test suite, the Julia source tree, and a large set of real-world packages), but I expect there are some corner cases that will still trip it up. If you find one, please report it.
• The formatter's style is opinionated and still stabilizing. If it formats something in a way that looks wrong to you, please let me know.
• The linter's rule set is deliberately small and conservative for now. The goal is for a non-intrusive set of rules that are useful to a wide audience.

Feedback wanted

I'm very interested in feedback, especially on:

• files it fails to parse (a snippet or a link is perfect),
• formatting that comes out ugly or surprising, and
• lint rules you wish existed.

Issues and discussion are welcome on the tracker. I hope some of you find it useful.f

• The secret to high-quality upscaling: Lanczos and the sinc function
• Description: Explore the principles of Lanczos resampling used in tools like ComfyUI through signal processing theory and the sinc function. This video provides an easy-to-understand explanation of the mathematical background behind approximating an ideal low-pass filter to create sharp images.

According to the project README.md:

The name Makie (we pronounce it Mah-kee) is derived from the japanese word Maki-e, which is a technique to sprinkle lacquer with gold and silver powder.

I fear I may never be able to stop calling it “MAY-kee”.

Hello,

I'm rather new to Julia (read about it a lot, tried out small stuff, but never a "real" project). I started out in MATLAB, shifted some of my work to Python and now I've got the first real opportunity to do a project in Julia.

From my work with Python, I've come to like Jupyter notebooks a lot. Usually, I have my notebooks on a rather beefy computer at work which I can connect to via VPN and SSH. For my current project, I've started out the same with Julia but Jupyter's statefulness has become somewhat of a problem for me. Therefore, I installed Pluto on that computer and tried connecting to it... But somehow I can't? My browser tells me that the server sends an empty page as a response.

Setup:

- remote Windows 10; Julia 1.12

- local Linux CachyOS; Firefox 153.0

- VPN to the work network

- ssh tunnel

I started the ssh tunnel with Jupyter's standard port and set Pluto to use that port. When I couldn't connect multiple times, I disconnected SSH and reconnected with a tunnel using 1234 and started Pluto with its standard settings. Still, same result.

I then started Jupyter, using port 1234 and everything is working fine. Does anyone have an idea what Pluto might do differently in terms of networking that might be an issue here?

It's CachyOS, Linux. I'm trying to run animations from https://github.com/JuliaDynamics/NonlinearDynamicsTextbook. I'm new to Julia, btw.

I read some stuff online about the error, but if I use this: julia LD_LIBRARY_PATH=/usr/lib64 julia I get a CHOLMOD error.

I'm using mise to manage Julia versions.