I made a new language designed for AI and Human collaboration

TL;DR: could I make a scripting language that saved time and money while encouraging better coding practices? Yes, I think so: duso.rocks and it's open source.

Even the best programming models struggle with these pain points

• Expressive languages like Python and JavaScript are a minefield of subtle runtime errors waiting to happen. Debugging sessions can be a nightmare.

• More rigid languages like Go catch a ton of errors at compile time. But the overall development time is slower because of its internal complexities.

• If your stack is filled with hundreds or thousands of dependencies, you're asking your AI bot to understand and choose from among them. Plus you increase the surface area for bugs to cling to.

Making Duso

Originally, I was just going to add some scripting to another system I'd written in Go. Lua was a natural choice because it's designed to be embedded. I didn't love the idea of having to add C to my build process, so I looked at pure Go implementations. They were lacking in areas I really needed.

So I did what any normal programmer would do. I decided to make my own programming language.

A few hours in, I realized: hey, if I'm writing this anyway, why not make a few tweaks? I wanted better error handling, sensible data structures, modern language conveniences, and a runtime that actually ships with things you need. Lua is a great language, but it's designed to be minimal. I needed something more complete. So I decided to address all of these things.

Along the way, I noticed something. Claude could code well in Duso. Even though Claude had never been trained on Duso, or its growing runtime, it was doing great. I noticed fewer errors during coding, and shorter debugging and testing cycles. It was just faster to develop with than other languages I'd used with Claude (including Lua).

This caught my attention and my mission changed. Faster development meant fewer tokens. Fewer tokens meant less time and money spent. Less code meant more reliable apps. Holy crap, now I was hooked.

So I did what any normal programmer would do. I decided to add beefy things like a complete web server, a Redis-esque system of datastores, and a complete runtime covering strings, math, regex, file I/O, data conversion, security, and crypto.

As I worked to expand the runtime, I kept the core simple. I refined the Lua-like syntax with more "normal" and consistent ways of doing things. Then I added things from other scripting languages that were good, while trying to avoid the bad. And finally I added a few small innovations of my own.

I started working with Claude. Instead of "code this, test that", I started asking things like "Claude, which pattern looks more natural to you?" and "Hey, what would you call this runtime function?". It was a different way to work that was also more fun.

Two weeks later

By our first public release, I had made 90% of the design and architectural decisions, and Claude had made about 90% of the code, documentation, and examples. It was an excellent collaboration. But did we succeed?

First big test

I have a mobile app called Arland. It's an AI chatbot that acts like a cool co-worker who helps you stay on track with your goals. The Arland server was written in Go using Claude Code. I wasn't looking forward to maintaining it. It was very boutique and even small changes required complex sessions with Claude. My experience with any LLM is that they struggle with refactoring, especially in growing codebases.

The Go version is 8,200+ lines of code. Some files are huge. Claude itself has difficulty editing them. It's not spaghetti code, but it's far from ideal.

So I asked: could I rewrite the Arland server in Duso? Would it work? What would the code look like?

4 hours later

Seriously, 4 hours later. To be fair, Claude had the Go version to use as a model. But this is a pretty complex JSON API server with Apple authentication, purchase authorization, a scheduling system, and the chatbot itself. Not a toy project.

The Duso version? 1,400 lines. More than 80% less lines! But the structure was good too. There's a separate script for each endpoint, a pattern Duso makes natural. All the code is written top-down, with shared features in modules. Every script is isolated, and data is only shared through the HTTP server (deep-copied for thread safety) or with datastores for session caching.

It's cleaner. It's shorter. It's going into the Arland closed beta after some more testing.

Duso is different

• AI-first architecture
• Lua-inspired syntax without the quirks, plus modern language conveniences
• Simple and powerful concurrency model
• Built-in fully-featured web server
• Built-in thread-safe datastores for caching, persisting data, and inter-process communication

But LLMs weren't trained on Duso!

True! So I decided to address this. In the Duso binary, I embedded all the libraries, docs, and examples. You can have your LLM run duso -read and it'll get back a directory-like experience that's easy to parse and interact with. Pure text, pure markdown.

The website also has a /text endpoint that does the same thing.

For humans and LLMs alike, Duso features quick reference documentation on runtime, keywords, and modules. Just type duso -doc http_server and see everything you could want to know about the built-in web server.

I also spent time quizzing Claude and other LLMs about working with Duso. Every one of them reported fewer tokens used for similar tasks. Less time understanding a codebase. Fewer output tokens. Some of the factors that contribute:

• Plain text keywords and built-in function names. A function is function. Block identifiers like do and end are cheap to process for an LLM. No abbreviations, less punctuation, fewer tokens.
• No "magic". Duso is boring because everything does what it says. You can probably guess the keyword for a thing before you look it up.
• Practical architectural decisions. Everything is based around which direction produces code that's easier to make, debug, and ship.
• A fully-featured built-in runtime (120+ calls) and simple module ecosystem reduces decision fatigue. Having basically one way to do any important thing simplifies everything.

Convenience

• duso -init lets you pick an example project to start with (chat, web, swarm, etc.)
• duso -repl is a nice command-at-a-time interface
• duso -c lets you run arbitrary Duso scripts inline
• Duso has an LSP server built in, powering plugins for VS Code, Zed, Sublime, and Vim/NeoVim with syntax highlighting, auto-complete, and pop-up help
• duso -debug turns on the interactive debugger that pauses any script process with an error or breakpoint and queues them up one at a time so you can deal with concurrent issues without going crazy

Future

Duso is about 7 weeks old. I'm still polishing features and docs, but it's solid . I would love early feedback, especially from folks brave enough to start building with it.

The website has easy download for Linux, macOSm and Windows. Or you can get into the source code of Duso at github.com/duso-org/duso which is open source under Apache 2.0 license.

I'm hoping to build a community of like-minded devs who want to help guide and improve Duso. Documentation, bug fixes, examples, modules, improvements in the Go layer, even just a kind suggestion or a share with a friend helps more than you know.

Thank you for reading this far! This is my first post here and I'm happy for any comments!