The Ü Programming Language

Many here probably want to know if the language actually works as intended and solves problems mentioned in it's README. I can absolutely say yes, it works!

Since November 2025 I develop a project written (almost) fully in Ü. It's a video game. It's not finished yet, but I plan to release a mostly-working version in several months, including making its source code open. So, stay tuned.

I already have ~45000 lines of code in this project. All this is manually-written (no LLMs involved). Writing Ü is nice, and code mostly works if it compiles. No single time I needed finding/fixing memory-related issues (typical for languages like C++). No single time I faced a crash in random place, if something crashed, it was a safety check. The standard library covers basic needs. unsafe code is used only to interact with SDL2 and OpenGL functions.

I spend my time mostly developing this game project. But occasionally I fix bugs and make small improvements in the language itself. This explains why there are so little commits in last months compared to time before November 2025.

>code examples are linked as a footnote at the bottom of the page (and need to open each code file individually to view them)

This project apparently does not want to succeed.

(Which is odd given the amount of effort invested in it!)

The language itself seems quite nice though.

As someone building a language myself, I'm interested in the other languages actively in development...

But you start with an info dump, no examples, and then a table of features - where the first feature is not something anyone would pick a language for.

You claim to be a memory safe language... And those are buried in the middle of the list. You want to highlight that, and say how you accomplish it. You say you have no GC, but no mention of Affine Ownership or Ref Counting. You talk about thread safety, but no mention of how.

You need to show WHY anyone should care about your language, what problem it's solving, and what that looks like as fast as possible.

In your comparison table, you leave out Go and include Odin - that seems like a mistake. Go punches FAR above its weight class. Dismissing it because it "comes with a heavy runtime" is likely to get your project dismissed, no offense. Odin is - essentially - experimental.

People's attention is fleeting.

Everyone and their mother is building a language or two...

Some things I want to know right away:

1) what stage are you at (honestly, not wishfully)?

2) what problems have you ACTUALLY solved instead of INTEND to solve at some point in the future?

3) how thorough is your testing, what do you have, how much, what's the coverage by category?

4) this seems like a performance language - I want benchmarks. If you don't have a good concurrency story, you better have something, and you better have convincing benchmarks that it actually works, otherwise - why is anyone from Go or Rust or Zig or Nim or Crystal or Swift or even Java/Kotlin/Scala or C# going to think about switching?

Saying "using RAII for memory management" is insufficient - with just RAII, you cannot even assign a class into a passed-in variable. The language designer _must_ make make more choices to get a useful language - maybe affine types, or linear types, or prohibit many C++-like idioms, or maybe just good-old refcounted shared pointers (but I'd argue this is a form of GC...)

> Ü is memory-safe and race-condition-safe, as long as no unsafe code is involved at all or as long as unsafe code is correctly written.

How is this achieved? The docs mention in passing that there is some sort of thread-safe immutable structs, but it is not really clear what's the overall picture and how they interact with non-trivial code. And the examples have nothing on thread.

* https://news.ycombinator.com/item?id=45769161

2) In the examples, the placement of & is incoherent: sometimes it's 'i64&', sometimes it is 'i64 &', pick one (I prefer the first).

3) constexpr is a long name for a 'base' concept. comp/<a special letter> would be better. Also conversion_constructor is huge.

4) In D, their static_if doesn't introduce a scope, Alexei Alexandrescu has made a very insteresting pitch about this.

5) zero_init is nice.

6) I don't like "hidden" overloaded operators, how about #+ for the overloaded variant of +?

7) you support i128 natively but integer literals are limited to 2*64-1?

8) I'm slowly reading "reference checking" ( https://panzerschrek.github.io/U-00DC-Sprache-site/docs/en/r... ) which seems to be an important part of the language, and I still don't know what's the integer overflow behaviour which is quite important..

I advocate Zig's behaviour: signed and unsigned have undefined behaviour in case of overflow for optimised build, trap in debug build and there are modulo operators.

> Exceptions are also one of the greatest C++ sins. They were problematic from the start, several attempts to fix them (like noexcept annotations) were done, but C++ exceptions still remain fundamentally wrong. They violate one of the most significant C++ design principles - don’t pay for what you don’t use. Even so-called zero-cost exception implementations (on happy path) aren’t really zero-cost, since they affect optimizations, because of possible unwinding. Also they introduce additional executable bloat - for unwinding code.

- thread-safety (no race conditions): Swift has full concurrency checks since Swift 6, which prevents race-conditions*.

- compile-time calculations: Macros can permit compile-time compilations. The syntax is not lightweight, that’s for sure, but it is possible. And you can do much more than “just” compile-time compilation.

- references (with auto reference creation and dereferencing): I am not fully sure what this is about, but classes are references…

*Logical race-conditions are still, obviously, possible, but unsafe concurrent access to the same variables are not.

Edit: also the name is ungoogleable.

"Some may call this junk. Me, I call them treasures."

Well, a fitting translation seems to be "Bazooka". However, "Panzerschreck" sounds like an old fashioned German word (not too surprising I guess) that wouldn't be used anymore today. The typo which I think might be intentional makes it kind of silly.

Blessed are the humble, for they shall be humbled.

I can't help but notice your username, and the fraktur font, and of course the umlaut.

Are you aware that the flavouring you've chosen for your user account, the product name, and its logotype are referencing 1930s Germany?

I wonder what the intent could be.

NB non German speakers, "shreck" is fear, and "panzer" is well-known to anyone who has watched nearly any documentary about WWII. The Fraktur typeface is an older Prussian typeface vigorously revived by the National Socialists, who, IIRC, made it mandatory for government documents, because Helvetica was considered woke.