I really don't think that worrying about what symbols Hoon uses is productive. There are tons of worse things to say about Urbit than "once it becomes bigger than C, how will Japanese people code it"
Arabic and Japanese people have been using C and Javascript just fine, so I'm not sure even in the hypothetical future it would be a problem. And if it is - Hoon has keyword style now ("|- a/@ (add 5 a)" can be written (":gate a/@ (add a 5)"), or barring that the language rune parser can be replaced with a simple gsub in the source.
Hoons runes are really just names for which AST node it is, so it would be trivial to make a smartphone Hoon editor that works like Scratch or Lisp instead of textual.
Hell, Hoon compiles down to Nock, so you don't even have to use it, just write another language that targets Nock instead.
Japanese is actually not the best example of "bracket pain" - in order to type in Latin script at all, you need to shift completely away from "native" input, as the various methods for typing kanji and kana tend to be some variant of lookup (via eg pronunciation) - select (like tab completing identifiers).
Thus, it makes a lot of sense to simply switch input modes and maybe even keyboard layouts.
Now, for something as close to English as Norwegian - you have a rather different touch layout due to having 29 letters. This is actually one reason I like python - less gymnastics due to less curly brackets.
Another problem with using ascii, is that now even code comments need to be in English character set in practice. Never mind function names etc.
Utf-8 by default is actually great in the programming languages that support it.
Don't mistake "have been tolerating absurd limitations of C" with "greatly enjoying the backward limitations of ASCII".
I'd actually have to check if Urbit supports utf8 code. I want to say yes, since the compiler internals technically can, but it's probably not hooked up correctly.
Are there any languages do this right? Even if identifiers can be utf8, they still have English reserved words. Maybe something like Forth, where the entire language is redefinable. Or, I dunno, Smalltalk.
It's not just Arabic and Japanese. My Swedish/Finnish MacBook keyboard doesn't have the | and ~ characters printed anywhere on the keyboard. To type them, you just have to remember where they are. That's ok for me as a programmer, but doesn't work for anyone closer to a general user, which Urbit seems to expect because these symbols are used extensively in the command line UI.
Realistically there's no reason the interface can't simply autoconvert some arbitrary unicode character into a |, and leave that as an extension for anyone to add to whatever arbitrary language
It matters for reading/writing code, having uniform syntax, but it hardly matters for a general user's usage (in fact, I'm just talking about an alias, and its not so troublesome).
And regardless, this special character issue likely exists for any character; I imagine few are consistent among all languages, appearing on all keyboards.
So its just a pick your poison and stick with it situation, and whaddyaknow, English is still the most common internet language, and perl/bash have already ensured that most programmers have had to deal with these characters for decades
Arabic and Japanese people have been using C and Javascript just fine, so I'm not sure even in the hypothetical future it would be a problem. And if it is - Hoon has keyword style now ("|- a/@ (add 5 a)" can be written (":gate a/@ (add a 5)"), or barring that the language rune parser can be replaced with a simple gsub in the source.
Hoons runes are really just names for which AST node it is, so it would be trivial to make a smartphone Hoon editor that works like Scratch or Lisp instead of textual.
Hell, Hoon compiles down to Nock, so you don't even have to use it, just write another language that targets Nock instead.