Myna: Monospace typeface designed for symbol-heavy programming languages

Design goals and scope

  • Font is positioned as an ASCII-first, monospace typeface tuned for symbol‑heavy languages (Perl, Haskell, etc.).
  • Key idea: multi‑character operators like ->, >>=, ::, <$>, etc. should look visually cohesive without using ligatures, so it works in terminals and editors that don’t support them.
  • Designer emphasizes adjusted angles, weights, and spacing of operators (<, >, -, ~, backtick, colon) to better match real-world code usage, rather than traditional text typography.
  • Font is condensed horizontally to show more code per line; derived from a customized Source Code Pro with influences from other mono fonts and built in FontForge.

Symbol alignment and readability

  • Some commenters say they can’t see what’s special about the symbols and request side‑by‑side comparisons with other monospaced fonts.
  • A comparison table was later added, which helps some readers see the differences and motivates trying it for Perl/Haskell.
  • Others feel aligning symbols to brackets and caps makes dashes, colons, and angle brackets look too high next to lowercase letters, especially in HTML/XML/C++ generics.

Glyph choices: mixed reactions

  • Curly braces are the most polarizing: some find the “S‑shaped” style noisy and distracting; others like how clearly they differ from parentheses and how they match how they’re handwritten. A “disambiguated braces” variant is suggested.
  • Multiple comments criticize l vs 1 similarity; the designer is open to a variant that changes l.
  • Kerning in text samples (e.g. “Lorem”) bothers some; designer prioritised strict centering over nuanced kerning.
  • Caret ^ height and vertical “ASCII arrows” (^/v + |) trigger a long subthread; many consider that use extremely niche and prefer preserving the traditional elevated caret.
  • Em dash is acknowledged as poorly distinguished from dash due to monospace constraints.

Ligatures, Unicode, and arrows

  • Font intentionally avoids programming ligatures; designer and some users prefer explicit ASCII sequences for portability and clarity.
  • Long debate over whether -> should just be a Unicode arrow:
    • Pro‑Unicode side: languages and tools increasingly support Unicode identifiers and symbols; editor macros or keybindings can insert arrows directly.
    • Anti‑Unicode side: typing such symbols is awkward on standard keyboards; ligatures and Unicode arrows can break search, selection, and semantics in languages where -> and => are distinct tokens.
  • Several note that Unicode and full‑width glyphs don’t fit well with monospace constraints; Myna covers Latin extended and a subset of Unicode but is not trying to be a Julia‑style full‑Unicode code font.

Comparisons and usage preferences

  • Many compare Myna to Iosevka, Ubuntu Mono, JetBrains Mono, Intel One Mono, Cascadia Code, Go Mono, IBM Plex Mono, JuliaMono, and others.
  • Some love its compactness and aesthetics; others find it less legible than their current choices.
  • Discussion branches into broader topics: monospaced vs proportional fonts for coding, font size and high‑DPI displays, and how much font choice matters versus actual coding.