maybe more like an ecosystem around a framework implemented in multiple language SDKs, here are two I use

https://adk.dev/

https://docs.dagger.io/reference/sdks

both can invoke modules written in other languages from your language of choice

Kubernetes is likely an interesting ecosystem to consider under this lens too

Platforms and programming systems, e.g. Beam.

Once you get into the third party

year, that's usually what is referred as ecosystem.

Because human review is a serious bottleneck and optimizing something that isn't the bottleneck isn't helpful

Yes, because that code was never written to be understood by machines, merely to be mechanically translated. Software is a very messy set of layers of leaky abstractions trying to express reasonably well defined ideas. Humans can't write code without mistakes, in spite of all the examples out there. If they could compilers wouldn't have to emit error messages.

Right on every count except that it needs to be bad for people

LLM's are trained on human code though. Converting the code to its ast tree and training ai on that would be trivial of course, but I imagine there would be information that explains why something exists that would be missed.

I agree. But I'm very sure that it will happen. AI the way we have put it together now will be tempted to create new languages whenever they communicate to optimize channel use.

That's what a good amount of people are doing, including in the Elixir ecosystem (where Jose Valim, the author of OP, mainly resides): build graph/vector DB-based code indexers and finders. LLMs seem to deal with those well and take less turns to give an answer or even find and address a smell.

We also need a metric ton of opinionated linting to sheep-herd codebases into a smaller amount of possible shapes -- which I'm strongly in favor of and see it as the next iteration (of the concept of a single code formatter a la Rust) because it'll put many other bikeshedding time-wasters to rest, hopefully forever.

To be honest though, it's mostly hypotheses and feelings; nobody has truly figured it out yet -- and if some have, they're keeping the secret sauce to themselves.

AI negates language specific ecosystems ... Pick whatever your favourite programming language is and its ecosystem

I think this is only true when it comes to LLM raw output. There's also the concern of checking its work. A compiler that can check many aspects of correctness (static types, null) is a huge boost to AI. It can use the compiler directly to check its own work.

Explaining the additional features as bits of other languages is exactly what helps LLMs:

"Dart-style constructors, Swift-style pattern matching and Strings, Trio-style async cancellation, Scala-style sealed classes"

This keep getting repeated. So were just stuck with whatever we have at the point of training the magic plagiarism machine?

The future is cooked

You should have working programs that demonstrate the features you want them to use, and then the skills. Working programs they can mutate in an RL gym.

It might seem obvious but in truth is not - to be honest, a strictly typed language where models can play adversarial competitions against a strict compiler/linter does have advantages, as mentioned in the article itself but that's not related to training size, the advantage is exactly that it can generate synthetic useful data due to compiler/linter guarantees - regarding training size as long as some logic showcasing the constructs exists that is all that is needed. If you have 2 correct examples for each feature or language construct then the probability of the a LLM learning it and applying it is very much guaranteed, if you have thousands of diverging uses of patterns and constructs in the training data (with a lot of bad examples or wrong uses) a LLM might, I dare say will, actually perform worse, since the probabilities of what particular variation being the "correct" one to use are all over the place.

What can happen is sometimes patterns that are unique to certain languages aren't surfaced and so can't be "learned" but that is a different case, since you can add examples - or patterns that go beyond syntax (threaded code, process isolation, interaction between different modes of resolution, etc) where you need the agent to be able to understand and plan higher-level logic.

I wrote CSSex as a css pre-processor (similar but not the same as SASS/SCSS) and my "boss" at the time fed the existing cssex files to GPT (+2 years ago) and it was able to write CSSex just as fine as if it was writing something that was present in its training data set. It never introduced syntax bugs, the bugs it introduced were all relative to complex cascading styles rules in an existing large (for a definition of large in webapps) codebase, rules interactions (CSS), browser quirks, and complex logic to do what we "humans" wanted (or him in this case) and so on.

True, it’s also trained on millions of papers of programming language research, so you can write a language to operationalize that research and it does great with it. The millions of lines of typescript scaffold the syntax, the PL papers scaffold the semantics.

Agree, new language will not suitable for LLM because there is not enough documents about it on the internet. LLM should learn the usage of the langauge from documents. Yes, it can use new language but it's not natural as existing(which have a lot of documents) languages. So my opinion is language is no matter anymore. Just prompting(describe the spec) matters. And there is babo language for this. https://github.com/armbox/babo

They should find the limitation of the natural language somehow, and use and distribute babo language will help find how it will works(or not). LLM model eveolves yet, so there is no such a approach, but the speed of evolution is decreased lately. So now is good time to dig into identify the limitation and boundary of the LLM.

This is absolutely not the case in my experience. I am building a very large embedded domain specific language for describing distributed systems. It looks like a small subset of Elixir, but with object-oriented syntax in a lot of places. (It’s called a choreography; there exist many other choreographic programming languages.)

Even though this programming language is absolutely nowhere in any large language model’s training set, they have so far done extremely well at extrapolating from the small set of examples I’ve given it when I need an agent to generate some tests or whatever for me.

Alternatively, this might accurately identify Chinese models so you can avoid them if that's your goal

Personally I don't have much interest in using models that blatantly censor historical facts.

Tiananmen Square is an obvious one but I would be concerned that any model that censors that would also have other hidden censorship or more subtle biases I wouldn't catch

Native compilation should be doable already with a Wasm compiler like Wastrel.

One reason I haven't explored that is that I want to tailor the language for the more constrained environment of Wasm GC first.

Why not languages that are designed in that way, like Ada. Or if one wants less of rigidness then a static typed language that makes it hard to shoot in your foot like Rust,Java, C#?

JS derivatives are that, a derivative to a scripting language.

Ironically, since AI can build an STL and tooling (up to a full OS!), I think now presents an opportunity for a language that does start from scratch, at least targeting hobbyists (besides those specifically looking for novel languages).

Please do the world a favour:

integer literals become i32, float literals become f32

Don't use the shitty small sizes that have introduced countless bugs over the last decades, as a language default.

Especially if you care about correctness.

i32 is all over the examples.

Use 64 bits, like Python and Haskell; even JavaScript and thus TypeScript got floats right defaulting to f64.

Languages for AI era should be more explicit so reviewers can read it faster.

Are they changing or converging? If you can pinpoint where they are going you can get there before they do.

The semantics they are trained on include latent representations of the world that are superior to any pre-existing PL corpus. That is my guess and it's not any less rigorous than your guess.

Even when no(human)body is reading the code, AI is still reading the code in order to "understand" it. Languages that can express high level concepts, use structured programming for recognizable control flow patterns instead of inscrutable jumps, and assign names to things have the same benefits for the AI-coders and AI-reviewers that they always have for humans.

Definitely a reasonable thing to consider and this is the direction I would like to see programming languages evolve towards in the AI era.

Move errors from runtime to compile time as much as possible.

I think that's just extra detail on the _degree_ of human responsibility depending on the environment. Even in what you suggest, if something goes wrong, who's responsible? AI are not persons in our society; the IT-architecture/cyber security expert is ultimately responsible for the code, regardless of how it's written.

Machine code isn't especially expressive per line or unit of code. Lower level languages takes up more of an LLM's context than higher level ones.

To be effective in using low level languages, LLMs would have to build higher level constructs like subroutines from scratch every program.

It's not that different from why we almost never use assembler for anything more than code islands: even a modest subroutine can overwhelm our own mental context window.

I’ve reimplemented some python science code into rust using LLMs and it absolutely works well if you setup the criteria for done. In my case it was GIS-ish code so a key requirement was identical in/out pairs at 10k points across CONUS. It worked, and when it didn’t it showed up bugs that the agent would go and research, read up on other implementations, then try again.

Net result faster (10-70x) and massively lower memory footprint. Now we’ve got a service that can do something essentially instantly that most people wouldn’t have even bothered to try before.

Have you managed to run this locally? If yes, how'd you do it?

I'm keen to run it.

dOctument?

Concept sounds neat is that the name or a working title? I see there’s 50/50 go/zig code, so you have a reference zig compiler and a go compiler? LLMS are neat that they can port compilers to new ecosystems, but I’m wondering what prompted that change, because even if it’s LLM assisted it’s not always an automatic task.

That’s an interesting idea about an aromas transition, I’ll have to think about that. I put state machines in the language for better static program analysis and tracing, I think the aromas idea could complement that. What do you see as the main utility?

Have you written about your work anywhere else?

This is a mascot I commissioned from an artist I know.

It's a nautilus. If I remember correctly, the original idea came from `gyre -> spiral`, so I attached meaning to the spiral shape of its shell.

The reason gyre ended up in the name was that I had this idea that a world, or perhaps a program, keeps curling inward through layers.

At the time, I was studying state machines. Once you define a state machine, you also define its state space: how far that space can expand, what states are possible, and where its boundaries are.

But the more I programmed, the more I felt that software kept repeating the same structure inside itself. You establish an outer boundary, then inside that boundary you create another state space and another boundary, and then another one inside that.

So I started wondering whether a program is something that begins by defining an outer frame and then keeps spiraling inward.

When I first started designing the language, one of my biggest inspirations was D&D.

That's partly why I chose words like `ability` instead of `interface` or `trait`. The idea was closer to, "this subject must have this ability," rather than "this type implements this interface."

I like fantasy games, and most RPGs tend to describe their worlds using fairly similar concepts and vocabulary.

Around the same time, I was reading material about Simula 67. What interested me was the old question behind Simula: how do you represent a world using a programming language?

When humans describe worlds, we probably do it most extensively in fiction and games. So I thought: why not build a programming language using words humans already use when describing a world?

I started collecting those kinds of words and turning them into language concepts.

Originally it was just a small language with a C backend. Then AI arrived, I became more ambitious, and the project gradually grew much larger than I initially intended.

So there is a `World`, and inside the world there are `Zone`s. At first I considered using `Realm`, partly because of D&D, but in Korea people tend to use the word "zone" much more naturally for this kind of spatial division, so I ended up with `Zone`.

The project has grown quite a lot since then.

It's still incomplete. The source of truth for the semantics is not fully closed yet, and there are many rough edges, although I've confirmed that at least some of the basic ideas actually work.

I'm also trying to make it a memory-safe systems language without relying on a GC.

One of the inspirations was Vale, an experimental language that explored generational references. I took that idea and tried to expand it into something broader: in Pergyra, I think of a `Slot` as a resource identity, and the compiler tracks transitions in the state of that resource. (Vale itself seems to have moved away from that approach in its successor, Valen.)

The compiler pipeline is roughly:

`HIR -> DIR -> RIR -> MIR -> backend`

At the RIR level, memory accesses are interpreted as resource-state transitions, and resource operations are normalized there.

This does mean that Pergyra can carry more runtime machinery than some other systems languages when those checks cannot be eliminated. On the other hand, the same resource identity model has been useful for reasoning about parallel access and concurrency.

I still don't think I can honestly claim that the language is completely memory-safe yet, and I'm not even sure whether this approach will ultimately turn out to be the right one.

But as the design evolved, I noticed the same spiral structure appearing again:

`World -> Zone -> ... -> Slot`

The layers keep curling inward.

That's why I chose the nautilus.

There's another meaning I like as well: the nautilus is often described as a "living fossil," and in a way I'm taking an old question from Simula — how should a programming language represent a world? — and trying to revisit it from a different direction.

I don't really expect the language to become successful. I'm not even sure I've written the compiler particularly well. I'm currently using it in a few small projects to see whether the ideas survive contact with real software, but I don't know how far it will go.

Thank you for taking an interest in it.

My personal goal, though, is much simpler: I want to make a game in my own language.

I think that part is probably achievable within the next two years.

The answer was already visible in the previous attempts of 4 GLs, UML tooling with RUP, low code/no code tooling.

Some of us now have to deal with tools like Boomi, Workato, Opal, Sitecore AI, Power Platform,....

Eventually some microservices might be written in "legacy" languages for MCP tools.

This is how "programming languages" look like in 2026 for internal corporate development.

I’d love for language environments to support encouraging LLMs to specify more when they write code. Why should they first write a complex function or a class and later bolt on a test?

I’d love for a class in this future language to come packaged with tests, invariants, fuzzer parameters, profile targets / performance budgets with realistic inputs (on this 100 element array this should take no more than X clock cycles), race condition stress tests etc.

The compiler (or even linter) should optionally run some / all of these checks and succinctly report back (with knobs so the LLM can manage wall clock time).

Adding each of these should not be follow on steps.

Beyond this, debug hooks should be trivial to set (in code itself), so the LLM can trivially say show me the stack after the 9th time this function is called on this input to the program.

I've been building something in this direction for a year across many iterations and explorations: https://dziban.net/posts/yabu/ and https://kinoko.sh

There is such a wide range of interesting things that can happen here that we aren't exploring at all.

Yeah. I have my own file formats for music, pixel art, and levels in a little game I’m building with the kids. LLMs are really good at understanding these proprietary formats that exist nowhere else in the world except on my old laptop.

I used an LLM to write assembler in my made up API so I don’t think what you say is true.

I think you are underestimating the amount of data/context that is required to use a battle tested general purpose language, for both humans and LLMs. The ecosystem requires official docs, stack overflow answers, blog posts, tutorials, existing source code, subreddits, issue/PR discussions of undocumented features, obscure mailing list threads with rare insights, books, youtube videos, benchmarks, tests suits... and the ecosystem of libraries for the language that also need their own official docs, stack overflow answers...

You also need the collective audit by the community and assurance that this language has been used in production by countless others.

The frontier models are exceptionally good at one shoting rust. I find them to be even better at writing rust than python (and the dataset for python must surely be bigger). I think there might be a threshold of enough data for a programming language to make it useful for an agente

I've been playing around with a new DSL, and I've had good luck adding a "describe" feature, eg,

  newdsl describe some_feature

This returns the docs for that language feature. So instead of a giant SKILL.md containing the language spec, it exposes a way for an LLM to introspect.

DSLs climb the ladder of abstraction and constrain the solution space at the language level, which IMO provides tighter feedback to both humans and machines.

Tremendous amounts of the Java out there in the training corpus would be based on outdated patterns, especially anything pre-Java 8 or pre-Java 21 (Pattern Matching, Project Loom). I don’t think this negatively impacts the quality of LLM Java code but it sort of calls into question whether this is simply a case of more is better.

My personal experience is that LLMs are quite good at one-shotting complex solutions in both Rust and Go, and tend to be idiomatic.

Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.

This makes sense and is very insightful, thank you. But with that solution it seems that only LLM companies will be in the position to create new languages.

The Language Server Protocol is designed for advanced text editors (IDE’s). Now that we rarely edit text by hand, I believe we could instead use source code viewers that don’t have to deal with unsaved or incomplete code.

If we can assume that all files are saved and each file has correct syntax (which can be enforced by tooling), a much simpler protocol could handle all the language-specific indexing needed to make it easy to read source code.

(I’m assuming that we still do read source code. I for one like reading source code and have little interest in ‘software factory’ techniques where you don’t look at at the code. I might not look at every commit, but I’ll still read it fairly often and tell the AI to fix anything that’s unclear.)

console games were stagnant before sony opened the market. open source compilers meant many more people could write c/c++ without paying $500 to MS for access to VS. in the same way that access to tools creates an explosion in software these language abililties will naturally create an explosion in languages.

claude is perfectly capable of building a language to your specific design and then being competent at programming in it. the trick will be how much senior or experienced devs stay in the process. hands off will be boring and backward looking. hands on (steered by human in the loop) will be innovative and interesting.

i predict the results will be that we will get a cambrian like explosion in the number of new syntaxes and languages. every home experimentor will create their variant of c++ or lisp, they will be frowned on by experts. but because out of it will come one or two unique and interesting new ways of programming that nobody else thought of before.

I like the "DB > LSP" idea.

It is interesting that niche languages like Ruby and Elixir sell out to AI, hoping for a revival or more market share. Valim is at dashbit.co, which builds tidewave.ai.

This is unfortunate, because I wanted to try both. Now I hope that Erlang has not sold out yet.