Can you offer any specifics? The ToC looks quite extensive, which to me indicates a lot of design decisions needed to be made (probably involving many people) and unclear how that process might be accelerated by AI.
Unless you're suggesting the language design should also be vibed together?
> Unless you're suggesting the language design should also be vibed together?
Sounds like a fun little project, have a bunch of AI pushers fork Zig and see if they can do a better job. I want to see results, not snarky HN comments. After all this progress, ChatGPT should be able to one-shot a better language since AI is so good now... right?
One-shot, no, but there are a bunch of people pretty much solo-building their personal ideal language with AI and it's going quite well. You need to know just enough about language design to be dangerous, but you don't need to be a seasoned pro.
I'm doing it myself: <a href="https://zena-lang.dev/" rel="nofollow">https://zena-lang.dev/
Been thinking about doing this myself (did some PL in grad school but it's been a long time), but I find myself wanting to reach for a Scheme (using macros to grow the language I want) and customize it or build something atop Janet.
Curious why you wanted a more ML / Rust / Scala inspired syntax. (Personal preference here is totally valid btw, just curious.)
It seems like such a strange thing to do, building a language that you aren't going to write by hand. It's guaranteed to perform worse at higher cost, fill up a lot more of the context window, and burn a ton more reasoning tokens.
If you're using AI, a language with a large training set is going to win.
I guess it depends on whether you will write everything in an AI assisted fashion or not. There's benefits to languages that are quick and easy to read by the author even if the LLM is doing the writing, because most code still benefits from human review above and beyond the review that agents provide. Language popularity certainly helps but it seems like for moderately popular languages [1] the cost you pay for a lack of popularity is quite modest.
A language you just created isn't going to be moderately popular, so it's just going to put you at a disadvantage -- and you're not even going to be writing in it, so why the self-kneecapping?
I mean what does "put you at a disadvantage" even mean concretely? To use a less popular language, it means you need to load up context related to the semantics of your language, load context on how to invoke tools to make sure the syntax with your language is correct, load up context related to each tool call you make (which will be more numerous in a niche language), and load up context on architectural decisions that might be specific to your language. All of this is simply a token cost. By forcing a model to load an initial amount of context per harness turn you also effectively shorten the max context window beyond which the model becomes stupid (which itself is much shorter than the max context length.)
Obviously it's not like people are specifically trimming each and every prompt they give a model to tokenmax their models to get the best output / input prompt, we instead live in a spectrum of how many tokens of input and context we're willing to provide to a model to make progress. If the cost of those tokens is low enough for the problem domain you're working in, then it's fine. For some the readability of a personal language may outstrip any of the token costs that one needs to pay to use it. Alternatively maybe you want something like an array language (J, K, APL, etc) which allows array programming and optimizations that conventional PLs just can't do. Maybe you want your language to compile to a target that is highly portable. There's actually a lot of stuff out there that previously wasn't feasible but with LLMs-as-force-multiplier absolutely is.
I also suspect the space is a continuum. There may be pareto optimal points, such as DSLs built atop languages, that are both highly readable but also fairly token efficient.
It's both a token cost and a performance cost; there's only so much that documentation can do, compared to a ton of RL on top of millions of lines of examples. The space is a continuum, but the more you stray from the trained path the higher the cost you pay.
> the more you stray from the trained path the higher the cost you pay.
Note the LLMs are trained on language semantics far beyond the mainstream ones, so language design can become quite exotic without straying too much from the training. You really do have to measure these things, I don’t see how you can make a confident assertion without data.
I don't think those assertions about AI development necessarily hold. And I think it'd be a depressing future if we can't ever have anything new or better that wasn't popular in the training set as of November 2025.
I wrote about some of my thoughts with Zena and AI here: <a href="https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/" rel="nofollow">https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/
I don't think it's particularly sarcastic. Its bitter, of course, because the world we're working towards kind of sucks. I'd like to opt out of it, but it's being forced on me.
The best I can do is understand its edges and try to find some advantage that leaves me well off enough to stave off the worst effects.
But you’re very clearly wrong. Just go ahead and try it: write your own language or just a DSL, write a brief description of how it works , let a LLM use it. Many of us have done this and everyone knows that it works extremely well, to most people’s surprise.
I'd suggest benchmarking the outcomes. It's going to "work", but at a higher cost with worse ontcomes compared to an existing language with a large training set.
I compare one algorithm across several programming languages and backends. There is no training data for Mech in the LLM yet it beats most other implementations in perf, which were optimized by LLM.
Maybe human performance engineers trained in these languages could write better implementations. But to answer the question of whether the LLM could write more performant code in languages it’s trained in versus languages it’s not, this comparison is at least illustartive.
> If you're using AI, a language with a large training set is going to win
Not necessarily? What if the training set contains an overwhelming amount if bad code written by neophytes? I imagine Python quality by the LLM suffers from this, for example.
What if the language has extremely confusing syntax constructs (like early php) or bad or no conventions (suppose the standard library has somecollection.put(key, value) sometimes and othercollection.put(value, key) other times), and individual code authors just pick what they want adhoc
There's a lot of RL that goes into this, you're not just training on bad code. Python is one of the programming languages that LLMs consistently perform best at.
None of these systems can. They need enormous training. They need alignment and reinforcement. They need harnesses. And most importantly they need a human that knows how to write and develop a C compiler.
The ISO specifications are not sufficient. Neither are the System V guidelines. Not even spec tests and compcert.
Claude can one-shot a C compiler just fine. It just won't produce great code. But with all the C code out there in the wild, it won't have a shortage of things to test on, which is mostly what coding agents need to complete a task.
You're not going to one-shot it, but over the course of a couple of months of evenings you could come up with something usable/interesting if you manage the LLM well.
jabedude · · focus · HN ↗
abc42 · · focus · HN ↗
greggoB · · focus · HN ↗
Unless you're suggesting the language design should also be vibed together?
nvme0n1p1 · · focus · HN ↗
Sounds like a fun little project, have a bunch of AI pushers fork Zig and see if they can do a better job. I want to see results, not snarky HN comments. After all this progress, ChatGPT should be able to one-shot a better language since AI is so good now... right?
spankalee · · focus · HN ↗
I'm doing it myself: <a href="https://zena-lang.dev/" rel="nofollow">https://zena-lang.dev/
Karrot_Kream · · focus · HN ↗
Curious why you wanted a more ML / Rust / Scala inspired syntax. (Personal preference here is totally valid btw, just curious.)
spankalee · · focus · HN ↗
0c3ca83 · · focus · HN ↗
If you're using AI, a language with a large training set is going to win.
Karrot_Kream · · focus · HN ↗
[1]: <a href="https://danluu.com/pl-tokens/" rel="nofollow">https://danluu.com/pl-tokens/
0c3ca83 · · focus · HN ↗
Karrot_Kream · · focus · HN ↗
Obviously it's not like people are specifically trimming each and every prompt they give a model to tokenmax their models to get the best output / input prompt, we instead live in a spectrum of how many tokens of input and context we're willing to provide to a model to make progress. If the cost of those tokens is low enough for the problem domain you're working in, then it's fine. For some the readability of a personal language may outstrip any of the token costs that one needs to pay to use it. Alternatively maybe you want something like an array language (J, K, APL, etc) which allows array programming and optimizations that conventional PLs just can't do. Maybe you want your language to compile to a target that is highly portable. There's actually a lot of stuff out there that previously wasn't feasible but with LLMs-as-force-multiplier absolutely is.
I also suspect the space is a continuum. There may be pareto optimal points, such as DSLs built atop languages, that are both highly readable but also fairly token efficient.
0c3ca83 · · focus · HN ↗
cmontella · · focus · HN ↗
Note the LLMs are trained on language semantics far beyond the mainstream ones, so language design can become quite exotic without straying too much from the training. You really do have to measure these things, I don’t see how you can make a confident assertion without data.
itishappy · · focus · HN ↗
When I design my own languages (I have written several, all terrible!) it's typically to learn about language design.
spankalee · · focus · HN ↗
I wrote about some of my thoughts with Zena and AI here: <a href="https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/" rel="nofollow">https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/
0c3ca83 · · focus · HN ↗
spankalee · · focus · HN ↗
What is the point of sarcastic, passive aggressive comments like this?
0c3ca83 · · focus · HN ↗
The best I can do is understand its edges and try to find some advantage that leaves me well off enough to stave off the worst effects.
brabel · · focus · HN ↗
0c3ca83 · · focus · HN ↗
cmontella · · focus · HN ↗
<a href="https://mech-lang.org/iros-r4r-2026/index.html#58054068114627774" rel="nofollow">https://mech-lang.org/iros-r4r-2026/index.html#5805406811462...
I compare one algorithm across several programming languages and backends. There is no training data for Mech in the LLM yet it beats most other implementations in perf, which were optimized by LLM.
Maybe human performance engineers trained in these languages could write better implementations. But to answer the question of whether the LLM could write more performant code in languages it’s trained in versus languages it’s not, this comparison is at least illustartive.
dnautics · · focus · HN ↗
Not necessarily? What if the training set contains an overwhelming amount if bad code written by neophytes? I imagine Python quality by the LLM suffers from this, for example.
What if the language has extremely confusing syntax constructs (like early php) or bad or no conventions (suppose the standard library has somecollection.put(key, value) sometimes and othercollection.put(value, key) other times), and individual code authors just pick what they want adhoc
Large training set ain't gonna save you.
0c3ca83 · · focus · HN ↗
dnautics · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
agentultra · · focus · HN ↗
None of these systems can. They need enormous training. They need alignment and reinforcement. They need harnesses. And most importantly they need a human that knows how to write and develop a C compiler.
The ISO specifications are not sufficient. Neither are the System V guidelines. Not even spec tests and compcert.
int_19h · · focus · HN ↗
IshKebab · · focus · HN ↗
DASD · · focus · HN ↗
IshKebab · · focus · HN ↗
UncleOxidant · · focus · HN ↗