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.
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!
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.
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).
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.
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.
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.
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.
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.
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.
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...)
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.
reply