I do worry about the impact of AI on the community, and the viability of Julia as a language of choice. What Mason pointed out about the lack of traffic to Slack’s helpdesk and this forum, can become a real problem in the future if the recruitment potential drops off.
In my neck of the woods, bioinformatics, there is a growing sentiment that we should just use “Rust for everything”, maybe except the top level interactive notebook, and have AI agents write all the Rust for us. Who cares about the two language problem if you don’t write the code yourself? You can see this sentiment echoed e.g. here and here.
It is probably too early to make rash decisions about the future of Julia based on these hypothetical ideas, but I do think it is a real threat to the language. “No code” will not happen overnight, but I do agree that agentic coding alters the relative importance of strengths/weaknesses of programming languages, and Rust comes out better than Julia does.
It’s not that Rust is somehow optimal for agentic coding, but Rust intentionally sacrifices a lot of write-time convenience for better run-time guarantees. Obviously that means that when someone else writes the code, you get most of the upsides and fewer of the downsides.
If Julia were to lean more in that direction, it would probably look like Julia leaning more into static guarantees and opt-in limitations to semantics in order to get latency under control
Again, that might be too early to think about. For now, I do think the noticably increased development speed of the core devs will have a strong positive impact on the language by easing some of the blocks that historically have held people back from using Julia (high latency GC, high latency compiler, lack of deployability, etc).
Who’s going to coordinate all of that agentic coding? Or will each person reinvent the wheel for each new project they’re working on? Seems to me that that is something that can spiral out of control relatively quickly, and leave a huge wasteland of unmaintained packages that were vibecoded for each new project.
However, I do think the threat that AI poses on the Julia community is real. If we hold on to the strengths of Julia, in particular the The Unreasonable Effectiveness of Multiple Dispatch, then I think the damage can be contained. My reasoning here is that multiple dispatch makes packages often ‘just work’ with each other, or at least with minimal effort. And that I believe people would prefer to use something trusted, that also just works, rather than vibecode their own solution. Meaning that relying on multiple dispatch should be lower effort / more comfortable than vibecoding something entirely new.
I understand the hesitancy concerning “rash decisions” and can empathize with the feeling that things are “too early”, but what Keno hinted at in the State of Julia is real: If Julia doesn’t do it someone else will. What I don’t understand is that those things should be “hypothetical ideas”, given that your colleagues already act in the real world.
And that I believe people would prefer to use something trusted, that also just works, rather than vibecode their own solution.
I think the opposite is true: Whatever you vibecode you can trust, where as I see random github packages just as potential malware spreaders, or as supply-chain-attack-in-the-making. (under the assumption that we are talking about security related trust, not necessarily trusting the correctness). Just look at the huge amount of dubious vscode extensions, or the recent npm debacles. Julia would win, if they can reliably offer trustworthy code (= a couple of Julia overlords prompting the development of the entire Julia package ecosystem, with domain expert simply offering prompts in PR).
Almost all companies use github packages. Especially established ones. Even companies like ASML (check their juliacon talks), which need to take extreme security measures to prevent IP from leaking.
I’m quite sure that you underestimate the security related vetting process of SOUP in regulated environment. There is a noticeable difference between in-house written software and some external vibe coded github repo from a single account named “MajorTrustworthy”.
Look at the amount of work hackers spent on backdoor attacks (e.g. xz utils) in the past and now those same actors have the ability to mass produce shiny hooks and disguise them as open-source software library with a real value.
The whole point of open source is that such things happen out in the open, in full visibility.
Right, Veratasium has made an hour long video about it: https://www.youtube.com/watch?v=aoag03mSuXQ where they also interview the people involved. This argument is as old as open source itself, and has been debunked too many times to count. In fact, the last 2:30 of that video Karsten Nohl addresses it directly.
I don’t know which argument you are talking about, i assume the “proprietary software is more secure than open source”, which I didn’t bring up.
Let me make this more clear: I can trust code I prompted (modulo bugs) to not have nefarious backdoors. I don’t trust code from a repo just because of its license. I trust code from open source projects only if they check a lot of boxes.
This is not a sustainable way to do development for a group of volunteers. Who is going to pay AI costs for the overlords to do that work? What if my own needs do not match with what the overlords want to develop? How do we maintain this prompted ecosystem in the long term?
Sorry, this was just the most basic approach of stating a trust boundary for Julia on my side. You could of course develop your packages as you like. I think what I meant is to have an extreme approach on “curated packages” or “batteries-included-on-steroids” .
That’s not remotely plausible. Even if the Julia overlords wanted to do it (which I doubt), there are literally thousands of packages on General, on a huge amount of very niche and technical subjects. No human being can even know what to prompt, to get useful packages on quantum information, astronomy, finite element analysis, optimal control, genetic sequencing, crystallography, etc.
You could ask an AI for the prompts, of course. But if one could actually vibe-code an entire package ecosystem without even knowing the subjects of the packages there would be no point in doing it. We would be in an AGI/superintelligence/singularity scenario, and no humans would be involved with programming or even science.
It’s also just not a good use of LLMs. The thing that current LLMs exceed at to (arguably) superhuman levels is identifying cornercases and exploits in pre-existing, already written software (or proofs / conjectures).
They are good, but significantly less impressive at creating things from scratch.
Thus, if you’re ASML or whatever other big corp with serious security requirements, it makes way more sense to use open source packages, and spend your token budget on vetting whether or not those packages are actually safe to use and contain exploits / backdoors.
To some extents, this idea encapsulate some of the paradox of the current situation.
The fact that the future is made of or include Julia only matters insofar as we care about the community built around it or our ability to use the language itself. If we were strictly after the best most productive tool, then we would look forward to being outgrown and outcompeted by another better one (what’s better than an awesome programming language, if not an awesomer programming language).
And yet, it looks like that for Julia itself to stay relevant and thus justify its continued use, we may have to embrace AI for its development. Which, by itself, limits the relevance of writing code in Julia and the necessity to engage with the community.
I’m not sure about this, but I think it would be good for the Julia community to be intentional in studying and understanding this because there may be some lines of work that become higher or lower priorities now.
I think it is also important to do this in the context of actual use cases. Rust is fundamentally not an interactive analytical language, while Julia excels here. We are seeing a significant difference in agentic use emerge between our software engineers who are doing the kinds of work that can be specified and allowed to run, and our analysts who do more incremental and exploratory work enabled by code. In the past, we saw that VSCode didn’t turn out to be a good interface for analysis work (notebooks are “better”), and we’re now beginning to see indications that raw coding harnesses – e.g. OpenCode – are also not good interfaces. Treating all of this as a single, uniform case is not the way to go; just as Python, Julia and R differentiate from C/C++ (and, frankly, Rust) to largely separate cases, I think we’ll continue to see that with agentic tools.
Perhaps the community should consider a working group to systematically look at all of this; I don’t think forum discussions are going to get us there.
There’s good reason that AI companies are trying to sell models to various experts for groundbreaking work and to the average Hank for making interactive web apps for the millionth time. At the end of the day, the output has to be useful to people, and not everyone knows what is useful or useless in every context.
As a farm boy, this discussion reminds me that when mechanized mowing machines were introduced, that the people that used scythes threw wire in the fields such that the mechanized machines would break and they would retain their jobs. Mechanization has taken over never the less. Except there are old order Mennonites living near-by that go to town and to church in their horse drawn buggies and do all their farming with horse drawn implements.
My son does timber framing and when he needs to erect a building he uses a crane. The farmers of 100 years ago would have called a big party with enough people to erect the building.
There will be parallels here to AI and there will also be differences. I am glad to see people wrestling with the question, and encourage everyone to be the master of AI, and not let it master them. And to have relationship with people that care about them, not with machines.