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.
Why the nazi-esque "Frakturschrift" Logo? I get the font was not originally associated like that, but your name and that logo make me question what's behind it.
I'm Austrian.
Such fonts were in use many centuries before NS time in many countries in north Europe. There were eventually replaced by modern ones, but in Germany they lasted long enough, until WWII. It's a common misconception, that only nazis used it. Even more, they forced replacement of fraktur fonts with modern ones. Nowadays such fonts are in use in places where an old-looking font is needed, like in signs. Also modern nazis use it sometimes, but only because they don't know history well.
I selected fraktur for a logo of my language because it looks "cool" and is already pretty stylized compared to a boring logo using some modern font. I don't insist to use it forever, maybe I will change it later with some better one, but for this someone else need to draw it properly, I don't have necessary design skills for this.
My nick-name is easy to explain. Many years ago I have enjoyed playing Wolfenstein and Call of Duty and these games have Panzerschreck as one of weapons. I choose this as my nick-name, but I unfortunately misspelled it.
> Ü uses RAII for memory and resources management (no GC is involved), but manual memory management may be still used in unsafe code.
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.
Well, if this is supposed to be something like C++, and if "new" is dynamically allocating memory, then simply don't do that - this kind of thing has been solved years ago.
Just a suggestion... you might want to include an example on your main README.
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?
More than 10 years of development, the core aspects of the language are pretty stable and are unlikely to be changed in future. New features can be added, especially in the standard library.
> what problems have you ACTUALLY solved instead of INTEND to solve at some point in the future?
The main problem is memory safety. It's already solved and not planned to be solved. You already can't shoot your leg with typical memory-related errors.
> how thorough is your testing, what do you have, how much, what's the coverage by category?
I have a lot of tests, several thousands of test-cases covering each language feature, including tests for specific compilation errors, tests for compilation into actual binary code, many tests for each standard library feature, tests for the build system. And of course I have a self-hosted compiler, which proves that everything works as intended in actual code.
> this seems like a performance language - I want benchmarks
Nice suggestion, probably it's worth to adding some benchmarks.
> it actually works
It does. There is just nothing there in the language, which can degrade performance significantly. The same LLVM library is used as in C++ or Rust compilers, no GC is involved, runtime safety checks are sparse. In many cases the result binary code is identical for identical C++ or Rust code or at least closely matches it.
My own rough measurements between two compiler generation (first one written in C++ and second one written in Ü) show nearly identical performance.
> 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?
Go and Java-VM based languages are garbage-collected, which is problematic in some areas (like video-games). Rust is fine, but is sometimes too complicated. Zig is just a better C with no memory safety. Nim isn't known for me.
The README makes me never want to use this. A career of seeing the same style from shit vendor salespeople has made me assume that under the hood is nothing but snakes.
Whenever you are publishing something, whether it be an app, a programming language, ... the examples or screenshots must come first. The reality is that unless you have made a very compelling case beforehand (like with a well crafted screenshot or example), most people will not read your list or description below. Put the examples at the start of the README, they're the selling point of your language not the list of features
For instance, this was the first ever version of the rust-lang.org website:
I remember reading it 14 years ago and it was pretty effective at captivating users towards the language. Notice its terseness and the example at the bottom: a reader will first look at the example, then the bullet points above if they're interested, and then the rest of the docs
- Overly boastful language. Nothing is perfect, everything has limitations, etc, etc. If the creator isn't willing to admit that and be open about it then that just means users will hit those issue instead.
- Saying what others are not versus saying what you are. You're talking more about other languages than your own language. Vendors do that as a cheap marketing trick to use the popularity of others to boost themselves.
Guess your comparison with C++ in this case needs to be revised, or at least you need to look into this in other point. As well as the part about the similarity with other languages is co incidents make me laugh :D Hope you'll make this really great, but you need better comparisons and better wording and docs.
> 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.
Mmmh I don’t know about most of the languages with which this language compares itself in the readme, but for Swift it seems that the comparison is either out-of-date or misinformed.
- 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.
You are partially right. I cherry-picked features which I personally find important. But since they are so important for me, I bothered designing/implementing them in the language in a right way.
On a random day last month there where 17 commits, and commits happen daily by the same author. It’s true dedication.
Browsing through them requires understanding / translating Slovenian. Translation has never been cheaper, just recently the author has switched to English.
When I started development on the language, my English knowledge wasn't that great, so I preferred writing commits in Russian, but using Latin alphabet instead of Cyrillic to avoid changing keyboard layout (I hate doing this).
The conclusion was made by Deepl auto translate based on a random commit. Perhaps due to the use of Latin characters the ai was derailed, which is entertaining to see
Something is wrong with that commit count. There are a total of ~4k commits over nine years [1].
It looks like the author revived the project recently with the help of AI, but the majority of commits are from 2017-2024. Github might be counting all the branch activity from agents.
From the description of the graph you kindly provided:
Contributions per week to master, line counts have been
omitted because commit count exceeds 10,000.
So I am confused as to the "total of ~4k commits over nine years" determination, unless this is in reference to commits Panzerschrek has made spanning the last two years (not nine).
Why does DeepL translate "Panzerschreck" to "Panzerschreck"? Is that actually a word understood by English native speakers? I know the words "Panzer" and "Schreck" (normal word of used in the appropriate context), but didn't exactly know what a Panzerschreck is.
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.
It's sad that the compose key isn't prevalent. Combining " and u into ü makes a lot of sense, however people thought that we wanted 40 different slightly different keyboard layouts instead of a universal one. Despite how annoying it might seem to get, it's not that bad really.
> Ü is heavily inspired by C++, but doesn't have its downsides. Also it was influenced by Rust, but only slightly and thus is way easier to use in comparison to Rust. Any possible coincidence with design and features of other programming languages is unintentional.
Blessed are the humble, for they shall be humbled.
We've banned this account for repeatedly breaking the site guidelines. If it were just an isolated comment I'd post a warning instead, but it's the majority of your posts! That's not cool, and we warned you once before.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
I have thoughts about some kind of attributes for class fields and maybe classes. But such change isn't the first in the list of features to be done, there are more important things to do.
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.
- 'Panzer', of course, is a famous Nazi tank model
- 'Schrek' is from _schrecklish_, terrifying (sp?) in German
- The typeface, Fraktur, has a specific meaning in the National Socialist design language, which is, by about a century, the last time it was regularly used (IIRC.)
So, you tell me. In an Internet awash with encoded symbols, what are these ones telling you?
Use your eyes, your noggin, and your German history texts.
> 'Panzer', of course, is a famous Nazi tank model
Panzer is German for tank, or armor. It‘s not referring to any model specifically, I don’t think, but I‘m not a historian.
Panzerschreck (spelled correctly) is something like „tank scare“.
But indeed, that GitHub page gives off the wrong vibes. Using this project will be tough, at least in Germany and Austria, lest you want to be suspected of Wiederbetätigung.
The author here.
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.
Why the nazi-esque "Frakturschrift" Logo? I get the font was not originally associated like that, but your name and that logo make me question what's behind it. I'm Austrian.
Such fonts were in use many centuries before NS time in many countries in north Europe. There were eventually replaced by modern ones, but in Germany they lasted long enough, until WWII. It's a common misconception, that only nazis used it. Even more, they forced replacement of fraktur fonts with modern ones. Nowadays such fonts are in use in places where an old-looking font is needed, like in signs. Also modern nazis use it sometimes, but only because they don't know history well.
I selected fraktur for a logo of my language because it looks "cool" and is already pretty stylized compared to a boring logo using some modern font. I don't insist to use it forever, maybe I will change it later with some better one, but for this someone else need to draw it properly, I don't have necessary design skills for this.
My nick-name is easy to explain. Many years ago I have enjoyed playing Wolfenstein and Call of Duty and these games have Panzerschreck as one of weapons. I choose this as my nick-name, but I unfortunately misspelled it.
>ungoogleable name
>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.
Who are U to judge the name ?
> Ü uses RAII for memory and resources management (no GC is involved), but manual memory management may be still used in unsafe code.
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.
It reads like affine types to me https://panzerschrek.github.io/U-00DC-Sprache-site/docs/en/r...
They borrowed heavily from Rust here.
> Saying "using RAII for memory management" is insufficient - with just RAII, you cannot even assign a class into a passed-in variable.
What exactly do you mean by " assign a class into a passed-in variable"? Please post some code illustrating what you are talking about.
If this one is too easy, make function return "w" as well, or make it add a widget to two different lists
Well, if this is supposed to be something like C++, and if "new" is dynamically allocating memory, then simply don't do that - this kind of thing has been solved years ago.
Just a suggestion... you might want to include an example on your main README.
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?
Thanks for the suggestions!
> what stage are you at
More than 10 years of development, the core aspects of the language are pretty stable and are unlikely to be changed in future. New features can be added, especially in the standard library.
> what problems have you ACTUALLY solved instead of INTEND to solve at some point in the future?
The main problem is memory safety. It's already solved and not planned to be solved. You already can't shoot your leg with typical memory-related errors.
> how thorough is your testing, what do you have, how much, what's the coverage by category?
I have a lot of tests, several thousands of test-cases covering each language feature, including tests for specific compilation errors, tests for compilation into actual binary code, many tests for each standard library feature, tests for the build system. And of course I have a self-hosted compiler, which proves that everything works as intended in actual code.
> this seems like a performance language - I want benchmarks
Nice suggestion, probably it's worth to adding some benchmarks.
> it actually works
It does. There is just nothing there in the language, which can degrade performance significantly. The same LLVM library is used as in C++ or Rust compilers, no GC is involved, runtime safety checks are sparse. In many cases the result binary code is identical for identical C++ or Rust code or at least closely matches it.
My own rough measurements between two compiler generation (first one written in C++ and second one written in Ü) show nearly identical performance.
> 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?
Go and Java-VM based languages are garbage-collected, which is problematic in some areas (like video-games). Rust is fine, but is sometimes too complicated. Zig is just a better C with no memory safety. Nim isn't known for me.
For those interested, I found code examples here: https://github.com/Panzerschrek/U-00DC-Sprache/tree/master/s...
All good points. I have sent a link to this page to the author of the language (Panzerschrek).
I hope the author is ok with this kind of publicity. He might not have wanted attention if the language is not ready for public opinion.
https://news.ycombinator.com/item?id=45769161
There was a "Show HN: Ü Programming Language" from the author last October.
* https://news.ycombinator.com/item?id=45769161
Some more resources from that post:
> See examples (https://github.com/Panzerschrek/U-00DC-Sprache/tree/master/s...) to get a general idea what Ü is and how it looks like and feels. Read the documentation (https://panzerschrek.github.io/U-00DC-Sprache-site/docs/en/c...) for more details. If you have some questions about the specific mechanism providing safety, read the corresponding chapter (https://panzerschrek.github.io/U-00DC-Sprache-site/docs/en/r...). If some topic isn't clear for you after reading the documentation, contact me and I can answer your questions.
this homepage has snippets to die for https://raku.org/
The README makes me never want to use this. A career of seeing the same style from shit vendor salespeople has made me assume that under the hood is nothing but snakes.
Could you explain please, what is exactly wrong with the README and maybe suggest, how to fix it?
Whenever you are publishing something, whether it be an app, a programming language, ... the examples or screenshots must come first. The reality is that unless you have made a very compelling case beforehand (like with a well crafted screenshot or example), most people will not read your list or description below. Put the examples at the start of the README, they're the selling point of your language not the list of features
For instance, this was the first ever version of the rust-lang.org website:
https://web.archive.org/web/20111226082307/https://rust-lang...
I remember reading it 14 years ago and it was pretty effective at captivating users towards the language. Notice its terseness and the example at the bottom: a reader will first look at the example, then the bullet points above if they're interested, and then the rest of the docs
i like the rust page example…
here’s what the Raku site should look like:There two main things:
- Overly boastful language. Nothing is perfect, everything has limitations, etc, etc. If the creator isn't willing to admit that and be open about it then that just means users will hit those issue instead.
- Saying what others are not versus saying what you are. You're talking more about other languages than your own language. Vendors do that as a cheap marketing trick to use the popularity of others to boost themselves.
Using a font so close to Fraktur for a german letter is definitely an intentional choice if you want to evoke nazi imagery.
Combined with the username Panzerschrek...
That, and also not realising that given the transparent background it's absolutely invisible with the dark theme. I didn't see it at all
Guess your comparison with C++ in this case needs to be revised, or at least you need to look into this in other point. As well as the part about the similarity with other languages is co incidents make me laugh :D Hope you'll make this really great, but you need better comparisons and better wording and docs.
> 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.
Mmmh I don’t know about most of the languages with which this language compares itself in the readme, but for Swift it seems that the comparison is either out-of-date or misinformed.
- 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.
Do we really need this? I'd rather improve the type checker of some heavily used existing language
Bold claims with no examples. Anyone can make a markdown chart with some pros and cons. Description by comparison is weak.
I find the "Why choosing Ü?" table to be particularly amusing. Just cherry-picked language features where Ü happens to achieve all of them!
You are partially right. I cherry-picked features which I personally find important. But since they are so important for me, I bothered designing/implementing them in the language in a right way.
11775 commits in about a year is... concerning.
On a random day last month there where 17 commits, and commits happen daily by the same author. It’s true dedication.
Browsing through them requires understanding / translating Slovenian. Translation has never been cheaper, just recently the author has switched to English.
Example random day: https://github.com/Panzerschrek/U-00DC-Sprache/commits/maste...
This is Russian, written in Latin characters.
Exactly.
When I started development on the language, my English knowledge wasn't that great, so I preferred writing commits in Russian, but using Latin alphabet instead of Cyrillic to avoid changing keyboard layout (I hate doing this).
The conclusion was made by Deepl auto translate based on a random commit. Perhaps due to the use of Latin characters the ai was derailed, which is entertaining to see
It's 11775 commits in 10 years.
But in last several years I prefer committing frequently, basically each time I do a change which compiles successfully.
And it's all manual changes, no LLM (vibe-coding) is involved.
Sounds pretty normal if someone's working full-time on it? That's what, 50/ working day, or about a commit every 10 minutes? Nothing to worry about.
Something is wrong with that commit count. There are a total of ~4k commits over nine years [1].
It looks like the author revived the project recently with the help of AI, but the majority of commits are from 2017-2024. Github might be counting all the branch activity from agents.
[1] https://github.com/Panzerschrek/U-00DC-Sprache/graphs/contri...
From the description of the graph you kindly provided:
So I am confused as to the "total of ~4k commits over nine years" determination, unless this is in reference to commits Panzerschrek has made spanning the last two years (not nine).Why does DeepL translate "Panzerschreck" to "Panzerschreck"? Is that actually a word understood by English native speakers? I know the words "Panzer" and "Schreck" (normal word of used in the appropriate context), but didn't exactly know what a Panzerschreck is.
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.
I choose my nickname many years ago, when I was much younger and had troubles with correct spelling. Now it's too late to change it.
I just think of it as some kind of armored shrek :)
> Now it's too late to change it.
Really? May I suggest to reconsider that? Are you still a fan of World War II Germany?
How do I Google for this language……
It's sad that the compose key isn't prevalent. Combining " and u into ü makes a lot of sense, however people thought that we wanted 40 different slightly different keyboard layouts instead of a universal one. Despite how annoying it might seem to get, it's not that bad really.
"Ü programming language" brings up the Github docs with Google, as does "U programming language", although this HN post comes up second.
On a Mac "Ü" is typed "option-u shift-u".
I use Ctrl+Shift+U followed by DC to type it. Or sometimes just switch to german keyboard layout. One can also just copy-paste its name.
> Ü is heavily inspired by C++, but doesn't have its downsides. Also it was influenced by Rust, but only slightly and thus is way easier to use in comparison to Rust. Any possible coincidence with design and features of other programming languages is unintentional.
Blessed are the humble, for they shall be humbled.
[flagged]
We've banned this account for repeatedly breaking the site guidelines. If it were just an isolated comment I'd post a warning instead, but it's the majority of your posts! That's not cool, and we warned you once before.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
as an ü person i endorse it
> duck-typing in templates (without mandatory template type requirements specification)
"Some may call this junk. Me, I call them treasures."
Are there plans to bring in compile-time attributes like C#? I really like what I’m seeing here apart from the lack of that.
Edit: also the name is ungoogleable.
I have thoughts about some kind of attributes for class fields and maybe classes. But such change isn't the first in the list of features to be done, there are more important things to do.
Not if you have a German keyboard.
Oh god, I once had to program in C++ on a French keyboard.
What a nightmare, happy you've made it through.
Hi Panzershreck,
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.
You should save face by editing in a '/sarcasm' as soon as possible.
I was not, and I am not, because it obviously is.
- 'Panzer', of course, is a famous Nazi tank model
- 'Schrek' is from _schrecklish_, terrifying (sp?) in German
- The typeface, Fraktur, has a specific meaning in the National Socialist design language, which is, by about a century, the last time it was regularly used (IIRC.)
So, you tell me. In an Internet awash with encoded symbols, what are these ones telling you?
Use your eyes, your noggin, and your German history texts.
To nitpick:
> 'Panzer', of course, is a famous Nazi tank model
Panzer is German for tank, or armor. It‘s not referring to any model specifically, I don’t think, but I‘m not a historian.
Panzerschreck (spelled correctly) is something like „tank scare“.
But indeed, that GitHub page gives off the wrong vibes. Using this project will be tough, at least in Germany and Austria, lest you want to be suspected of Wiederbetätigung.
[flagged]
This is clearly satire.
You underestimate the egos involved.