At a risk of going against the hivemind, I disagree.

I self-taught programming quite early in my life, way before I had a good command of the English language. I've read books in my native language, talked on programming forums in my native language. In the end the "english" in programming languages is just a handful of keywords, and it didn't hinder me one bit that I had no idea "int" stands for "integer".

Of course, I started by writing code like "bool es_primo(int numero)" (in my language), but there's nothing in C that says identifiers must be english, just convention. Standard library and packages nowadays would be a problem, but back then standard library were thin and "strcpy" name is obscure anyway. The real hard part was always learning how to program and design properly.

And for more advanced topics, documentation and learning materials in english only are HUGE problem for ESL, because one has to actually read and understand them. But this is not something programming language can help with.

That’s the least of their problems. The best computer science textbooks are published first and foremost in English and only translated belatedly. The research papers are in English and not often translated. Even the manuals of both commercial and FOSS programming tools tend not be translated. A few keywords is what, half an hour of rote memorization.

Naah, my non-english-speaking friends say that the keywords are less than 1% complexity of a programmer's job, so it really doesn't matter.

Also, in most languages you already can name variables/classes/members in any Unicode letters. So only "if/for/while" keywords and stdlib classes remain English. It makes little sense to translate those.

True. English is a major reason why India is the IT back-office for most of the western world. I too have personally observed how my fellow classmates, who had done their schooling in their regional language, struggled with the coursework in college because it was solely in English. And some of them were state rankers - it felt bad to realise that they had to put in twice the effort needed to keep up their grades. I think there's a lot of potential wasted in India because of this kind of hardship / struggle - a lot of intelligent people are held back just because they lack an aptitude for multilingualism.

Thank you for your empathy. English has been the one of the most frequent languages for globe so that it is reasonable to Eng in many coding project, though.

These are really cool! Will also add a version of these mnemonics to the Korean guide I have been writing: https://tolearnkorean.com/

Learning the Korean alphabet (Hangul) can be done quite quickly, it's only about as many "letters" as the English alphabet!

Remembering the words is a bit more difficult though, especially if you don't know a similar language. Have been using Anki and my own app for that: https://game.tolearnkorean.com/

That is a deep knowledge that even Korean-natives would not know. I will add this site as a reference to Github. I am glad that I have you as a supporter!

Just added that link to the README — it fits perfectly in the "Beauty of Hangul" section.

That is a fair feedback and I have known those languages which are very reasonable and fairly designed language. But I wanted to more focused on translated into rust for english speakers first, which would make bigger user for this language. Thanks for your feedback!

It's been tried with Chinese Python back in the early 2000s: http://reganmian.net/blog/2008/11/21/chinese-python-translat...

It never really took off. I think because computers already require users to read and type Latin letters in lots of other situations, and it's not that hard to learn what a few keywords mean, so you might as well stick with the English keywords everyone else is using.

Good point about compactness — 실명인증계정생성 vs AbstractVerifiedIdentityAccountFactory is a real example where Korean shines.

One distinction though: Han uses actual Korean words, not transliterations. 함수 means "function" in Korean, 만약 means "if" — they're real words Korean speakers already know.

Your example uses transliterations like 펀크 and 아래이 which would look odd to a Korean reader. That difference matters for readability.

I can't speak to Korean, but thinking about Japanese, one probable reason it wouldn't catch on is how tedious and inefficient it would be to constantly switch between input modes. Japanese input mode is designed for prose, and isn't well-suited to efficiently entering the symbols commonly used in programming. Even spaces. It results in needing a lot of extra keystrokes.

Scratch supports Korean, but Scratch benefits from using JSON instead of bytes or code points to serialize programs, which allows the user to change their display language (similar to how hard tabs let users set indentation size).

There's probably a lot of reasons why non English programmers stick with English keywords, beyond just language/tooling support. Learning new keywords is already part of learning a programming language, and much of the documentation and resources available for languages and libraries are only in English. ASCII-only strings are still ubiquitous in software, like URLs and usernames. And in international teams, English is the go-to lingua franca.

Could this change with LLMs? Maybe, but most code in its training data is in English, so LLMs likely work most effectively in English.

funny examples, though.

The real barrier is not just the language keywords but lots of documentations and discussions in English. I'm not sure whether there is a solution to this.

Haha, using Eng has been reasonable for decades. Thank you very much of your comments.

Honest answer: right now it's mostly a keyword translation with English-like syntax order. Korean is SOV (subject-object-verb) but Han follows English SVO order — 목록.추가(값) reads like "list.add(value)" not the Korean natural order. Changing that would require a fundamentally different syntax design, which is an interesting challenge for the future.

That said, a few things do lean into Korean specifically:

- Method names are real Korean verbs: .추가() (add), .삭제() (delete), .분리() (split)

- Error messages are in Korean

- The REPL prompt is 한> and exit command is 나가기 (literally "go out")

Good question — it pushed me to think about what makes this more than just s/function/함수/g.

That's a fascinating idea! Hangul is indeed compositional — 한 = ㅎ + ㅏ + ㄴ — so in theory you could assign meaning to individual jamo components.

But in practice, breaking syllables into jamo would make keywords less readable, which goes against Hangul's design goal. And considering how AI-assisted coding works today, fully named descriptive keywords actually reduce errors — LLMs perform better with explicit, unambiguous tokens than with cryptic symbol compositions.

So Han leans toward more descriptive Korean keywords rather than shorter symbolic ones. Readability over brevity.

Interesting direction to think about though — thanks for the question.

I think this notation is superior, because of syntax completion - get_name(user.id) can be syntax completed by IDE, (user.id)get_name can't. Just like "SELECT id, name FROM users" would be better of as "FROM users SELECT id, name" (LINQ in C# fixed this mistake, and most modern query languages do too).

Object oriented programming languages also use object.method rather than method(object), so I don't think prefix/suffix notation has much to do with language.

Ha, neat trick. But macro substitution and a purpose-built language are very different — Han has a full pipeline (lexer → parser → AST → interpreter + LLVM codegen) designed around Korean from the ground up.

Error messages, REPL, LSP hover docs are all in Korean. You can't get that from #define 만약 if.

Thanks! One thing that motivated me was curiosity about prompt efficiency in the AI era. Hangul is beautifully dense — a single syllable block packs initial consonant + vowel + final consonant into one character. I wondered if Korean-keyword code might produce shorter prompts for LLMs.

I actually tested this with GPT-4o's tokenizer, and the result was the opposite — Korean keywords average 2-3 tokens vs 1 for English. A fibonacci program in Han takes 88 tokens vs 54 in Python.

The reason comes down to how LLM tokenizers work. They use BPE (Byte Pair Encoding), which starts with raw bytes and repeatedly merges the most frequent pairs into single tokens. Since training data is predominantly English, words like `function` and `return` appear billions of times and get merged into single tokens.

Korean text appears far less frequently, so the tokenizer doesn't learn to merge Hangul syllables — it falls back to splitting each character into 2-3 byte-level tokens instead.

It's a tokenizer training bias, not a property of Hangul itself. If a tokenizer were trained on a Korean-heavy corpus, `함수` could absolutely become a single token too.

So no efficiency benefit today. But it was a fun exploration, and Korean speakers can read the code like natural language. It could also be a fun way for people learning Korean to practice reading Hangul in a different context — every keyword is a real Korean word with meaning.

Korean doesn’t reduce typing compared to English from my experience. What looks like a “character” is actually a syllable block called “eumjeol” that’s made up of consonants (moeum)and vowels (jaeum). You can’t have a vowel only syllable either so you always have to pair it with a null consonant no matter what (which kinda looks like a zero: ㅇ) and while nouns can be much more concise compared to English, verbs can get verbose.

The main benefit of Korean actually comes from the fact that the language itself fits perfectly into a standard 27 alphabet keys and laid out in such a way that lets you type ridiculously fast. The consonant letters are always situated in the left half and the vowels are in the right half of the keyboard. This means it is extremely easy to train muscle memory because you’re mostly alternating keystrokes on your left hand and right hand.

Anecdotally I feel like when I’m typing in English, each half of my brain needs to coordinate more compared to when I’m typing in Korean, the right brain only need to remember the consonant positions for my left hand and my left brain only need to remember the vowel positions.

I personally don't know Hanja at all, and I think that's common for most younger Koreans. Korean did borrow from Chinese characters historically, but it's similar to how English was influenced by Dutch, German, French, and Latin — each language developed independently.

Korean has its own pure Korean words (순우리말) as its foundation, and borrowed some Chinese-origin vocabulary on top of that.

Hangul was specifically created so people wouldn't need to learn Chinese characters.

So Han's keywords use native Korean words where possible — it fits the spirit of Hangul itself.

I don't think programming languages follow English grammar or syntax closely.

If X then Y, sure. While X, do Y? Maybe. For X equals Y, X equals Z, X is incremented, do A? Hardly. Match X case Y1 Z1 case Y2 Z2? Definitely not

Native English speakers have a small leg up understanding the vocabulary, not the syntax.

Force for good be with you

The fact that you're already thinking about it means you can do it. Go for it!