Yes! It started out by me building/designing it with my own blood sweat and tears (this is probably the 3rd or 4th serious attempt at a language), until I started toying around with Codex (uggh), then eventually Claude Code. I used the language for the first time to solve many of 2026 Advent of Code puzzles for the first time last year.

At this point, it's mostly for fun, educational purposes and an attempt to build the smallest, but generally useful language with a good balance of dynamic performance, native code compilation, self hosting and a language that is both easy to learn and easy to understand it's design and implementation.

I call it Mu (µ) lang. You can find it at https://mu-lang.org

I've also experimented with building a full UNIX(ish) OS and Kernel in Mu itself. So that means, about ~2k Assembly, the rest in Mu. It's at about a 80/20 (Mu/Asm) and works fairly well!

I like it. What’s the safety/memory story? How much of it would you say is Claude vs you at this point? How good is Claude at writing code in the language itself?

If by "How much is Claude vs. Me", I would honestly say it's all me, Claude just pattern-matched and wrote the code. And to answer your 2nd question, the host was written in Go initially, but progressively over the past year I got Claude to eventually get to a point where the language is now written in itself (self hosted).

So yes, Claude is able to write in Mu quite well -- But this isn't surprising, because I believe large language models sort of settle on the structure and patterns of languages and generalizes fairly well. So this kind of didn't surprise me at all.

If you have a pok around the site, you'll see why. Mu is deliberately very small and minimal. I've also chosen not to implement floating point arithmetic, because I wanted to see if I could get Mu programs to run on micro controllers one day, which many of them don't have FPU(s) -- especially the smaller ones.

I once made a program for calculations in engineering, but it wasn't general enough to be practical, so I thought of creating a simple coding language to script it. After the first day, I realized that creating a language was far more complicated than I had ever expected and would be a maintenance hell. So, in the end, I exposed the program routines to Python and made a GUI around it, so it could be scripted with Python.

Today, with AI and LLMs, creating a language is probably an easier task, but I still think it's smarter to do what I did. Any language you create will necessarily be mediocre and full of bugs. Don't reinvent the wheel.

Yes, I am. I’ve been working on a language for what I think the future of programming might look like under fast and intelligent LLMs. In my own projects and at work it’s already getting close to where the inner loop of checking, linking, compiling and running is slower than the LLMs thinking and edits. I’ve been working on a language that makes it fast to run large programs without sacrificing lots of runtime performance. There are some other tools and features to hopefully keep the inner loop tight.

Additionally, I’ve been really fascinated by the idea of a language that makes LLM observation and rewrites at runtime possible. There is an interface to get profile data and replace functions at runtime based on the analysis of an LLM.

Lastly, I’ve always wanted a language that could model more of the external environment and make those easier/safer to interact with. I think of libraries like Kysely as an example of making that easier. It’s a really cool time to be playing around with these.

Additionally, I’ve been really fascinated by the idea of a language that makes LLM observation and rewrites at runtime possible. There is an interface to get profile data and replace functions at runtime based on the analysis of an LLM.

—-

I poked around at this idea myself and it is a great idea to try and probably a security nightmare to implement. It also isn’t far off from what the JVM does anyway and would probably not work as well.

I've been actively working on my language / compiler for a couple of years now (https://github.com/taolson/Admiran). My goal in its development was to learn in a deep sense how to efficiently compile a pure functional language down to low-level assembly-language, so I haven't used LLMs at all -- using them would negate the learning experience. Plus it's fun to puzzle through these things by yourself!

I actively use it for most programming, these days (command-line only), and use it every year during Advent of Code.

So I've been working for the past half-year or so on a language called xc - it's a heterogeneous compiler, so it takes source code and can target both the CPUs and GPUs (or in fact GPUs across a network or thunderbolt link).

Theres no need for any data-hazard checks in your code, the compiler will do it for you. If you want an analogy, where "ARC" freed programmers from having to manually manage memory, this is "ARC for algorithms", freeing you from having to care where the code runs.

It measures the computing environment at runtime not compile-time, and its opportunistic, so it will schedule work on the most-efficient worker at any given time - be that single-CPU, multiple-threads on the CPU, SIMD or similar hardware, GPU, multiple GPUs, or across a network via an installed daemon.

Here's some results for single-threaded CPU:

     xc cf              arm64 (M3 Max)   x86-64 (AMD Ryzen 9 9955HX)
     ------------       --------------   ---------------------------
     Objective-C        1.45× faster     1.24× faster
     C++ (clang)        1.12× faster     1.04× slower
     C++ (GCC)          1.12× faster     1.13× faster
     Swift              1.44× faster     1.43× faster

Or, on a Mac M3 Max, looking at GPU vs fastest CPU:

     benchmark   1 thread  N threads    GPU     all     auto    GPU vs N threads
     ----------  --------  ---------    ---     ---     ----    ----------------
     mandelbrot  164       13.5         1.3     1.2     1.0     10.1× faster
     md5         1349      108          4.9     5.5     4.8     22× faster 
     md5_mask    1064      85.2         4.1     4.3     4.1     21× faster 
     nbody       17.7      1.8          609 µs  1.3     1.3     3.0× faster 
     perlin      89.9      7.7          1.2     1.2     1.2     6.4× faster 
     saxpy       1.4       1.1          3.9     5.2     1.1     3.6× slower
 

The data-parallel sections are automatically detected, I've recently added a C front-end using clang to generate LLVM IR, which is then converted to our IR, which is then parallelised as usual.

The language itself is fairly modern (classes, protocols for interfaces, blocks for closures, callbacks, exceptions) and each platform is a cross-compiler for each other platform, so I have a binary on my iPhone which was created, compiled, and signed with my dev-certificate all on a linux box. Works great :)