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?
Not sure I use the “extensive” unicode support, but in frequent use for me are
≤ ≥ ∈ ∉ ₀ ₁ ᵢ ₜ
and greek letters α etc.
Note that Unicode characters can be typed in the REPL and supported editors by tab completing their ASCII name, so you don’t have to “look for it” if you can remember its name.
help?> ÷
"÷" can be typed by \div<tab>
second that. (I sort of use what is not easily confused with other symbols and what sublime_text can easily type.)
As a dinosaur from the DOS days, I use almost nothing but ASCII.
Quite a few folks do - I keep (for my own purposes 
) a collection of code snippets where people like to use Unicode creatively. But in general people don’t use them in registered packages, as there’s a convention to use mostly ASCII for public interfaces.
I think the Algorithms for Decision Making book shows some common ones (a lot of Greek and Math Script glyphs):
I use them, my AI agents use them, my TUIs use them too. Here’s a little … erm … something … displaying all the actual unicode characters used in source code in a couple of my projects 
In a single easily recognizable symbol you can clearly communicate a concept within a specific context/field. Yes, I use them, and yes its worth typing \sigma to get σ instead of sigma. The set operators are also quite helpful.
I don’t use unicode characters in code, mostly because I don’t want to try to explain how to type it to new research undergrads and/or elder colleagues. That said, I make heavy use of it in comments, as it’s great for writing out equations, especially with the LaTeX-like backslash-command syntax. Rather than having to write raw LaTeX code or something, I can just say “this function implements this equation from this paper/book”, type the equation out in Unicode and move on, which is nice.
I use them when they improve code readability – greek letters in Formulae or whey they then agree with the paper something is based on.
Of course you can “properly” make use of them even more and use 
.jl! The package could sadly not be registered under that name, so there is the fabulous GitHub - JuliaWTF/WatchJuliaBurn.jl: The most unneeded package you'll find. · GitHub
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:
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
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.
"using Cardano's formula. Returns all three roots as `Complex{T}`."
function solve_cubic(a::T, b::T, c::T, d::T) where {T<:AbstractFloat}
iszero(a) && throw(DomainError(a, "a must be nonzero"))
# Normalize: x³ + bx² + cx + d = 0
b, c, d = b / a, c / a, d / a
𝟐, 𝟑 = T(2), T(3)
ℂ = Complex{T}
# Depressed cubic:
# t³ + pt + q = 0, x = t - b/3
b², b³ = b * b, b * b * b
p = c - b² / 𝟑
q = 𝟐 * b³ / 𝟑^3 - b * c / 𝟑 + d
Δ = (q / 𝟐)^2 + (p / 𝟑)^3
x₀ = -b / 𝟑
if Δ > 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
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.