Introducing Yugo

Yugo home page

Yugo is a programming language meant to empower humans and agents to create working, performant, and reliable software, enabling them to solve their most important problems. There’s more information about the language itself on the homepage. The language/compiler is still in pre-alpha and subject to change. The language is currently invite-only early access as I want to take the time to develop a high quality language and create a high-quality product. Making a programming language is easy (especially now with agents), making a good programming language that provides unique value is still challenging (for now).

In addtion, I want to ensure Yugo works well across the 4 mainstream arch-OS parings (Windows/Linux x64, Linux/Apple ARM64) before making the language widely available - at the moment I only have reliable access to Apple AArch64 machine, but God willing, should be getting a reliable access to other machines soon.

Aburi walked so Yugo could run

Working on Aburi, a compiler for C/C++, has given me intuitions on what I do and don’t want in a new programming language. C++ especially is a complex language and there are many areas where a new language can significantly cut down the complexity while still providing a premier development experience. I go into more detail in the Yugolang Difference Comparison page. Here are some of the nitpicks:

• C/C++ macros are a mess. IIRC they are holdover from the days where preprocessor and compiler were different programs.
• C++ templates are powerful but too featured-filled and overused. IMO C++’s template system is it’s greatest asset and it’s biggest disadvantage. At least 75% of the time I spent debugging/working on Aburi involved the template subsystem, and it has secondary issues such as slow compile times
  • Adinkra stdlib manages to achieve faster compile times compared to libc++ on Clang because it uses less template sugar, at the cost of runtime performance.
• Inheritance adds unnecessary complexty, and the problems it attempts to solve are better done via protocols/interfaces/traits.
• C++ concepts allow too much. When I was workng on Aburi it was a major source of performance tension and required the creation of a mini “Concept AST” (when I said C++ templates are too dependent on syntax sugar this is what I meant). Overloads of templates also led to the need for normlization/DNF, another source of complexity.
  • In Aburi, overloads are mostly limited to operators to assist with numerical computation.

Perhaps a understated point is how much current implementations cement pre-existing architectures within the standard. GCC and Clang, the two major open-source C++ compilers, first emerged, the language itself was much smaller, facilitating experimentation and the testing of different architectures. As Clang and GCC grew, I believe a subtle process began to unfold wherein “the standard starts dictating compiler design”. New features are (informally) required to already have an implementation in GCC or Clang, usually via development forks such as Bloomberg’s version of Clang with reflection support. While this is certainly necessary (the export template case illustrates why), focusing too much on existing implementations binds the standard more tightly to the existing architectures of those compilers, thereby making the implementation of alternative solutions more difficult.

A new, ambitious compiler might attempt to circumvent these limitations through modifications to the language, but in that scenario, it’s probably better to create a new language: especially in 2026, given the great flexibility in code handling offered by current models, let alone those expected in the coming months or years. While working on the Aburi project, I wanted to introduce a multitude of (relatively minor) changes that would significantly improve the compiler, but unfortunately that wasn’t feasible because, regardless of the specific functionality or behavior involved, there will always be at least one codebase that comes to depend on it in some subtle way. Hence, another reason for Yugo’s existence. ¹

(Not) the Everything Language

Some C++ hardliners will refuse to admit but it’s true: there’s a growing lack of interest in the use of C++ for future/newer systems applications/projects. Recent examples include: NVIDIA’s work on Rust CUDA, FlashAttention-4 being implemented in CuTe-DSL instead of C++ (complexity and compile-time of templates being cited as a explicit reason), and Google using Gemini 4 to rewrite their codebases in Rust. I start these projects for fun but I enjoy working on “relevant” stuff: a COBOL compiler doesn’t interest me for example. It doesn’t really make sense to me to attempt a Rust/Go/Swift compiler as they don’t have specs and the ecosystem moves as if the official compiler is the only one that should exist (I am not too sure but I seem to remember some drama with rust-gcc due to some crate maintainers declaring they’d never support it), and Aburi was such a large undertaking that I’d only want to repeat for something more novel.

I believe the reasoning for why is as follows (correct me if I’m wrong: I was born after the year 1999): in the early days of C++ there weren’t a lot of languages like it and as such C++ quickly became the “everything” language supporting all kinds of programming use cases. As new languages came about (Python, Java, and then Go, Rust, Swift) came about which was better than C++ for certain use cases it slowly began to eat away at C++’s marketshare and this process continues onto today. Memory safety is important but it is not the only feature drawing people away from C++ and as the C++ committee/maintainers make progress towards adding some levels of safety people will still be drawn to other languages. C++ still has strengths no other langauge has, and it will be used, just not for every or probably most systems projects.

As a result, I am wary of trying to create the “Everything” language. There will be use cases I don’t consider. There will be features I don’t add. There will be instances for which using Yugo is a bad fit. For example, the “modern” day frontend web development is not a use case I am targeting nor are the principles of modern web development, with excessive JavaScript and RAM bloat and slow website loading times, something I identify with (I’m not saying Javascript or modern web features are bad, but people misuse them). The “big” web has a lot to learn from the “small” web/Indie Web, but that’s a discussion for another time. Backend web services remain a potential use case for Yugo. Yugo is also not intended to be someone’s first programming language, althrough I don’t think Yugo’s learning curve is high compared to a language like Rust.

Future of Yugo

The immediate goals are to harden the compiler, clean up bugs, improve standard library, improve performance (of both compiler and compiled programs), and create sample programs in Yugo to test language ergonomics and features. I will make those sample programs (mix of hand-written and vibe coded/agentically engineered) avaliable as language development progresses.

Medium term plans is try to enhance the language for embedded/resource-constrained environements (e.g: no ARC mode). For example, the aarch64 embedded scene is growing and Yugolang will grow with it.

On long-term plans: We live in interesting times. There is a possibility that artificial intelligence models will continue to advance and eventually render human software engineers and human intellectual contributions superfluous (and perhaps lead to our extinction, though that a topic for another time; humanity might survive in some form even after “singularity”. After all, we have already survived events that brought us to the very brink of mass extinction. However, the world will then be so drastically different that almost none of the current world model will hold up). I still believe in human creativity, expression, and empowerment, admitting how that’s expressed will change as AI progresses.

It is also true that agents can create programs in any language, including assembly language, without major difficulty. As early as a year ago, AI models were successfully writing GBA emulators in assembly; more recently, Gair Isene wrote a X11 Graphics Server in assembly with the help of LLMs. This raises the question: Why spend time working on Yugo, even if it offers advantages over other programming languages?

There are several reasons: first, agents benefit from “better” programming languages and their associated tools (e.g: C/C++ has address santizer, Rust has borrow checker). Assuming agents could generate perfect assembly code on the first try, there are obvious issues with an agent writing in assembly rather than, say, a language like C, portability being one of them. Languages like Rust and Go are well-suited for agents because they offload burdens from the agent itself onto the compiler/runtime, which can then undergo rigorous correctness testing. If an agent requires fewer tokens, less time, or less reasoning/effort/compute to create a functional (i.e., free of avoidable errors) equivalent program in Yugo compared to other languages, that is a major advantage.

Second, there may be situations where manual coding remains necessary, and Yugo is designed with handwritten code in mind. However, given the current pace of AI development, and with recursive self-improvement seemingly on the horizon, the necessity of manual coding for systems programming might only hold true for a few more months (I say this in absolute terms; for many use cases the need to manually handwrite has already disappeared). Regardless the ability to handwrite code will be nice if only for artasinal reasons. To make sure the language works well with hand writing, I have been handwriting many Yugo programs by hand such as solutions to Neetcode 250. Many language issues have been unearthed from me attempting to code programs manually which I would have missed if I let agents do all the work (merely looking at AI-generated Yugo code is not enough)

Finally, in case you hadn’t noticed, all my projects are created for fun and to satisfy my interest in programming languages and compilers. If they happen to become useful to others as well, that’s just an added bonus. In three years (or sooner), AI will likely create a better version of Yugo on its own with no human involvement required, but it’s not over until it’s over, and as long as human effort holds any value, I’m staying in this game until the very end: like I said earlier, epistimic humility during these times is important :)

As of late 2026, designing a programming language remains a challenging task, even with the help of agents. AI makes it easier to discard failed attempts and experiment rapidly, yet I still spent a great deal of time deciding how I wanted the language to be structured, a process aided by experience gained from other projects (I’ve been programming before 2022). With agentically-developed languages, there is a significant risk of feature creep, and I see many “vibe-driven” languages falling into that trap. In my view, the problem with creating a language that has “as many features as possible”, like Rust, C++, or Swift, is simply that Rust and Swift already exist and have significant backing. I also see too many of these same languages rush to self-host their compiler and/or create large-scale software in their language they don’t understand the code of, in my opinion, this is unwise and you should really take time to slow down every once and a while and go through what you’ve created. One good program in a new PL is better than 100 poorly made, rushed ones. There will be extreme focus on features and programs people and agents can use day to day.

Based on my experience working on the Aburi compiler, I can say with certainty that more language features are not always a good thing. Real value lies in knowing what not to add (and knowing when to add). I recently came across a language developed by a programmer from a West African country (where official language is English); it allows code to be written using words from the local languages instead of English keywords (such as “fn”, “let”, or “if”), utilizing a special layer (I don’t know how; the compiler is closed source) to translate them into their original form for subsequent compilation. I do not intend to use my platform to disparage or criticize other programming languages or projects (imho some other PL devs should take a similar approach), but I will make an exception here, to say this is a completely useless feature (a language using Arabic/Chinese/Japanese/Cyrllic script would be more interesting IMO).

The creator of Exlir, José Valim, has a very good article on the future of PLs. I agree with most of what he’s written, especially on his views on the uselessness of creating a special “agentic syntax” and to rather focus on increased verification/language guarantees.

Anyway, I will be posting progress as the language develops. I am interested to see what comes out of this, if anything.

Happy (late) German Unity Day to all of my German readers.