# Is Julia still as relevant in the age of AI agents?

**URL:** <https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889>\
**Category:** General Usage\
**Created:** [October 7, 2026, 3:51pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889 "2026-10-07T15:51:04Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 7, 2026, 10:07pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/21 "2026-10-07T22:07:41Z")

</div>

> [@austin-putz](#):
>
> today I can easily implement C++ with Rcpp in my R package (only 200 lines so far but more coming). I cannot exactly pinpoint why I should come back to Julia for anything.

I would think you could implement those 200 lines also in Julia with (or without!) AI. And you can already call Julia from R; and with this package it will likely get easier as it already has for Python to call Julia:

> [@\[ANN\] JuliaLibWrapping.jl: bringing Julia libraries to C and Python users](https://discourse.julialang.org/t/ann-julialibwrapping-jl-bringing-julia-libraries-to-c-and-python-users/139150/1):
>
> R and Matlab are likely to follow soon.

> <https://github.com/JuliaInterop/JuliaLibWrapping.jl/issues/19>
>
> Tracking issue for the two unimplemented language backends.
> 
> Matlab is the close…r of the two: \`loadlibrary\` consumes the \`.h\` header that \`CTarget\` already generates, so a Matlab backend is largely a thin \`.m\` façade generator — and would itself exercise the façade machinery (#13).
> 
> R (via \`.Call\` / Rcpp) is more involved.

R is likely next, and AI has been helping greatly recently in the Julia ecosystem as with the MATLAB support (and at JuliaLang and elsewhere), here with 45 commits across 30 files:

> <https://github.com/JuliaInterop/JuliaLibWrapping.jl/pull/90>
>
> A MATLAB backend, from the same \`@api\` declarations as the Python one. Second
> o…f three; the last runs real MATLAB in CI.
> 
> One \`.m\` façade per declaration in a \`+package\` directory, plus a C gateway
> that turns \`mxArray\`s into the carriers and releases what Julia allocated.
> Emitting needs no MATLAB. Every fixture's gateway is compiled in the suite with
> \`-Wall -Wextra -Werror\`, and the emitted \`.m\` and \`.c\` are pinned by goldens.
> 
> \`\`\`julia
> standard\_build(@\_\_DIR\_\_; libname = "boundary", matlab\_package = "boundary")
> \`\`\`
> 
> \## An open question
> 
> Array arguments are borrowed, so a function that writes to one changes every
> variable sharing that buffer. \`duplicate\_arguments = true\` copies instead, but
> it is per build: one mutating function taxes every other.
> 
> | approach | granularity | cost |
> |---|---|---|
> | target flag (this PR) | whole library | one mutating function taxes the rest |
> | \`@api … mutates=(a,)\` | per argument | changes the annotation layer |
> | \`MatlabTarget(…; duplicate=\["f"\])\` | per function | names repeated in the build script |
> | always duplicate | none | gives up the no-copy property |
> 
> Putting it in \`@api\` seem the right place as mutability is a fact about the function, not MATLAB — but I left it out for the same reason we dropped the target field: no consumer, no case in hand. What do you think?
> 
> @timholy Maybe I need to clarify. MATLAB makes copies of everything and has value semantics almost everywhere. To avoid copying too much by default this wrapper borrows, but could have unintended side-effects. So, there is an option to make copies instead, that makes it more MATLAB-ish. But it is an all or nothing approach. The question is, should we make it more granular? if so, how granular?
> 
> \*\*Not in this PR:\*\* running MATLAB. The compile check verifies types, not
> semantics, so \`mustBeVector(\[\])\`, the integer coercion order and finding the
> library at run time want a real gate. That is the next PR.
> 
> Apologies for the scope creep :sweat\_smile: 
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)

I still think Julia is the better language for, and if you’re language agnostic, you might be able to move everything to Julia. AI can probably already do it as has been shown in other cases (in one recent case of large codebase translation by AI for C++ to Julia resulted in 6x speedup):

> [@Julia faster than C++ on a converted large simulation model](https://discourse.julialang.org/t/julia-faster-than-c-on-a-converted-large-simulation-model/139787/13):
>
> It’s about 12k LOC (comments, libraries code and doc removed)  
> I am using Claude Opus 5.5 .. I wasn’t able to squeeze C++ performance the way it could have been possible. I am sure the LLM could do it, but I am not sure I could then read the code. My claim is that doing that in Julia (by myself or by the LLM) is much easier while keeping the code high-level, compact, and readable by a non-expert. At least, this has been my experience.

Now it’s a question of which is the best language.

Depending on exactly what you’re doing this might apply:

> **[The Best AI Models Fail at Physics: Coding Harnesses are to Blame - Blog |...](https://juliahub.com/blog/why-the-best-ai-models-fail-at-physics)**
>
> How the Dyad Harness Turns Silent AI Model Failure into Scientific Rigor

> **Same AI model, different results:** Dyad Agent scored 0.899 versus Claude Code’s 0.533 across four physics problems, at similar cost and runtime.

---

_[View the full topic](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889)._