How a new DSL may survive in the era of LLMs

Hacker News Top News

Summary

The article explores how new domain-specific languages (DSLs) can remain relevant in the age of LLMs by emphasizing strong documentation, interactive landing pages, and robust tooling such as language servers and diagnostics, using the author's projects Web Pipe and Datafarm as examples.

No content available
Original Article
View Cached Full Text

Cached at: 06/12/26, 02:53 AM

# How a New DSL May Survive in the Era of LLMs Source: [https://www.williamcotton.com/articles/how-a-new-dsl-survives-in-the-era-of-llms](https://www.williamcotton.com/articles/how-a-new-dsl-survives-in-the-era-of-llms) June 11th, 2026 There have been an untold amount of projects written in Python, Rust, Ruby, and other "legacy" software languages over the last few decades\. All of this code has made for great fodder for LLMs\. As these models have progressed the instances of hallucinations have decreased dramatically\. But it's not just the mere volume of source code to train on\. It's the advanced tooling around these languages\. Type checkers, linters, language servers, compilers, interpreters, testing harnesses, you name it\. All of these tools ground software in reality and give an LLM agent immediate feedback\. For example, hallucinations are caught by the type checker before the code is even run\. Because of this even more of these legacy software languages are being used to create even more content for future models to train on\. It seems like we're stuck in a feedback loop of sorts\. So what's a new language to do to become viable in the era of LLMs? The answer isn't too dissimilar to how things used to work: great documentation, great marketing, and great tooling\. How does a prospective language user find out about a new language? How do they onboard? How does the language integrate with their existing tools and workflows? A modern language is going to need a robust language server\. It is going to need an extensive set of documentation with a good onboarding flow\. A new language also going to need a little bit more to play well with LLM agents\. #### Documentation and Context One approach is to have your new language create an AGENTS\.md type file from the binary itself, something along the lines of: `webpipe init \-\-codex` Here's the[LLM template](https://github.com/williamcotton/webpipe/blob/main/src/scaffold/templates/LLM.md.template)used by[Web Pipe](https://github.com/williamcotton/webpipe), an experimental web application DSL that I've been working on lately\. It's a bit unfair because Web Pipe has a number of advantages that other DSLs might not have\. It embeds other languages like jq, Lua, JavaScript, SQL and a few more\. LLMs are already going to have familiarity with these languages so the syntax and semantics of the pipeline\-oriented approach are not that much more to learn\. I've already had a lot of luck with one\-shot prompts in codex to create demo applications using Web Pipe with just this single AGENTS\.md template file as guidance\. #### Landing Pages The quicker you can get across the purpose and use case of a new language the better\. The quicker you can get someone playing with the language the better\. Since it has never been easier to create WASM runtime environments for new languages you can benefit immensely from adding an interactive editor right at the top of your landing page, as is the case with another project of mine called[Datafarm](https://williamcotton.github.io/datafarm-studio)\. So don't just target one runtime like a CLI tool\. Target a browser runtime as well\! #### Tooling You're going to need great diagnostics\. From compile time, to runtime, to linting, you name it, you're going to need to throw the kitchen sink at this problem\. You will need a language server and you will need multiple interfaces with the underlying diagnostic tooling\. And of course we've got a plethora of agentic programming tools out there to assist with this\! One pattern I've come across is to create a single binary that operates as the runtime and the language server\. This keeps all of the diagnostic feedback inline between the two\. In addition, separating the diagnostics from the LSP APIs means you can ship WASM diagnostic tools for a browser\-embeddable component like Monaco\. Red squiggles under all of your typos and syntactical errors, no matter the tool or runtime, FTW\! It's my opinion that we're going to see an explosion of new languages, especially of the DSL variety, over the next few years as it becomes easier and easier to cover the bases needed for liftoff\.

Similar Articles

Expert Beginners and Lone Wolves will dominate this early LLM era

Jeff Geerling

The author reflects on how local LLMs (GPT-OSS 20B, Qwen3 Coder 30B) helped him migrate his blog from Drupal to a static site, comparing them to junior developers who deliver code quickly but need review. He argues that 'expert beginners' and 'lone wolves' will thrive in the early LLM era.

Use Boring Languages with LLMs

Hacker News Top

An opinion piece arguing that LLMs perform better with boring, consistent languages and ecosystems (like Ruby on Rails) because the training corpus has lower variance, leading to more reliable agentic output, while fragmented ecosystems (like JavaScript) produce poor results.

Fine-tuning an LLM to write docs like it's 1995

Hacker News Top

The author fine-tuned a local LLM on a corpus of 1990s Microsoft manuals to generate documentation in that vintage style, exploring local model customization for technical writing.

Content for Content’s Sake

Armin Ronacher

The author investigates how LLMs are influencing word usage in coding and everyday language, finding that words favored by LLMs show increased frequency in both coding sessions and Google Trends, raising concerns about humans adopting LLM writing styles.