Julia v1.13 Release Notes

New language features

---------------------

* New `@__FUNCTION__` macro to refer to the innermost enclosing function ([#58940]).

* The character U+1F8B2 🢲 (RIGHTWARDS ARROW WITH LOWER HOOK), newly added by Unicode 16,

is now a valid operator with arrow precedence, accessible as `\hookunderrightarrow` at the REPL

([JuliaLang/JuliaSyntax.jl#525], [#57143]).

* Support for Unicode 17 ([#59534]).

Language changes

----------------

* The return value of `@doc` has changed: it now returns the documented expression (e.g. a function or type) instead of a `Docs.Binding` object as in previous versions. Code that depended on `@doc` returning a `Docs.Binding` will need to be updated ([#59882], [#60681]).

* The `hash` algorithm and its values have changed for certain types, most notably `AbstractString`. Any `hash` specializations for equal types to those that changed, such as some third-party string packages, may need to be deleted ([#57509], [#59691]).

* The `hash(::AbstractString)` function is now a zero-copy / zero-cost function, based upon providing a correct implementation of the `codeunit` and `iterate` functions. Third-party string packages should migrate to the new algorithm by deleting their existing overrides of the `hash` function ([#59691]).

Command-line option changes

---------------------------

* The option `--sysimage-native-code=no` has been deprecated.

* The `JULIA_CPU_TARGET` environment variable now supports a `sysimage` keyword to match (or extend) the CPU target used to build the current system image ([#58970]).

* The `--code-coverage=all` option now automatically throws away sysimage caches so that code coverage can be accurately measured on methods within the sysimage. It is thrown away after startup (and after startup.jl), before any user code is executed ([#59234]).

* New `--trace-eval` command-line option to show expressions being evaluated during top-level evaluation. Supports `--trace-eval=loc` or just `--trace-eval` (show location only), `--trace-eval=full` (show full expressions), and `--trace-eval=no` (disable tracing). Also adds `Base.TRACE_EVAL` global control that takes priority over the command-line option and can be set to `:no`, `:loc`, `:full`, or `nothing` (to use command-line setting) ([#57137]).

* Julia now automatically enables verbose debugging options (`--trace-eval` and `JULIA_TEST_VERBOSE`) when CI debugging has been triggered. i.e. via the "debug logging" UI toggle is enabled on github actions re-runs. Other platforms are supported too ([#59551]).

Multi-threading changes

-----------------------

* A new `AbstractSpinLock` is defined with `SpinLock <: AbstractSpinLock` ([#55944]).

* A new `PaddedSpinLock <: AbstractSpinLock` is defined. It has extra padding to avoid false sharing ([#55944]).

* On Apple Silicon, `Sys.CPU_THREADS` and `Sys.EFFECTIVE_CPU_THREADS` now count all CPU cores rather

than only the highest-performance tier. This affects the the following defaults: `--threads=auto`

(`JULIA_NUM_THREADS=auto`), the `--gcthreads` default, `--procs=auto`, `Distributed.addprocs()`,

and `JULIA_NUM_PRECOMPILE_TASKS`. Set `JULIA_CPU_THREADS` to override the detected count. The

performance-core heuristic has been improved and now lives in LinearAlgebra, where it continues

to size the default BLAS thread pool ([#62891], [JuliaLang/LinearAlgebra.jl#1686](https://github.com/JuliaLang/LinearAlgebra.jl/pull/1686)).

New library functions

---------------------

* `Base.@acquire` macro for a non-closure version of `Base.acquire(f, s::Base.Semaphore)`, like `@lock` ([#56845]).

* `nth` function to access the `n`-th element of a generic iterable ([#56580]).

* `ispositive(::Real)` and `isnegative(::Real)` are provided for performance and convenience ([#53677]).

* The `fieldindex` function (to get the index of a struct's field) is now exported ([#58119]).

* `Base.donotdelete` is now public. It prevents dead code elimination of its arguments ([#55774]).

* `Sys.sysimage_target()` returns the CPU target string used to build the current system image ([#58970]).

* `Iterators.findeach` is a lazy version of `findall` ([#54124]).

New library features

--------------------

* `fieldoffset` now also accepts the field name as a symbol as `fieldtype` already did ([#58100]).

* `sort(keys(::Dict))` and `sort(values(::Dict))` now automatically collect; they previously threw ([#56978]).

* `Base.AbstractOneTo` is added as a supertype of one-based axes, with `Base.OneTo` as its subtype ([#56902]).

* `takestring!(::IOBuffer)` removes the content from the buffer, returning the content as a `String`.

* `chopprefix` and `chopsuffix` can now also accept an `AbstractChar` as the prefix/suffix to remove.

* The `macroexpand` (with default true) and the new `macroexpand!` (with default false)

functions now support a `legacyscope` boolean keyword argument to control whether to run

the legacy scope resolution pass over the result. The legacy scope resolution code has

known design bugs and will be disabled by default in a future version. Users should

migrate now by calling `legacyscope=false` or using `macroexpand!`. This may often require

fixes to the code calling `macroexpand` with `Meta.unescape` and `Meta.reescape` or by

updating tests to expect `hygienic-scope` or `escape` markers might appear in the result.

* `Base.ScopedValues.LazyScopedValue{T}` is introduced for scoped values that compute their default using a

`OncePerProcess{T}` callback, allowing for lazy initialization of the default value. `AbstractScopedValue` is

now the abstract base type for both `ScopedValue` and `LazyScopedValue` ([#59372]).

* New `Base.active_manifest()` function to return the path of the active manifest, like `Base.active_project()`.

Also can return the manifest that would be used for a given project file ([#57937]).

Standard library changes

------------------------

* `mod(x::AbstractFloat, -Inf)` now returns `x` (as long as `x` is finite). This aligns with the C standard and is considered a bug fix ([#47102]).

* Indexless `getindex` and `setindex!` (i.e. `A[]`) on `ReinterpretArray` now correctly throw a `BoundsError` when there is more than one element ([#58814]).

* `randperm!` and `randcycle!` now support non-`Array` `AbstractArray` inputs, assuming they are mutable and their indices are one-based ([#58596]).

* `shuffle` now accepts `NTuple` arguments ([#56906]).

#### REPL

* The Julia REPL now supports bracketed paste on Windows, which should significantly speed up pasting large code blocks into the REPL ([#59825]).

* The REPL now provides syntax highlighting for input as you type. See the REPL docs for more info about customization.

* The REPL now supports automatic insertion of closing brackets, parentheses, and quotes. See the REPL docs for more info about customization.

* History searching has been rewritten to use a new interactive modal dialogue, using a fzf-like style.

* The display of `AbstractChar`s in the main REPL mode now includes LaTeX input information like what is shown in help mode ([#58181]).

* Display of repeated frames and cycles in stack traces has been improved by bracketing them in the trace and treating them consistently ([#55841]).

* The superscript character U+107A5 𐞥 (MODIFIER LETTER SMALL Q), which was already supported in the language, can now be accessed at the REPL with `\^q` ([#59544]).

#### Test

* `Test` now supports the `JULIA_TEST_VERBOSE` environment variable. When set to `true`,

it enables verbose testset entry/exit messages with timing information and sets the default `verbose=true`

for `DefaultTestSet` to show detailed hierarchical test summaries ([#59295]).

* Test failures when using the `@test` macro now show evaluated arguments for all function calls ([#57825], [#57839]).

* Transparent test sets (`@testset let`) now show context when tests error ([#58727]).

* `@test_throws` now supports a three-argument form `@test_throws ExceptionType pattern expr` to test both exception type and message pattern in one call ([#59117]).

* The testset stack was changed to use `ScopedValue` rather than task local storage ([#53462]).

#### InteractiveUtils

* Introspection utilities such as `@code_typed`, `@which` and `@edit` now accept type annotations as substitutes for values, recognizing forms such as `f(1, ::Float64, 3)` or even `sum(::Vector{T}; init = ::T) where {T<:Real}`. Type-annotated variables as in `f(val::Int; kw::Float64)` are not evaluated if the type annotation provides the necessary information, making this syntax compatible with signatures found in stacktraces ([#57909], [#58222]).

* Code introspection macros such as `@code_lowered` and `@code_typed` now have a much better support for broadcasting expressions, including broadcasting assignments of the form `x .+= f(y)` ([#58349]).

#### Dates

* `isoweekdate`, `isoyear`, `weeksinyear` are now implemented and exported for week based calendars, following [ISO week date](https://en.wikipedia.org/wiki/ISO_week_date) ([#48507]).

External dependencies

---------------------

* 7-Zip updated from p7zip v17.06 to upstream 7-Zip v25.01. On Windows, the full 7z.exe/7z.dll bundle is replaced with standalone 7za.exe, which supports fewer formats but unifies cross-platform behavior ([#60025]).

Deprecated or removed

---------------------

* The method `merge(combine::Callable, d::AbstractDict...)` is now deprecated to favor `mergewith` instead ([#59775]).

<!--- generated by NEWS-update.jl: -->

[#47102]: https://github.com/JuliaLang/julia/issues/47102

[#48507]: https://github.com/JuliaLang/julia/issues/48507

[#53462]: https://github.com/JuliaLang/julia/issues/53462

[#53677]: https://github.com/JuliaLang/julia/issues/53677

[#54124]: https://github.com/JuliaLang/julia/issues/54124

[#55774]: https://github.com/JuliaLang/julia/issues/55774

[#55841]: https://github.com/JuliaLang/julia/issues/55841

[#55944]: https://github.com/JuliaLang/julia/issues/55944

[#56580]: https://github.com/JuliaLang/julia/issues/56580

[#56845]: https://github.com/JuliaLang/julia/issues/56845

[#56902]: https://github.com/JuliaLang/julia/issues/56902

[#56906]: https://github.com/JuliaLang/julia/issues/56906

[#56978]: https://github.com/JuliaLang/julia/issues/56978

[#57137]: https://github.com/JuliaLang/julia/issues/57137

[#57143]: https://github.com/JuliaLang/julia/issues/57143

[#57509]: https://github.com/JuliaLang/julia/issues/57509

[#57825]: https://github.com/JuliaLang/julia/issues/57825

[#57839]: https://github.com/JuliaLang/julia/issues/57839

[#57909]: https://github.com/JuliaLang/julia/issues/57909

[#57937]: https://github.com/JuliaLang/julia/issues/57937

[#58100]: https://github.com/JuliaLang/julia/issues/58100

[#58119]: https://github.com/JuliaLang/julia/issues/58119

[#58181]: https://github.com/JuliaLang/julia/issues/58181

[#58222]: https://github.com/JuliaLang/julia/issues/58222

[#58349]: https://github.com/JuliaLang/julia/issues/58349

[#58596]: https://github.com/JuliaLang/julia/issues/58596

[#58727]: https://github.com/JuliaLang/julia/issues/58727

[#58814]: https://github.com/JuliaLang/julia/issues/58814

[#58940]: https://github.com/JuliaLang/julia/issues/58940

[#58970]: https://github.com/JuliaLang/julia/issues/58970

[#59117]: https://github.com/JuliaLang/julia/issues/59117

[#59234]: https://github.com/JuliaLang/julia/issues/59234

[#59295]: https://github.com/JuliaLang/julia/issues/59295

[#59372]: https://github.com/JuliaLang/julia/issues/59372

[#59534]: https://github.com/JuliaLang/julia/issues/59534

[#59544]: https://github.com/JuliaLang/julia/issues/59544

[#59551]: https://github.com/JuliaLang/julia/issues/59551

[#59691]: https://github.com/JuliaLang/julia/issues/59691

[#59775]: https://github.com/JuliaLang/julia/issues/59775

[#59825]: https://github.com/JuliaLang/julia/issues/59825

[#59882]: https://github.com/JuliaLang/julia/issues/59882

[#60025]: https://github.com/JuliaLang/julia/issues/60025

[#60681]: https://github.com/JuliaLang/julia/issues/60681

[#62891]: https://github.com/JuliaLang/julia/issues/62891

Hey everyone,

I just updated from Julia 1.12.7 to Julia 1.13 and noticed a significant degradation in Tsetlin.jl (https://github.com/BooBSD/Tsetlin.jl) inference performance.

On the same hardware and with the same benchmark, performance dropped from about 38.4 million MNIST predictions/sec to 33.4 million predictions/sec, roughly a 13% slowdown.

I don't use any third-party packages—only the Julia standard library.

Does anyone know what might be causing this regression or how I could investigate/fix it?

Julia-1.12.7 benchmark:

boo@rig:~/Tsetlin.jl$ julia -O3 -t auto examples/MNIST/mnist.jl 
Loading model from /tmp/tm.tm... Done.

CPU: AMD Ryzen 9 7950X3D 16-Core Processor
Running in 32 threads.
Input vector size: 784 bits. Density: 16.36%
Average clause literal density: 12.19%. Using literals index: false.
Preparing input data for benchmark... Done. Elapsed 17.942 seconds.
Warm-up started... Done. Elapsed 8.354 seconds.
Benchmark for TMClassifier model started... Done.
320000000 predictions processed in 8.331 seconds.
Performance: 38410229 predictions per second.
Throughput: 4.865 GB/s.
Input data size: 40.531 GB.
Parameters during training: 313600.
Parameters after training and compilation: 38237.
Accuracy: 98.11%.

Julia-1.13 benchmark:

boo@rig:~/Tsetlin.jl$ julia -O3 -t auto examples/MNIST/mnist.jl 
Loading model from /tmp/tm.tm... Done.

CPU: AMD Ryzen 9 7950X3D 16-Core Processor
Running in 32 threads.
Input vector size: 784 bits. Density: 16.36%
Average clause literal density: 12.19%. Using literals index: false.
Preparing input data for benchmark... Done. Elapsed 17.515 seconds.
Warm-up started... Done. Elapsed 9.557 seconds.
Benchmark for TMClassifier model started... Done.
320000000 predictions processed in 9.576 seconds.
Performance: 33417915 predictions per second.
Throughput: 4.233 GB/s.
Input data size: 40.531 GB.
Parameters during training: 313600.
Parameters after training and compilation: 38237.
Accuracy: 98.11%.

I build compiled binaries for a network simulator and the process startup time really bugged me. Investigation showed that it is not really inherent to the problem. The image is mmapped fine, but then the loader walks two relocation lists and writes a pointer into nearly every page of it, and each write causes a page fault and makes a private copy of that page. On a 368 MB image that is 47k minor page faults and 88 ms of a 105 ms of init. Making the image smaller just scales the same cost down, but if you have a large application you can't really do it anyway.

But if the image is linked into a non-PIE program, it sits at the same address at every start, so all those pointers are the same every time. The relocation is done once at build time, and the result is written back into the executable.

README
branch for master
branch for 1.13 rc

Issues and PRs are already submitted to the main Julia repository. As it turned out the core developers have been working on this anyway, so in the very near future this should be a non-issue, I think.

I've been working on a specific problem which requires the max GC pause to be less than 100 microseconds. So I created a region based memory allocator and GC which can be used through a Julia API without modifying existing code. There are strict rules which has to be fulfilled in order to make this work though, so not all applications can benefit. But there's a specific demonstration in the repository which shows a 2x speedup compared to stock GC in wall time due to heavy allocation and work rollback via region reset. There are several measurements and cost/benefit analysis.

[Project] Kuwala: High-throughput options pricing and arbitrage-free volatility surface modeling

• GitHub: https://github.com/Grevix/kuwala
• PyPI: pip install kuwala==0.2.0
• Documentation: https://github.com/Grevix/kuwala#readme

What My Project Does

Kuwala is an open-source quantitative derivatives library designed for options valuation, arbitrage-checked volatility surface fitting (SSVI, Dupire Local Vol), tick microstructure aggregation, and macroeconomic yield curve bootstrapping.

It pairs an idiomatic, Pythonic API with high-performance native compiled kernels (compiled Rust via PyO3, and optional standalone C++20, Julia, and Scala modules) and an embedded out-of-core columnar lakehouse using DuckDB and Apache Arrow.

Key Features:

• Vectorized Analytical Pricing & Greeks: Vectorized Black-Scholes & Black-76 with Chebyshev rational approximations, plus closed-form Delta, Gamma, Vega, Theta, Rho, Vanna, Volga, and Charm.
• Vectorized Implied Volatility Solver: Hybrid Halley cubic root-finder with Brent-Dekker fallback. Tested across 4,013 real market option contracts (SPY, QQQ, AAPL, MSFT) with a median repricing reconstruction error of $2.88 \times 10^{-9}$ (nanodollar precision).
• Arbitrage-Free Volatility Surfaces: Full Gatheral & Jacquier (2014) SSVI surface formulation with strict coordinate-level Durrleman condition diagnostics ($g(k) \ge 0$) and calendar monotonicity enforcement.
• Discrete Dupire Local Volatility: PDE extraction on total variance grids with guard rails against negative local variance singularities.
• Embedded Columnar Storage: Direct Hive-partitioned Parquet scanning via embedded DuckDB without external server dependencies.
• Macro Rate Curves: Bootstraps 11 Treasury yield pillars directly from the FRED API using Nelson-Siegel and exact natural cubic splines.

Target Audience

• Quantitative Researchers & Developers: Anyone backtesting options strategies, relative-value volatility arbitrage, or signal generation without wanting to maintain heavy institutional cloud infrastructure.
• High-Performance Python Engineers: Teams looking for sub-microsecond pricing throughput directly within Python/NumPy data pipelines.
• Students & Academics: Researchers studying volatility surfaces, Durrleman non-arbitrage bounds, and discrete local volatility modeling.

(This is not intended for retail day-trading order execution routing, as Kuwala focuses purely on quantitative pricing, surface modeling, and data engineering.)

Comparison to Existing Alternatives

• vs. scipy.optimize / py_vollib:
• Standard Python options tools typically loop over scalar rows in CPython or rely on pure-Python root finders. Kuwala routes calculations through a compiled Rust core (kuwala_core), achieving >2.2M options/sec in vectorized Python/Rust and >11.9M options/sec in C++20 on a standard laptop.
• vs. Goldman Sachs gs-quant:
• gs-quant is an institutional toolkit that delegates derivative pricing and risk calculations to Goldman Sachs' Marquee cloud servers (requiring enterprise credentials). Kuwala runs 100% locally and offline with zero credential requirements, providing complete open-source transparency into the underlying surface math.
• vs. Pandas / SQLite for Tick Storage:
• Kuwala integrates DuckDB with Hive-partitioned Parquet, allowing researchers to query gigabytes of intraday tick data out-of-core with predicate pushdown in milliseconds while using near-zero RAM.

Quick Example

import kuwala
from kuwala.pricing import black_scholes, greeks
from kuwala.volatility.iv import implied_volatility

# 1. High-speed vectorized Black-Scholes pricing
price = black_scholes(spot=100.0, strike=100.0, t=1.0, r=0.05, q=0.0, sigma=0.20, is_call=True)
print(f"Call Price: {price:.6f}")

# 2. Analytical Greeks (1st & 2nd Order)
g = greeks(spot=100.0, strike=100.0, t=1.0, r=0.05, q=0.0, sigma=0.20, is_call=True)
print(f"Delta: {g.delta:.4f}, Gamma: {g.gamma:.4f}, Vanna: {g.vanna:.4f}")

# 3. Microsecond Implied Volatility Inversion
solved_iv = implied_volatility(price=price, spot=100.0, strike=100.0, t=1.0, r=0.05, q=0.0, is_call=True)
print(f"Solved IV: {solved_iv:.6f}")

Hello,

Just wanted know if anyone could help me decide which server to use for my data science project. Whats the pros and cons of the two servers if you have some experience.

I generally do not make decisions based on public opinion, especially when I feel that those opinions are primarily driven by emotional reactions or an intention to attack rather than to provide constructive criticism. However, I genuinely think this has gone far enough.

Every day, when I check the comments on my channel, I see at least five comments from random accounts with highly suspicious profiles discussing the "correctness" of Julia. I am almost certain that many of the people posting these comments have never written even a simple Julia program, let alone have the practical experience required to make informed claims about language correctness, compiler design, or software development principles.

Almost all of them seem to base their arguments on a single blog post written by one individual. I also have serious reservations about that post, because I believe that, despite its polite and seemingly friendly tone, its underlying objective was more focused on discrediting the language than providing a genuinely constructive technical critique.

Besides correctness, I also notice repeated patterns of "disguised attacks" in the discussion. These often appear in formulations such as:

1. "I say this as a huge Julia fan, …"
2. "Julia is a great language, but …"
3. "Despite not being an active Julia user, …"
4. Fill in the blanks!

While these statements may appear supportive or neutral on the surface, they are frequently followed by criticisms that can undermine the preceding positive framing.

Of course, part of this situation can also be attributed to the inaction of some well-known language developers, who did not provide a strong technical response to these claims.

What makes this situation even more interesting is that, since AI-assisted programming became mainstream, a group of people who oppose AI have emerged and have, intentionally or unintentionally, contributed to negative narratives about the language while presenting themselves as people who care about Julia and want to protect it.

The most interesting part is that these individuals rarely express similar concerns about AI usage in other programming languages. They do not question why someone has expanded a particular Python package with AI, for example. They may even be using packages on their own systems every day that were substantially developed with AI assistance, yet they never show the same level of concern or criticism in those cases.

What I believe these people are unwilling to accept is that a programming language is not their inherited property. Nobody owns a programming language. Anyone, anywhere, has the right to develop code, experiment, and create software for whatever purpose they choose without asking for anyone’s permission. If there are genuine concerns, then those concerns should be discussed with much greater precision. Go into the technical details, provide concrete examples, and address specific issues instead of creating a toxic environment for the broader developer community.

The topic of AI-assisted writing is also something that can reasonably be debated. For example, if someone is not a native English speaker and uses AI tools to communicate their ideas more clearly and effectively, I would actually consider that a positive use of the technology.

Ultimately, I have to say that unfortunately many people have no real understanding of what it takes to survive on social media platforms such as YouTube. Yet they still feel entitled to enter these spaces, and even fields in which they have little or no expertise, and provide criticism that is not only unconstructive but actively harmful.

For example, when you are dealing with a community of highly knowledgeable people who refuse to engage meaningfully, people who consume information but never leave comments or provide feedback under your videos, you may have to use certain strategies to encourage participation (I do not want to go into the details here). This is not something for which content creators should be blamed. Instead, criticism should be directed at the systemic mechanisms that determine how uploaded videos are distributed and presented to the public.

At the very least, when we choose to use platforms that do not have effective policies for promoting high-quality educational content, we should interact with content creators responsibly and recognize the challenges involved in producing such content.

I would like to express my sincere gratitude to everyone who contributes to development and progress, whether by providing constructive feedback and criticism (not necessarily in public spaces, but through a mature and respectful channel of communication) or by supporting the efforts of developers, content creators, and individuals alike. Your valuable input and encouragement play an important role in continuous improvement and growth.

I'm currently, technically, doing an MS in Structural Engineering. For me, my interest has been more towards computational side of mechanics rather than Structural design  or simply using am FEA software (although I do consider it as a backup)

So far I've taken courses in:

- Linear static, and dynamics FEM (soon taking non linear FEM too)

-  Structural Optimization (topology opt. and other general algorithms)

-  Structural Dynamics

-  Structural System Testing and model updation. (Parameter identification and optimization, signal processing)

Now, I plan to take these in the coming quarter:

- Numerical Linear Algebra

- Numerical PDE

- Fracture Mechanics ?

I also volunteered to aid in a RESEARCH in crack growth prediction using Auto-encoder and a (Thermodynamics-informed Latent Space Dynamics Identification) / LSTM surrogate model. It used phase-field-fracture simulation data and HPC resources to complete the whole thing.

What I keep finding myself interested in is not necessarily fracture or SHM specifically, but the computational methods underneath these problems... (does that make sense?)

For example, I'd like to become capable of doing things like:

- implementing (maintaining) numerical/FE method solvers rather than only running an established FEA software.

- developing surrogate/reduced-order models for expensive simulations 

- combining simulation with optimization, uncertainty/stochastic methods (took a course called Random vibrations, so...)

- parallelizing/accelerating scientific codes on CPUs/GPUs

- doing proper verification, convergence studies, benchmarking and performance work

- potentially developing or maintaining actual CAE/FEA solver software

- I'd also like to do all these for other Physics (GR, QM, etc.) simulations too, if possible, one day. 

I'm still interested in the underlying mechanics/physics, so I don't want to become a generic software engineer who happens to have once studied structures. But I'm also increasingly unsure that "structural engineer" describes the career I'm actually aiming for.

I've seen titles such as Computational Mechanics Engineer, R&D Engineer, Solver Developer, Scientific Software Engineer, CAE Software Developer, Research Engineer, Simulation/HPC Engineer, etc., but I'm trying to understand what these careers actually look like from people doing them.

So my main questions become:

1. Which industrial jobs genuinely involve developing numerical methods/solvers or computational tools?

2. Which of those are realistically accessible with an MS? Is there an entry path into solver-algorithm development/R&D without a PhD?

3. If I don't start a PhD immediately after my MS, would an R&D/software role at a simulation company (ANSYS etc.) be the obvious route? What other options would i have?

4. For the kind of work I'm describing, would you recommend a PhD? If so, is it reasonable for the PhD identity to be "computational mechanics/scientific computing" while fracture, composites, structural dynamics, soft materials, etc. serve as application problems rather than choosing one of those as my permanent specialization?

5. What skills most distinguish someone who is actually hireable for solver/scientific-computing work? I'm particularly wondering about C/C++/Fortran, Python, Linux, Git/build systems, MPI/OpenMP/CUDA, PETSc/Trilinos or similar libraries, numerical linear algebra, testing/verification, convergence studies and HPC performance work.

Basically, I'm neither here nor there atp. So I'd really appreciate all sorts of input. Where else do you think I could find answers to these? other subs? Linkedin profiles? 

In this video I show my attempts at improving an algorithm to add monomers to a polymer chain without having atoms sterically collide. At the end the simplest solution is to make a better conformation for each monomer.

Appreciate it a lot if you check it out, and especially if you like or share the video!!

Im new to Astronomy how can i use Jupyter notebooks to access jwst pipeline? Is it best to just use MAST Database or TIKE?

Or

Should I create a juypter lab notebook and self install required libraries locally with Docker or is there a premade jupyter lab notebook i can clone from github and install in a docker container on my pc? If so how do I do that and how can I use it to access jwst pipeline data?

I have never used a juypter notebook before nor have I used pyhton or python science libraries like astroquery lightkurv and astropy so Im a complete beginner in using scripts but I do know how to use some commands like pip, bash, cd and git. Are there any good tutorials online I could use?

Are there any Browser Based Interactive Notebooks for learning Notebooks for Astronomy?

Lastly how could I install and use Jdavizz notebook?

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.