# Limitations of Julia for AI? Better language(s) for AI, or similar graph-based possible for Julia?
**URL:** https://discourse.julialang.org/t/limitations-of-julia-for-ai-better-language-s-for-ai-or-similar-graph-based-possible-for-julia/139197
**Category:** Offtopic
**Created:** [September 3, 2026, 10:58pm UTC](https://discourse.julialang.org/t/limitations-of-julia-for-ai-better-language-s-for-ai-or-similar-graph-based-possible-for-julia/139197 "2026-09-03T22:58:56Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [September 3, 2026, 10:58pm UTC](https://discourse.julialang.org/t/limitations-of-julia-for-ai-better-language-s-for-ai-or-similar-graph-based-possible-for-julia/139197/1 "2026-09-03T22:58:56Z")
Very intriguing (yes a different language, maybe could be made to apply to Julia):
> **[GitHub - vercel-labs/zerolang: The Programming Language for Agents](https://github.com/vercel-labs/zerolang)**
>
> The Programming Language for Agents
Continuing the discussion from [Idiomatic Julia code in AI generated code](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/9):
> [@Idiomatic Julia code in AI generated code](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/9):
>
> > [@Idiomatic Julia code in AI generated code](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/8):
> >
> > Julia lacks the static checking used for informed speculative decoding and RLVF (Reinforcement Learning from Verifiable Feedback) in other programming languages.
>
> that sentence is a complete non-sequitur; neither of those techniques you’re name-dropping require nor have anything to do with static typing.
RLVR is independent of code, can be used without, but also for (and Julia may be missing out):
> .. empirical study of RLVR for Python code generation on the MBPP benchmark using two small models (Qwen3-0.6B and Llama3.2-1B) with LoRA fine-tuning. Across multiple reward formulations such as: unit-test-only rewards, **static-analysis** -only shaping via the Ruff linter
“speculative decoding” is just for inference speedup, so is “speculative speculative decoding” but I wasn’t sure what role informed had there; I’m glad I looked it up, this seems ingenious, though mainly an optimization
> **[Entropy-Aware Token Rejection for Improving Speculative Decoding](https://arxiv.org/abs/2512.23765)**
>
> Speculative decoding (SD) accelerates large language model (LLM) inference by using a lightweight draft model to propose tokens and a stronger target model to verify them. However, standard SD is mainly designed for acceleration, and its output...
---
### Author:  [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)
#### Post date: [September 7, 2026, 3:23am UTC](https://discourse.julialang.org/t/limitations-of-julia-for-ai-better-language-s-for-ai-or-similar-graph-based-possible-for-julia/139197/2 "2026-09-07T03:23:06Z")
> [@Palli](#):
>
> “speculative decoding” is just for inference speedup, so is “speculative speculative decoding” but I wasn’t sure what role informed had there; I’m glad I looked it up, this seems ingenious, though mainly an optimization
>
> [[2512.23765] Entropy-Aware Token Rejection for Improving Speculative Decoding](https://arxiv.org/abs/2512.23765)
Yep, it’s pretty genius! That’s made it the standard nowadays. The way it relates to static typing (and I believe this has been done for TypeScript) is you use the type information to constrain the draft model, which improves the acceptance rate (since a low-quality model will frequently generate code that’s rejected for having type errors).
Training on linters, static verification, compilation, and so forth is pretty much the standard nowadays (like you said).