Hacker News

Show HN: Han – A Korean programming language written in Rust github.com

A few weeks ago I saw a post about someone converting an entire C++ codebase to Rust using AI in under two weeks.

That inspired me — if AI can rewrite a whole language stack that fast, I wanted to try building a programming language from scratch with AI assistance.

I've also been noticing growing global interest in Korean language and culture, and I wondered: what would a programming language look like if every keyword was in Hangul (the Korean writing system)?

Han is the result. It's a statically-typed language written in Rust with a full compiler pipeline (lexer → parser → AST → interpreter + LLVM IR codegen).

It supports arrays, structs with impl blocks, closures, pattern matching, try/catch, file I/O, module imports, a REPL, and a basic LSP server.

This is a side project, not a "you should use this instead of Python" pitch. Feedback on language design, compiler architecture, or the Korean keyword choices is very welcome.

https://github.com/xodn348/han

112 comments

parksb•22h
Great work :) If you're interested in Korean programming languages, there's a functional one called 'Nuri': https://github.com/suhdonghwi/nuri/
Rather than just translating keywords, it lets you write code that actually uses Korean grammar. For example, "10을 5로 나누고 출력하다" (literally "10 by 5 divide and print") outputs "2".
You might already know this, but there's also a Korean programming language called 'Yaksok'. Here's a 2048 written entirely in Korean: https://github.com/yaksok/yaksok/blob/master/code_examples/2...
- xodn348•21h
  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!
- zahlman•20h
  I know barely any Korean vocab and can't read Hangul nor am I set up to type it. But is "yaksok", perchance, cognate with Japanese 約束 (やくそく)?
  - parksb•17h
    Yes, countries in the Sinosphere have historically used Chinese characters to write their languages. That's why Korean "yaksok" and Japanese "yakusoku" sound so similar. Both words are written with the same Chinese characters, "約束". The characters were borrowed from Chinese, but each language adapted them to its own pronunciation system.
    For example, "library" is pronounced "tu-shu-guan" in Chinese, "do-seo-gwan" in Korean, and "to-sho-kan" in Japanese. All three can be written with the same characters, "圖書館". In modern Korea, though, people use Hangul, so very few Koreans actually know how to write "library" in Chinese characters. In Japan, Chinese characters are still heavily used, but for difficult ones, they often write kana alongside them as a reading aid.
    It's very much like how Latin "universitas" became "university" in English, "universidad" in Spanish, and "università" in Italian.
  - numpad0•14h
    There's a significant amount of Japanese loanwords in modern Korean due to Japanese annexation(1910-1945/1965), as well as in modern Chinese to much lesser extent.
    These aren't an indication of a shared vocabulary or ancestry, just loanwords for concepts that were novel and scientific by victorian standards.
  - andrekandre•19h
    yes, and you will find a lot of borrowed words from chinese (and sometimes japanese) sound similar (more or less) in both languages
    a big one: hanja (kr) kanji (jp) both are 漢字
hangil131•12h
Hello, interesting project. I’m a native Korean speaker, so I wanted to share a quick perspective from Korean.
Nouns translate fairly naturally, but standalone verb commands in English need more care. In English, a verb like "find" can stand alone, but in Korean a verb usually needs an ending, and different endings can sound quite different or awkward depending on context. For example, "find" could become 찾다, 찾기, or 찾음, but those are not interchangeable.
Plural forms are also tricky. English distinguishes strongly between singular and plural, but Korean usually does not. Explicit plurals like “단어들” often sound unnatural unless the individuality of each item is important.And it feel same with "단어목록"
Overall, this is a very interesting project with real potential. I think it could become even stronger if it considers the structural differences between English and Korean, rather than treating it as simple keyword substitution.
danparsonson•1d
Wonderful! What a cool idea. For anyone interested, you can learn the whole of Hangul in an afternoon; it's cleverly designed to be very logical and has some handy mnemonics: https://korean.stackexchange.com/a/213
- bryanhogan•22h
  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/
- xodn348•1d
  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!
  - zdragnar•22h
    Really? That's how it was taught to me by Korean teachers at University. Even if it isn't daily-useful bit of info, it's such a fundamental component of the written form that I would have expected it to be common knowledge.
    - yorwba•12h
      It's part of the official origin story that was published alongside the introduction of the script, so students will learn about it at some point long after they're already fluent readers and writers, and then promptly forget about this bit of trivia. (Do you remember that A is an upside-down ox head?) It probably doesn't help that the original explanation covers Middle Korean for an audience literate in Chinese: https://ko.wikisource.org/wiki/%ED%9B%88%EB%AF%BC%EC%A0%95%E...
      Meanwhile, "Korean writing is so easy and logical you can learn it in no time at all" has become a meme to the point where I suspect the number of people who've been exposed to the meme and don't remember a single character might be larger than the number of Koreans who've heard about the tongue shape thing and still remember it.
      Also, ㄹ is obviously anatomically impossible for human tongues. It does however closely resemble similar letters in some Brahmic scripts. I'm partial to ʼPhags-pa ꡙ https://en.wikipedia.org/wiki/Origin_of_Hangul#%CA%BCPhags-p...
- xodn348•1d
  Just added that link to the README — it fits perfectly in the "Beauty of Hangul" section.
m-hodges•23h
When I was studying Computer Science in college, I once remarked how lucky we, English speakers, are that programming languages use English nouns and verbs. A ton of my classmates were here on a student visa, and English was not their first language. I always thought that programming in English put me at an advantage on the learning curve. I also always thought it was silly when someone would quip that programming should count for “foreign language” credit. Anyway, always cool to see non-English programming languages.
- localuser13•22h
  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.
  - sushid•20h
    That's coming from a Spanish speaker used to the alphabet, QUERTY, etc. I imagine you'd find it much more difficult if C were written in Chinese or Arabic, for instance.
  - nenxk•20h
    For people that use similar keyboards I don’t imagine it’s that different though like you said occasionally knowing that bool means Boolean or int means integer may make it slightly easier for English speakers I think a big disadvantage would likely be for people from say China that use incredibly different keyboards if I had to add a wildly different second language and switch to it every time I wanted to create a var or import something or write an if statement I’m not sure if I would’ve continued learning to code it may have been one step to many
  - a57721•22h
    I have a similar experience, I learned English much later than my first programming languages, and picking up some keywords and basic APIs was never an issue (it was BASIC and C/C++ at the time). Maybe I would occasionally look up in a dictionary what is 'needle' and 'haystack' in a code snippet, and I was puzzled by the ubiquitous "foo, bar, baz", which to my relief turned out to be equally cryptic for the native speakers. I still don't feel about code as a kind of English prose, it occupies a separate part of my brain, compared to the natural languages.
  - xodn348•21h
    I agree with your opinion and I was wonder how the Korean could be used in the world with full of Eng. Thanks for your feedback!
- thisislife2•23h
  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.
- deepsun•22h
  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.
  - zlfn•16h
    However, in the vast majority of cases, non-ASCII characters are rarely used for variable or function names during programming. This is because they can cause conflicts when using different encoding systems, and some automation tools fail to recognize them. Consequently, programmers in non-English speaking regions must invest more effort into naming variables than English speakers, as they have to translate all localized expressions into English.
    When Toss, a Korean unicorn startup, announced that they would start using Korean for variable names within financial contexts, it sparked significant debate and a wide range of reactions among Korean programmers.
- xodn348•23h
  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.
  - cubefox•22h
    It's may also be reasonable to make localized translations for a programming language. This is rarely done in reality for obvious reasons. An exception are Excel's function names. People who don't know English, or hardly know it, appreciate it.
- kccqzy•21h
  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.
- cyberax•17h
  Nah. If anything, treating keywords as special sigils actually helps.
  Also, not all natural languages are suitable for programming languages. In highly inflected languages you often end up with grammatically incorrect forms. Or with stilted language.
dance2die•2h
As a native Korean speaker who learned programming in English the code looks very easy to read.
The downside is understanding logic feels harder because - the order of Korean is diff from English - e.g. "동안" (while) hard to reason about as "동안" comes after the condition in Korean linguistics and comes before in English.
So my only suggestion is to go diff direction from normal writing flow as shown below for readability
- from: 동안 n < 5 - to : n < 5 동안
apt-apt-apt-apt•1d
A simple translation of keywords seems straightforward, I wonder why it's not standard.
```
    # def two_sum(arr: list[int], target: int) -> list[int]:
    펀크 투섬(아래이: 목록[정수], 타개트: 정수) -> 목록[정수]:
    # n = len(arr)
    ㄴ = 길이(아래이)

    # start, end = 0, n - 1
    시작, 끝 = 0, ㄴ - 1
    # while start < end:
    동안 시작 < 끝:
```
Code would be more compact, allowing things like more descriptive keywords e.g. AbstractVerifiedIdentityAccountFactory vs 실명인증계정생성, but we'd lose out on the nice upper/lowercase distinction.
I hear that information processing speed is nearly the same across all languages though regardless of density, so in terms of processing speed, may not make much difference.
- csande17•24h
  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.
  - hrmtst93837•16h
    People act like the keywords are the hard part. They aren't, and once you get past 'for' and 'if' the rest of the toolchain still lands in English: package docs, compiler errors, logs, blog posts, and ten years of answers on Stack Overflow.
    Changing syntax doesn't change the surrounding world. Unless you plan to translate half of pip and npm you mostly end up with a teaching language or a local curiosity.
  - hombre_fatal•17h
    That probably pops up all over the place, like how there's no real progress making the terminal support different keyboards/languages (e.g. send raw key code to terminal apps).
    Technical people already have to make concessions to deal with ascii chars and English in computing by the time they use a terminal, so the upside of changing any one thing kinda peters out.
  - zahlman•19h
    There has been more recent interest expressed as well, but still with no momentum as far as I can tell. E.g.: https://discuss.python.org/t/supporting-non-english-developm...
  - applfanboysbgon•18h
    I think the actual reason it has not taken off is because of the ecosystem. You can translate Python, but nobody using a high-level language like Python uses just Python. The first time you pull in a library and are met with a wall of English documentation, error codes, and APIs, you're right back to where you started. Low-level OS APIs are also in English. I suspect there is a lot of potential being left on the table here, but it's a massive undertaking because you need to translate not only a language but also enough of an ecosystem for people to be able to make programs.
  - UltraSane•23h
    It might not be hard to learn the keywords in an English programming language but it seems hard to learn something like Spring Boot
- xodn348•1d
  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.
  - WillAdams•23h
    Using actual Korean words rather than transliterations greatly aids readability --- I can still remember stumbling over the transliteration of "Walker Hotel" when taking Korean at the Presidio of Monterey, and pretty much everyone else had the same problem.
- sheept•23h
  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.
- dwg•22h
  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.
- xodn348•1d
  funny examples, though.
set92•9h
I think is a dumb idea. Historically has been easy to learn programming languages because everyone uses the same things, no fragmention. If now everyone starts creating their own programming languages with different language everything is fragmented, you would to a company, and in the interview they will require you to know korean to work there, they will not be able to hire contractors, you will not be able to see an article about a nice feature on another programming language, and port it...
I suppose is again why I discuss with everyone as I would like to have a single language in the world, it would reduce wars, miscommunications, bound everyone closer. But ofc, the other point of view is that it reduces culture But I think it would happen as UK/US or Spanish, same language with variations, but everyone can understand each other.
I can't imagine what would have happened if Python or JS had been fragmented into X different languages because of egos, and instead of collaborating, decide each to create their own languages. I don't think we would be where we are today, probably AIs would not be around, since we would be fighting to understand so many different programming languages.
- jitl•9h
  It’s not dumb to create, play, experiment.
  The author made some art and came here to share it and discuss craftsmanship, and you replied it with an insult and reviewed it like it’s a business decision steeped in global politics. You missed the point and were mean while doing so.
- zlfn•7h
  Then, what you're going to do is create a new programming language with Esperanto
jitl•8h
I don't know Korean but I really appreciate the interesting discussion around linguistics you started here. Some favorite comments that taught me something:
Hangul's phonetic symbolic design: https://news.ycombinator.com/item?id=47382219
Korean plural forms: https://news.ycombinator.com/item?id=47386312
Your comment on how LLM tokenizers shorten common inputs in training data; Korean is more visually compact but suffers from poor token compression: https://news.ycombinator.com/item?id=47381843
Hangul keyboard layout - so cool that the layout is split between consonant and vowel hands and forms rhythmic harmony while typing: https://news.ycombinator.com/item?id=47382081
zellyn•23h
I love this. Nice work!
It’s fun to look at your code samples, have absolutely no clue what any of it means, and think about just how many non-English-speaking programmers must have felt that way looking at our all-English programming languages.
Except lisp: that’s just inscrutable symbols like cond and cons and car and cadr and a bunch of parens! :-)
- woctordho•23h
  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.
  - xodn348•23h
    This tons of Eng documents and contents cannot be translated once but this project is trying to use another language for future use. Thanks for the comment, though.
- xodn348•23h
  Haha, using Eng has been reasonable for decades. Thank you very much of your comments.
naaqq•19h
It reminds me of the Easy Programming Language(https://en.wikipedia.org/wiki/Easy_Programming_Language), a Chinese programming language. Many kids in China started learning programming with it about 15 years ago.
raaspazasu•1d
I don't know Korean at all, but this looks cool and a fun project. I'm curious if this reduces typing or has any benefits being in Hangul vs Latin?
- xodn348•1d
  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.
  - ralferoo•1d
    I don't know how to read Hangul (I know the general idea about how the character is composed). To me just looking at the examples, it doesn't seem as obvious what the structure of the code is, compared to Latin letters and punctuation. Actually, most punctuation looked OK, but the first couple of examples used arrays and [ and ] seemed to just blend in with the identifiers wherever they appeared. I'm not sure how distinct they look with familiarity with Hangul characters. I'm sure it's also nothing that colour syntax highlighting wouldn't make easier.
    - xodn348•1d
      Fair point that [ ] can blend in.
      For Korean readers the character systems look quite different, but I can see how it's hard to parse visually without familiarity.
      As you said, syntax highlighting helps a lot — there's a colored screenshot at the top of the README showing how it looks in practice.
  - topce•1d
    Very Interesting...
    I have similar idea to train LLM in Serbian, create even new encoding https://github.com/topce/YUTF-8 inspired by YUSCII. Did not have time and money ;-) Great that you succeed. Idea if train in Serbian text encoded in YUTF-8 (not UTF-8) it will have less token when prompt in Serbian then English, also Serbian Cyrillic characters are 1 byte in YUTF-8 instead of 2 in UTF.Serbian language is phonetic we never ask how you spell it.Have Latin and Cyrillic letters.
    - xodn348•1d
      Really interesting approach — attacking token efficiency at the encoding level is more fundamental than what I did.
      Even without retraining BPE from scratch, starting with YUTF-8 and measuring how existing tokenizers handle it would already be a worthwhile experiment.
      Hope you find the time to build it, good luck!
    - oddmiral•16h
      You can look at Ukrainian LLM Lapa for inspiration:
      https://huggingface.co/spaces/lapa-llm/lapa
      Best tokenizer for the Ukrainian language
      Thanks to a SOTA method for tokenizer adaptation developed by Mykola Haltiuk as part of this project, it was possible to replace 80,000 tokens out of 250,000 with Ukrainian ones without loss of model quality, thus making Lapa LLM the fastest model for working with the Ukrainian language. Compared to the original Gemma 3, for working with Ukrainian, the model requires 1.5 times fewer tokens, thus performing three times fewer computations to achieve better results.
- bbrodriguez•1d
  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.
  - lunarboy•23h
    It's fascinating and lucky how well Korean fits into a keyboard designed for English. Japanese and Chinese are notoriously inefficient to type.
    - numpad0•19h
      The modern Korean Hangul script is phonographic, meaning it encodes sounds rather than ideas. Apparently that's good enough, or at least works better than how pure phonetic transcripts work for Japanese and Chinese languages, both of which users rejected that idea. But it was also a result of a relatively recent switch from Hanzi-Hangul mixed script used under Japanese occupation.
      - zlfn•15h
        Actually, the use of Hanza(Hanzi)-Hangul mixed script wasn't exactly a byproduct of the Japanese occupation. (In fact, Japanese was the official language back then lol)
        People started moving away from using difficult-to-type Hanza as soon as the typewriter was introduced. As computerization progressed, the transition naturally continued until Hanza was phased out of most documents. Even so, it has only been about 40 years since Hanza disappeared from everyday daily life.
  - xodn348•1d
    만나서 반가워요!
    What you talked is mostly right and I did not know about typing in Korean, the left-hand side and right-hand side. Btw, Consonant(Jaeum) and vowel(Moeum).
    In experience-wise, what you had would be precise.
niyikiza•5h
Cool project! I went to a Korean university more than 190 years ago and can only speak basic Korean but going through your examples seem to be improving my Korean vocabulary!
ovciokko•23h
This is indeed a cool project! Happy to see experiments on non-English programming languages. I have one question — not trying to be offensive or doubting, just out of curiosity — does Han make use of the unique properties of Hangul (or Korean in general)? Like, I remember sawing a Turkish programming language on HN the other day, and I might be wrong but my impression was it makes use of some syntax unique to Turkish, and I wonder if Han has similar features. Or, asking it differently, if I replaces only the lexer to another lexer recognizing a different script, will it not work?
- xodn348•23h
  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.
  - ovciokko•22h
    Thank you for replying! As a non-English speaker too, I always love to see people trying out new things different from the English mindset. Hangul is a very cool writing system and I'd love to see Han live and evolving.
geokon•20h
Have you considered rotating the layout? I always though a CJK programming language written vertically would be very ergonomic. Instead of scrolling vertically the program would flow right-to-left or left-to-right. I guess you'd probably want to rotate the bracket/paran glyphs which is a bit less trivial to do
dwg•21h
@apt-apt-apt-apt pointed out in a separate comment that: >A simple translation of keywords seems straightforward, I wonder why it's not standard.
I replied that for Japanese at least, probably due to symbol input being too tedious. However I think it's worth mentioning a potential mitigation, and maybe even an advantage.
As a mitigation, full-width symbols could be used instead, which are typically the default in Japanese input. Japanese itself is also fixed-width so if done across the board the language itself becomes fixed-width, not just by virtue of a font selection.
As an advantage, some logical symbols, greek letters, other rare characters are easy to input in Japanese mode, and this could lend itself to a more symbol-heavy language design. I already take advantage of this myself with Δ, φ, and τ use selectively in a few projects. Symbols with easy entry may differ by OS, but here are a few other examples that could be useful:
≠, ≡, ∞, ∴, λ, θ, α, β, ・, °, ※
- numpad0•20h
  Japanese input system do allow use of arbitrary UTF-8 symbols, but you have to type out the "pronunciation" for symbols, e.g. "nottoiko-ru" for ≠, "goudou" for ≡, "yueni" for ∴, "ramuda" for λ, etc. Just using "!=" is faster.
  - dwg•11h
    In case it was not clear, that is exactly my point: a language designed for Japanese could open up the possibility of incorporating symbols other than those readily available on QWERTY keyboards.
    And my other point is that != is _harder_ to type in Japanese input mode because you constantly have to manage full-width vs half-width input.
water_badger•1d
fun fact, you can easily write c in any language you want through the power of macros
https://github.com/farant/rhubarb/blob/main/include/latina.h
edit: oh, maybe you can’t do full unicode. that’s too bad!
- xodn348•24h
  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.
  - water_badger•24h
    yeah, making a whole language is way more impressive!
    anecdotally it is also interesting to use with ai because apparently it is "harder to be on autopilot" based on a huge pre-existing corpus of code when you write it in a different language. could activate different reasoning regions somehow.
    (i just appreciate what can be trivially accomplished in c even if it's kind of janky after spending way too much time in the JS preprocessor mines...)
zx13719•16h
Great work! I still remember my high school IT class, where teachers were using multiple languages to explain the functionality of different 'modules' in programming language (it was still python 2.x back then), and by that time I was trying to do a 'multilingual' programming language (tbh it was just changing variables into different languages), and now 10 years have passed, and the dream is finally catching up with me.
sabzil37•5h
This looks like quite an intriguing project. I think it would be even more compelling if it featured a JS live compiler for immediate browser execution.
lgessler•22h
I know this is mostly about keyword substitution but it still tickles me that you still write f(x) in this language and not (x)f given that Korean is SOV but I guess that's just how you notate that no matter what cultural context you're in. Hadn't ever considered that the convention of writing a function before its arguments might have been a contingency of this notation being developed by speakers of SVO languages.
- localuser13•22h
  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).
  - borski•22h
    …if you’re typing from left to right. :)
- cubefox•22h
  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.
technol0gic•1d
i only code in this when no ones around. one might say I...han solo
- xodn348•24h
  Force for good be with you
anesxvito•24h
Really cool to see more developer tools built in Rust. I've been using Rust for a desktop app backend (Tauri v2) and the performance difference vs Electron is night and day — native memory usage, instant startup. Curious what the compile times look like for Han compared to rustc itself.
xukeek•22h
Curious about the name — if the language uses Korean (Hangul) keywords, why call it “Han”? In Latin letters that usually reads like the Chinese 汉 (Han) / pinyin rather than Korean. Is there a specific reason for that choice?
- hangil131•6h
  It is "韓(Han)" not "汉(Han)" just same pronouns. Currently, The short name of "Korea" in korean is "한국(Hanguk)" it means "Han contry" so all the identity of korea is in "han"
WillAdams•23h
Have you looked into whether there are any Hanja (Chinese characters) which would be sufficiently expressive to warrant supporting as an alternative way to represent keywords?
Perhaps look to APL for efficient ways to represent math concepts/structures?
- xodn348•23h
  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.
  - WillAdams•11h
    Yes, but there is a potential for increased expressibility with Chinese characters which I've always found evocative and beautiful --- perhaps if there is some keyword which is long/awkward a character might be a better fit? Or would it work for a user to choose Chinese characters for module names? But also yes, I'm an old-fashioned sort of person as my kids are constantly pointing out, and moreover, it's not like I ever did much of anything w/ the 500 characters which I memorized after my graduation proficiency test (pulled them out for a couple of projects in college...)
    \begin{quotation}
    \emph{The beginning of wisdom is to call things by their right names.}
    --- \textsc{Confucius}
    \end{quotation}
    Very glad /u/faitswulff mentioned Wenyan (though I'm bummed that there are only simplified Chinese and Japanese translations).
- faitswulff•21h
  If you’re interested in Chinese characters, there’s https://github.com/wenyan-lang/wenyan
  - WillAdams•11h
    That is _very_ cool! Starred!
    Maybe one day someone will write a Korean translation for the book....
icase•6h
why ruin a beautiful language like korean with an awful language like rust?
all2•22h
So... iirc Korean words are constructed out of symbols, would it be possible to mutate the meaning of keywords by giving the symbols meaning and constructing new blocks of symbols?
- xodn348•21h
  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.
kreicer•19h
This is an interesting approach. Using Korean identifiers gives the code a very distinctive look and makes the project stand out. However, from a collaboration perspective it might reduce readability for contributors who are not familiar with Korean.
bouncycastle•23h
I'd imagine that a transpiler for Perl with this idea would make one-liners even more potent.
delibae•15h
Great project. As a Korean CS student I always wished Korean had more presence in dev tooling. Nice to see this getting traction on HN.
anigbrowl•22h
I wonder why there are not more programming languages not only with non-English keywords, but with different grammars. For example, if X then Y and many other constructions closely follow English grammar, but when you study other languages you quickly become away of many other possible constructions.
- dmurray•22h
  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.
- whacked_new•20h
  I'm a little sad that VSO languages didn't start the computing revolution because if they did, we would all be writing LISP. But instead, we are relegated to Python and JavaScript!
  - b3orn•13h
    Considering that Korean is an SOV language it would've been interesting to see that factor into the design of this programming language.
clark1013•21h
The name reminds me of the character Han from Broken Sisters.
marysminefnuf•1d
My dream is to one day make a chaldean programming language for my kids. Stuff like this is inspiring
- xodn348•1d
  The fact that you're already thinking about it means you can do it. Go for it!
zlfn•16h
It's been a long time since I've seen a properly implemented Korean programming language
tw1984•22h
The name is interesting, it is just like some aussies creating a new language calling it Anglo.
hudsonhs•11h
Wow this is the Choson language
AndrewKemendo•23h
I’ve always wondered why there weren’t more non-english charactered programming languages but I can only assume it was just inertia
This seems like a reasonably good security measure too
- hangil131•6h
  I'm not sure inertia is correct for this. I think the reason is there are no needs for non-english charactered programming languages. Let's think about there are perfect program language made with Korean. If you are programmer, then you already know program languages made with English even if you are not a native speaker. Now you have to learn "New" program languages. You are native Korean so maybe have some advantage but it is still new thing. If you are not programmer yet. You have to learn program language, in this case most users are already using traditional program languages so you can't skip Python or C or Java.
- whacked_new•20h
  I think another part of it is culture. Outside of Western tech circles there's far less a culture (it feels) to invent new languages. To my knowledge Ruby's Matz is the only notable exception, and he's highly unusual as a Japanese. Then, using non-ascii-friendly character set is an even greater challenge.
  Non-ascii encodings are harder to program in due to the need to switch in and out of input methods.
  That said, some languages like Arabic and Japanese (and possibly Korean and Hindi) lend naturally to VSO token ordering, which maps directly to LISP syntax, so it's unfortunate that there isn't a lot of interest in this. It would be lots of fun. Maybe agents will make this possible!
  Here are some interesting examples.
```
    - https://github.com/nasser/--- (Arabic)
    - https://honoka.nukenin.jp/Introduction/Loop.html (Japanese)
    - https://github.com/wenyan-lang/wenyan (Chinese, which is SVO like English)
```
  - willismonroe•11h
    My colleagues and I wrote a programming language (really just a python wrapper on unicode characters) in cuneiform. The novelty was that we tried as much as possible to use actual mathematical concepts from 3rd (and early 2nd) millennium BCE Mesopotamia. We published it in Sigbovik 2024 (https://www.sigbovik.org/2024/proceedings.pdf) as well as a full neural net implementation using the language.
- booleandilemma•20h
  Using english for your programming language gives you the widest audience.
AndrewKemendo•23h
I’ve always wondered why there weren’t more non-english charactered programming languages but I can only assume it was just inertia
metalman•13h
NK Emperor Kim King Dong * ,thanks you, and may have a job offer!
* , realy hope this isn't unforgiveably offensive.
sudo_cowsay•23h
Imagine if you had to work with a Korean company using this
Amazing though!
kaihong_deng•5h
good job！