Julia puts emphasis on the possible use of non-ASCII symbols in code. Most of supported operators are Unicode characters, some well known mathematical symbols (albeit practically unseen in programming), some are quite obscure. Many standard library functions use Unicode operators along with their ASCII versions. Although x ÷ y does look nicer than div(x,y), my keyboard has no “÷” and I don’t want to look for it every integer division. Do you use the fancy charac when writing Julia code?

I use them all the time. My keyboard has no α, β, γ, either, but I can type them with one mode key, just as we use the shift key for Uppercase Letters. My keyboard also doesn’t have ñ, é, or ç, but I can type them by hitting another mode key and two additional normal keys. I need these for writing Español, and the Greek ones for writing math in LaTeX and Typst. So when I started using Julia I was already used to typing all kinds of characters. My suggestion is to pick an input method for your platform and begin using it to type the characters that you need in every context. It quickly becomes automatic, and you’ll be freed from the tyranny of ASCII.

You know, I don’t think that’s completely useless. It reminds me of APL, and since, sadly, APL.jl seems to be unmaintained… (The one for dump made me LOL.)

I just want to mention that Japanese (and probably Chinese?) speakers can naturally type Julia’s unicode symbols. We just use the IME: We just type π, α, ∫, ÷, . . . in the same way as we type 漢字 (Chinese characters). The idea is that you can get such conversion as \sigma to σ to work everywhere, not just on Julia editors. (To avoid explaining exactly how Japanese IMEs work, I’ve just used an analogy.) I hope that use of unicode symbols will be common enough that somebody will develop an unicode IME for other peoples who normally don’t need IMEs to type their own languages. Every modern OS (I think) has a mechanism to write an IME plugin.

I find it hugely useful to define a suitably rich keyboard layout so that all those mathematical Unicode symbols actually are on my keyboard: [image] Can package names contain non-ASCII characters? General Usage Total side note, and shameless self-promotion, but The "U.S. International - Scientific" Keyboard Layout - Michael Goerz Still: do not require Unicode in the public API of your package; you can use something like function f(; eta=1.0, η=eta) end if you want to allow for Unicode in your API, in addition to ASCII. Certainly, do not require it in your package name. Internally, you can go wild. But also: know your audience. What might be a useful addition to the heavily mathematically educated u…

Yes. For Chinese using 中文代码快速补全 - Visual Studio Marketplace we can avoid switching system IME and type Chinese inside VSCode very fast.

I once found a UNICODE keyboard Nemeio - The customizable e-Ink keyboard Nemeio is a new generation keyboard. You are now totally free to choose how you use your keyboard with Nemeio’s customizable keys that is adapted to your specific needs. [image] A Unicode keyboard? Offtopic I routinely use about 100–150 Unicode symbols (in addition to ASCII), mostly Greek letters and math operators. I find it much simpler to remember the \ sequence since I already use it for LaTeX, and just set up Emacs to complete/replace these. I don’t think I would be touch-typing if I had to remember where eg \varphi is — instead, I would spend 5 minutes finding it on the keyboard. I even replaced my Android launcher with https://github.com/fAndreuzzi/TUI-ConsoleLauncher so I can just type a…

Unicode gives Julia a level of mathematical expressiveness that most programming languages do not have. For example, below is a cubic-equation solver I wrote that works generically with any AbstractFloat type. solve_cubic(a::T, b::T, c::T, d::T) where {T<:AbstractFloat} "using Cardano's formula. Returns all three roots as `Complex{T}`." function solve_cubic(a::T, b::T, c::T, d::T) where {T 0 # One real root and one complex-conjugate pair δ = √Δ u = ∛(-q / 𝟐 + δ) v = ∛(-q / 𝟐 - δ) t₁ = ℂ(u + v) t₂ = -(u + v) / 𝟐 + im * (√𝟑 / 𝟐) * (u - v) t₃ = conj(t₂) elseif Δ < 0 # Three distinct real roots r = 𝟐 * √(-p / 𝟑) φ = acos(-q / (𝟐 * √(-(p / 𝟑)^3))) πₜ = T(π) t₁ = ℂ(r * cos(φ / 𝟑)) t₂ = ℂ(r * cos((φ + 𝟐 * πₜ) / 𝟑)) t₃ = ℂ(r * cos((φ + T(4) * πₜ) / 𝟑)) else # Multiple roots u = ∛(-q / 𝟐) t₁ = ℂ(𝟐 * u) t₂ = ℂ(-u) t₃ = t₂ end return t₁ + x₀, t₂ + x₀, t₃ + x₀ end

There are multiple aspects of unicode support. The first is “prosaic” runtime support: This like String handling unicode just fine, the imo nice design decisions on how to handle invalid utf8 strings, indexing via code-units, etc. This makes writing code that deals with unicode not overly painful. The second is “prosaic” toolchain support: The julia parser doesn’t hiccup if source-code comments contain non-ascii things, you can write string literals with the actual unicode, etc etc. This is not a high bar, but works without issue (…remember the olden times with bibtex choking on non-ascii?). This is important! And it’s not half-assed like in java (\u1234 get unescaped before tokenization, String a = "\u0022"; ftw) Then there is the surface-syntax language support, the contentious “unicode in identifiers Symbol position” during parsing / tokenization. I view this as a terrible anti-feature, actively hate it and give my best to never use it. That works mostly OK. My main complaint is that xor didn’t get an infix ascii version. We have precedent for a lot of multi-character infix ascii operators, e.g. in, =, =>, !=. Can’t we get something like that for xor? And before people complain about anglocentrism: That is baked in too deeply anyways. I’m a German and a mathematician. The ubiquitous choice of \ as escape character or / as path separator produces enough carpal tunnel syndrome on German keyboard layouts that most German coders stick to US layout anyways – typing Gruesse or Gr\"u\ss{}e in latex is totally fine (Grüße for Grüße in html is not fine – that’s too long), and thankfully latex supports utf-8 now such that copy-pasting or layout switching also works. I never got why people want fancy chars in their code – sure the Δ looks nice on blackboard, paper and pdf as latex output, but in the monospaced plaintext world you “obviously” should prefer \Delta in latex source and delta or Delta in julia source (unless you’re typesetting a greek text in latex). Your @karei 's example makes the point: ∛(-q / 𝟐 + δ) is worse as plaintext than cbrt(-q / 2 + rho ), and is just shitty typesetting compared to \sqrt[3]{-\frac q 2 + \delta} or \sqrt[3]{-\frac q 2 + \delta}

Not only do I use it, I also probably abuse it, with characters like 𝒞 and 𝐼. But it feels so great.

I’m guessing you don’t like APL.

Do you use Julia's extensive Unicode support?

General Usage

johnh June 22, 2026, 3:36pm 16

I once found a UNICODE keyboard

Topic		Replies	Views
Unicode: a bad idea, in general General Usage	83	5945	June 17, 2023
Syntax: Escape hatch for unicode haters Internals & Design syntax , unicode	124	7319	January 16, 2024
Warning against Unicode confusables Internals & Design unicode	50	3324	January 13, 2024
Fonts in VS Code VS Code	26	4400	August 29, 2022
Tab completion of \uXXXX in the REPL? Internals & Design unicode	23	5075	January 12, 2024

Do you use Julia's extensive Unicode support?

Related topics