# 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:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 3:51pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/1 "2026-10-07T15:51:04Z")

</div>

I’ve been away from Julia for several years now, mostly because my company and field doesn’t really use it so implementing it is very difficult when no one will be able to read my code or use my packages.

I’ve been using AI agents extensively (like most I assume), they continue to get better and impress me for data analysis and pipelines.

My main question is the relevance of Julia in the age of AI for scientific computing for people like myself (go with quantitative genetics for now, not exactly but close enough).

Before the main draw to Julia for us was we didn’t have to learn C/C++/Fortran and Julia was much easier. We could get the speed/efficiency we needed without having to deal with pointers and low level “non-sense” (gc and such).

However, 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. It’s also easier than ever to jump to any language like Python if there is a better package ecosystem for certain tasks.

I know this is a sensitive topic on here, but I couldn’t find a recent post asking the same question. I guess I’m feeling more “language agnostic” in this new age. Not a formal programmer so we really have to leverage AI to get things done. I simply have my own tests and have AI write a crap ton of tests for validation and accuracy.

---

<div class="post-metadata">

**Author:** ![yolhan\_mannes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yolhan_mannes/32/220485_2.png) [@yolhan\_mannes](https://discourse.julialang.org/u/yolhan_mannes)\
**Post date:** [October 7, 2026, 4:10pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/2 "2026-10-07T16:10:53Z")

</div>

I think your point only works for “switching to julia” not “going with julia” on a project. So I will focus on the first thing, I guess we never asked anyone to switch from python+R+cpp if they like it, we just make sure we can get the same with only julia, after people choose. So yes python+R+cpp is simpler thanks to AI similarly julia is simpler thanks to AI and has been proven being very good with llm ([[2308.04477] A Comparative Study of Code Generation using ChatGPT 3.5 across 10 Programming Languages](https://arxiv.org/abs/2308.04477)). I don’t think the reason people would switch to julia is only “cpp is too hard” its also a matter of maintaining multiple language, syntax preference, debug experience, very powerful pakages SciML, Optimisation, AutoDiff, ML ect ect.

---

<div class="post-metadata">

**Author:** ![haakon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/haakon/32/42692_2.png) [@haakon](https://discourse.julialang.org/u/haakon)\
**Post date:** [October 7, 2026, 4:17pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/3 "2026-10-07T16:17:42Z")

</div>

In my line of research (weather/climate modeling), I find that AI agents are excellent at turning ideas into rough drafts, and comparing the benefits and drawbacks of these drafts.  
I am almost never, however, satisfied with the initial outcome. And no amount of prompting appears to replace careful judgement of the code.  
Then, I build new features on top of existing code, so the design for what was, matters to the design of what will be. While AI agents are certainly improving their design skills, I never seem to be able to stuff into them all the design goals, tradeoffs, project directions (and non-directions), to make them capable designers. That is to say that, I will need to know myself how to read and write Julia. I wouldn’t be as good if I merely prompted an agent to write code in a language I don’t know.

To your point more specifically, I find Julia excellent for writing backend-agnostic code that is performant across NVIDIA GPUs, Apple GPUs, single- and multi-threaded CPUs. This is substantially helped by Julia’s multiple dispatch, package extensions, and method overloading, in my experience. Backend-specific intrinsics go in extensions, and generic code is written once in the source code.  
Having only a single copy of core code seems to reduce the presence of bugs, and makes it easier and faster(!) to develop new features on top.

---

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 4:20pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/4 "2026-10-07T16:20:26Z")

</div>

Thanks, I agree, I didn’t articulate that well. I just meant “why Julia now when we can do it with other (particularly low level) languages”. The one thing that has been a big complaint I think with Julia is a standalone binary (I know it really improved over the years but not sure the status). Now that we can compile with any language, all we really need to do is build something in R, test it, and push it to C++/Fortran to build a binary for us when/if we need speed at some point.

I guess I’m asking because I want to start a project to solve mixed model equations, I understand Julia has many solving methods, but it likely won’t do since we have different methodology in our field (genomic selection in livestock). These can be millions of animals and efficiency is critical.

The question is then, what is the best language? Before I would have had to start it in Julia as other breeders did in the mid 2010’s when Julia started to develop. But today, why not just go with Rust or another low-level language if I have to program much of it from scratch? Btw, JWAS does exist for this topic written in Julia for this exact reason, they needed speed without the cost of building and compiling C++ all day.

One advantage I thought of is that binary programs are very inefficient, they often repeat operations many times that a scripting language could avoid (e.g. building a relationship matrix for each set of traits). However, this could be avoided by creating different modules I suppose and writing to disk.

Thanks!

---

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 4:24pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/5 "2026-10-07T16:24:55Z")

</div>

Point taken, thanks. I guess without being an expert programmer, I often cannot review the code for quality or design. All I can do is verify the output is correct by writing my own tests by hand or having it validate with tests/coverage/etc.

I’m sure it would help for me to review every line of code, but I’d say for most vibe coders, this is not realistic and the pressure is becoming too high for even software engineers, I think. Open source is great as we don’t have the pressure of companies, academia, etc.

But this is something to consider, if I get better at Julia, I could review the code more carefully myself. I would never spend the time to learn C/C++/Fortran most likely. Thanks.

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [October 7, 2026, 4:26pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/6 "2026-10-07T16:26:56Z")

</div>

> [@austin-putz](#):
>
> However, today I can easily implement C++ with Rcpp in my R package (only 200 lines so far but more coming).

With an LLM, it would be similarly easy to implement the R package in pure Julia, would it not? And if your colleagues don’t know Julia, well, you also said they don’t currently know C++. So what is the benefit? Julia can be as fast as C++ if well optimized, and now there is an LLM for that too.

I would also say there is inherent value in being able to fully understand what a piece of code does. So if you understand your Julia code, but have less understanding of the C++/Rcpp code, then I still chalk up a point for Julia.

> [@austin-putz](#):
>
> The one thing that has been a big complaint I think with Julia is a standalone binary

I know that some people really have a need for _small_ binaries, but maybe in your area it doesn’t matter much. Throw some code into PackageCompiler.jl and see if that fits the bill? But if the sticking point is the compiled binary, then its not “AI making Julia irrevelant”, its more “the need for a binary is driving the choice of language”.

---

<div class="post-metadata">

**Author:** ![yolhan\_mannes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yolhan_mannes/32/220485_2.png) [@yolhan\_mannes](https://discourse.julialang.org/u/yolhan_mannes)\
**Post date:** [October 7, 2026, 4:32pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/7 "2026-10-07T16:32:49Z")

</div>

Lets say you’re the best dev in the world and you understand low level language just as much as AI and you’re very confortable with c++ or rust, you also have a big team able to maintain million LOC with no problem then yes go with those completly.  
Otherwise the way you feel about the language starts to be important and I can’t tell you Julia is better or rust is better it depends which one gives you headeach faster I guess.  
I didn’t want to mix issues, but yes of course if you will need a small binary at the end don’t consider julia for now but its being fixed and I don’t think everyone needs that from their code.  
I don’t really agree with the “if I get a binary it will be faster” thats very wrong in a lot of cases and JuliaC.jl devs keeps saying it because its a hard belief but very wrong too.

Futurist case : We don’t read nor write any code what should I go with ? I guess AI will decide itself what it likes more for your project and you won’t care anyway as long the product is good.

---

<div class="post-metadata">

**Author:** ![BeastyBlacksmith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/beastyblacksmith/32/4741_2.png) [@BeastyBlacksmith](https://discourse.julialang.org/u/BeastyBlacksmith)\
**Post date:** [October 7, 2026, 5:11pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/8 "2026-10-07T17:11:36Z")

</div>

At the point where noone reads the code anyways it is indeed less relevant what code you don’t read.

I guess what is left as a deciding factor is then token efficiency and there is an argument to be made that julia is on average more compact than a combination of a dynamic language and a static language. But I don’t have data on that

---

<div class="post-metadata">

**Author:** ![votroto](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/votroto/32/224436_2.png) [@votroto](https://discourse.julialang.org/u/votroto)\
**Post date:** [October 7, 2026, 6:24pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/9 "2026-10-07T18:24:06Z")

</div>

Mark Seemann has a few relevant articles, such as _Does code quality still matter?_ and _Programming languages for AI_, on his danish software design _ploeh blog_.

---

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 6:37pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/10 "2026-10-07T18:37:22Z")

</div>

Thanks for your response. Yes, you are correct, Julia would be just as easy, but the main factor is that our field still uses R day-to-day almost exclusively. My audience for Julia is very small, but growing slowly. With AI agents, I suppose this is no longer an issue, but users as we are discussing, still want to be able to manipulate the code themselves precisely (certainly in research). So embedding Rcpp is easier for users that don’t need to see how the sausage was made and stay higher level in R.

Yes, I tried PackageCompiler.jl several years ago, perhaps it’s much better now. Just something I considered for the MME software I’d like to start someday. Often calling a binary for a task with a simple parameter file has been desired over some solving packages in scripting languages. Just a quirk of our field I guess. And a way for authors to force people to pay for their package (common for us still).

Thanks for your input.

---

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 6:42pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/11 "2026-10-07T18:42:08Z")

</div>

yes, thanks, I didn’t mean to say it was always faster, just that it can be extremely fast and then not have to worry about incorporating another language into our day-to-day work for users. If users are in R, then telling them to write 2 scripts for different parts becomes a tough sell (I found out). Even if they don’t need to know Julia with agents today, I still feel most are hesitant to adopt a new language. Hopefully, LLMs can make Julia more accessible and I find myself learning things about many languages (even learned more about Julia in a day that used to take me weeks to slowly go through and explain).

And yes, your 2nd part is part of the question… Will it matter at all when no one is reading/writing code? I wanted to know “should I tell my agents to write Julia code” or just let them do whatever they want. Often if it doesn’t matter, it picks Python by default. But knowing enough about different languages let’s me ask the question or force it to use 1 language for some reason. I wanted to know what those specific reasons were for an LLM to choose Julia as part of the main question. I do not know Julia well enough to force CC or Codex to chose Julia over Rust for example… You guys do I feel (but maybe you don’t know Rust well enough either, i dk..).

---

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 6:43pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/12 "2026-10-07T18:43:17Z")

</div>

Thanks, I will try to read these.

---

<div class="post-metadata">

**Author:** ![austin-putz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/austin-putz/32/2583_2.png) [@austin-putz](https://discourse.julialang.org/u/austin-putz)\
**Post date:** [October 7, 2026, 6:45pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/13 "2026-10-07T18:45:24Z")

</div>

Wow, something I haven’t considered was token I/O costs. This seems like it could stack up over a huge codebase. I’m sure someone has looked into this but never crossed my mind. This is something I was looking for when I asked the question. I guess you could argue for speed/efficiency per agent task cost, Julia very well be a top contender. Fascinating.

---

<div class="post-metadata">

**Author:** ![yolhan\_mannes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yolhan_mannes/32/220485_2.png) [@yolhan\_mannes](https://discourse.julialang.org/u/yolhan_mannes)\
**Post date:** [October 7, 2026, 6:54pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/14 "2026-10-07T18:54:08Z")

</div>

If you’re never in need to write cpp and can simply go with Rcpp all the time yes and you have R devs then yes I don’t see a reason to switch same thing if Numpy is enough for everything and you have python dev then yes no need to convert anything but the question shouldn’t be asked anyway. Now if its not enough and you may need to add cpp things to your app, you endup vide-coding it because you don’t know it and none of your dev know it enough either and at the end noone can read the code thats actually the most cirtical performant wise in your app and you must keep vide coding to fix it you may endup with thousands LOC noone can maintain in your app and feel quite bad and endup employing cpp devs too (oh no not them :o just kidding). So, if you don’t care about the size of your app and you know julia then keep your R frontend or even Rcpp and if some part can’t be express with Rcpp or are slow with it then add a julia backend compile it to a dll with JuliaC.jl with or without trimming depending if its possible and you get the same as your cpp backend but with 10x less code and the fact you can actually read it and you can keep the R dev for the less critical parts no issues you made the wrapper like you would with cpp. Also since julia will only deal with the critical part I hope it will be very type efficiant and as such no IO or anything not trimmable and as such wont be that big at the end.  
But for now at least until 2030 don’t add code you don’t understand whatever the language just in case we can’t get the AI where we think it will be.

---

<div class="post-metadata">

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

</div>

There was a post on token usage a while back. Maybe it will offer some insights.

tl;dr - Julia is near top of token efficiency and is ~2x more efficient that C++, which is near the bttom. R is not on the list unfortunately.

> [@Julia is one of the most token-efficient programming languages](https://discourse.julialang.org/t/julia-is-one-of-the-most-token-efficient-programming-languages/134996):
>
> Among the most popular programming languages, Julia is one of the most token-efficient programming languages​.

---

<div class="post-metadata">

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

</div>

I have a good experience with generating code in Julia because of the possibility of reading the code and understanding it. That has been said.

What I would add is that, I have the curiosity, about what happens if you tell an agent to write a Julia code (which is then readable) and then compile it to a juliac library to interact with R? Not necessarily asking you about that, but I would like to know what is the status of that possibility now.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [October 7, 2026, 7:42pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/17 "2026-10-07T19:42:58Z")

</div>

I’ve been wondering about that too. Not for interfacing with other languages but use in GUIs. In GUIs the Julia latency is a killing feature because many things are run only once and per-compilation creates huge files.

---

<div class="post-metadata">

**Author:** ![dmbates](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dmbates/32/44_2.png) [@dmbates](https://discourse.julialang.org/u/dmbates)\
**Post date:** [October 7, 2026, 9:01pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/18 "2026-10-07T21:01:51Z")

</div>

You mentioned mixed model equations and, from other comments by you, I assume that you are looking at mixed models involving pedigrees. I am one of the authors of the [MixedModels package](https://github.com/JuliaStats/MixedModels.jl) which, in its present state, doesn’t fit models with pedigree information. However, we just finished a paper to appear in Journal of Data Science (repo for the paper is [Manuscripts/blockedcholesky at JDataScienceRFP · JuliaMixedModels/Manuscripts · GitHub](https://github.com/JuliaMixedModels/Manuscripts/tree/JDataScienceRFP/blockedcholesky)) deriving the approach in the package and explaining the advantages of Julia for implementing this approach. In short, multiple dispatch is a big win in our implementation. Multiple dispatch was also important in the earlier implementation of the lme4 package for R (the ‘4’ in the name refers to S4 classes and methods which implement multiple dispatch in R) but the Julia implementation gave us much more flexibility in our design.

When you have large datasets performance is determined by the implementation of the numerical linear algebra and, in my opinion, Julia is unmatched as a language for numerical linear algebra. If you look at the end of that paper we were able to save memory on large models by using the Rectangular Full Packed (RFP) representation of a large triangular matrix. In Julia it is a matter of using the [RectangularFullPacked package](https://github.com/JuliaLinearAlgebra/RectangularFullPacked.jl). In other languages it would be much more difficult.

We would be happy to discuss your models offline to see if the approach we described to be applied to your cases.

---

<div class="post-metadata">

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

</div>

My agents use Kaimon.jl to train models with Reactant, export them and serve them with ReactantServer.jl, and then call a test harness to evaluate the model in the context of one of our imaging solutions, all from just a single prompt.

Agentic work flow is quite fast in Julia especially when you take advantage of Kaimon.jl + Revise.jl. The only difference is the agent is driving the REPL most of the time instead of me. Once your REPL is warm the agents actually seem to work faster in Julia than in Python for experimental / iterative workflows because you don’t have to pay the start up time loading PyTorch / numpy / skimage / sklearn, etc etc. Startup time per execution of Python can get quite bad for an agent that needs to iterate through an approach when you depend on a ton of heavy libraries. Statically compiled languages are the worst there.

I’m convinced that Julia is the language for agents when it comes to these sorts of iterative scientific/engineering workflows. I can easily build on and extend others code while actually still understanding how everything is wired together.

---

<div class="post-metadata">

**Author:** ![aerdely](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aerdely/32/37506_2.png) [@aerdely](https://discourse.julialang.org/u/aerdely)\
**Post date:** [October 7, 2026, 9:35pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/20 "2026-10-07T21:35:08Z")

</div>

I think AI has genuinely weakened one of Julia’s original selling points, but not necessarily its most important one.

Ten years ago, a major argument was: “I need C/Fortran-like performance, but I don’t want to become a C++ programmer.” Today Claude or another agent can write a surprisingly good Rcpp implementation for you, so the _cost of producing_ those 200 lines of C++ has certainly fallen.

But the cost of **owning** those 200 lines has not disappeared.

You still have two languages, an interface between them, a build toolchain, debugging across language boundaries, different type systems and memory models, and code that someone eventually has to understand when the AI-generated implementation behaves unexpectedly. Tests help enormously, but tests cannot prove that an implementation is correct.

To me, that is where Julia’s deeper advantage remains. It was never just “C++ speed without learning C++.” It is the possibility of expressing the mathematical/scientific algorithm directly, at a high level, while retaining the ability to specialize and optimize that _same code_ rather than eventually rewriting its computational core in another language.

That advantage becomes much more important as the computational part of a project becomes complicated: custom numerical algorithms, automatic differentiation, simulation, optimization, probabilistic models, parallelism, GPUs, etc. For a 200-line performance-critical Rcpp kernel, I’m not sure it matters very much.

And I think your “language agnostic” conclusion is actually quite reasonable. If your collaborators use R, your domain ecosystem is in R, and R + Rcpp solves your performance problems, I don’t see a compelling reason to switch to Julia just for the sake of using Julia.

Ironically, though, I suspect AI may eventually help Julia rather than hurt it. One of Julia’s disadvantages has always been that it has a smaller ecosystem and fewer Stack Overflow answers than Python or R. Agents reduce some of that friction. At the same time, Julia’s composability and ability to write high-level generic code that is also performant remain properties of the language itself—AI does not make those language-design differences disappear.

So perhaps the question in the AI era is no longer:

“Which language can I personally program?”

AI increasingly makes the answer “almost any of them.”

The more interesting question becomes:

**“In which language would I like the codebase that I—and the AI—produce to live for the next ten years?”**

For some projects the answer will clearly be R or Python. For sufficiently computational scientific work, I still think Julia has a very compelling answer.

Yours truly, ChatGPT 5.6 Sol.

[Next page](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889.md?page=2)