Hacker News new | past | comments | ask | show | jobs | submit login
Dev Fonts (gafi.dev)
642 points by syck 12 days ago | hide | past | favorite | 333 comments

My favourite monospaced font is Triplicate <https://practicaltypography.com/triplicate.html>: the only true serif monospace that I know of (though I have a vague feeling I found one other at some point). Every other serif monospace I know of is a slab serif. Triplicate’s variable stroke thickness is also exceedingly rare in monospaced fonts; almost everyone goes for uniform stroke thickness, as is customary with sans-serif fonts but anathema for true serif fonts (though slab serifs could be either). Variable stroke thickness can be a bit iffy on low-resolution displays, but so long as you keep the size up or use a high-resolution display, I find it very pleasant. I’ve been using Triplicate everywhere for the last few years, including on my website.

(Also note on that page, since people are talking about ligatures a lot in this thread: “No, there are no programming ligatures in Triplicate, and there never will be.” with a link to https://practicaltypography.com/ligatures-in-programming-fon..., which can be distilled to the quote “ligatures in programming fonts are a terrible idea”. I agree.)

Pragmata Pro and Operator are two other well-regarded and popular commercial monospaced fonts that are missing from this list.

Triplicate has a nice look, but l (lowercase L) and 1 (one) are indistinguishable, which is an immediate non-starter for me in a programming font. (CORRECTION: there is apparently a code version that disambiguates these and others. See comments. That means this probably would be a candidate font for me, except:)

I finally just paid for Pragmata Pro, and haven't regretted it. The unicode support is incomparable, and for someone who lives in emacs and console, support for things like the Powerline glyphs and the option to use Emacs' prettify-symbols mode means an awesome user experience.

I actually like ligatures when reading code, less so when writing. The thing I like about prettify-symbols and a font like pragmata pro is that I can toggle between strict representation and a cleaned up version with things like the below replacements:

  (defun aja/pretty-symbol-push-default ()
    (push '("!="      . ?≠) prettify-symbols-alist)
    (push '("<="      . ?≤) prettify-symbols-alist)
    (push '(">="      . ?≥) prettify-symbols-alist)
    (push '("=>"      . ?⇒) prettify-symbols-alist)
    (push '("->"      . ?→) prettify-symbols-alist)
    (push '("lambda"  . ?λ)prettify-symbols-alist))

There's a code variant that disambiguates 1 and l (and others).

But it makes the code Small Caps, which I find unusable in code.

I think you’re confusing Triplicate C4 (C for Caps) with Triplicate T4’s Code variant (T for Text).

Didn't notice that. Thanks for the correction.

PragmataPro compromises readability across the board - here is why: It is compressed/condensed to allow for shorter line widths but legibility suffers.

Put up 2 exactly same code snippets side by side. One in PragmataPro and one with SF Mono (or Consolas, etc.).

I purchased PragmataPro but regret it. Now I use it on Mechanical Drawing dimensions :) It is fantastic in CAD.

I actually like the reduced width because of the way I arrange edit panes, and after a brief adjustment period, have no readability issues at the font sizes I typically use. That's a personal taste thing, though, so I can see that others wouldn't like it. The 'm' glyph is a useful bellwether/canary in that it becomes difficult to distinguish the legs before most other glyphs become problematic. I tend to adjust the font size to one level above where the m's start turning into bricks, and have no readability issues, and still ample horizontal space. I don't generally use the font for publication to others (although I'm experimenting with its use in code blocks). I do often use it in projecting demonstrations to students, although that's typically at a large font size, when the legibility isn't much of an issue, but the narrowness is an asset.

The homepage includes snippets of both the regular and code variants, and they do look pretty distinctive in the code variant.

Which weight of Pragmata Pro did you purchase and use for emacs? Just wondering if I should get all of the weights which is super pricey or I only need Essential PragmataPro Regular/Bold.

I got the full version, but the nature of my job means I can claim a significant part of the cost against my PD funds (It's mostly for books, but I already own more unread technical books than I can complete within my expected lifespan. Thankfully they opened it up to allow software.) I think just the essential would be plenty for the majority of users.

Thank you.

Personally, my eyes and brain just can't scan ligatures in code efficiently, I have to double read the code, especially "is that =, ==, or ===? Oh, and that's !=="

(edit) I'll additionally qualify my comment, from a mathematics background I can casually scan a handwritten "!=" which is the same as the ligature, but I just cannot retrain my adult brain to accept the ligature version which is the same as the handwritten one. Brain plasticity I suppose.

Seconded. I get it for math but, it's just super confusing in code. Like, most of us agree "there should be one obvious way to do it" in code. Why don't we think the same about what code looks like? That feels much more fundamental.

Obligatory digraphs/trigraphs reference: https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C

I find some ligatures help a lot. I can often miss != but won't miss ≠ or ≢

I think the whole idea of pre-pending ! to negate is a poor idea in general, it's too hard to spot especially in long convoluted lines where it's just thrown in before a complex bracketed expression.

Even looking at what you've typed was hard for my old (!!) brain to read, especially != and !==.

It's brain training - you find "!" hard to spot, and I don't. And vice versa for ligatures. Thank goodness we both have choices!

I sometimes use a triple negation !!! for that reason. I don‘t know if there are any drawbacks, especially if there are other people working on the code, but it worked pretty well for me so far.

That might work until there's somebody who uses double negation !! for some reason. But this might only be common in JavaScript, so YMMV.

I had to google this to see why on earth you would use double negation.

Apparently it's a way to negate and convert to boolean.

Yes, it's one of those dirty JavaScript tricks that abuse type conversion. Negation converts anything into a boolean, so if you negate that again, you get the equivalent of converting the into a bool. In standard (old) JS fashion, it's both slower and less readable, but people still (used to?) do it. Similar hacks include 1* for num->string and +"" for the opposite, along with several others that I have luckily managed to forget.

I've never had to use JavaScript, but I've done the *1 or &"" in Excel to force conversion to the desired type... yes, let's mercifully lay the veil of forgetting over this.

Considering Excel's offical way of writing a != b is a<>b, I think these kinds of hacks there can be excused :)

a<>b is the preferred syntax in SQL. I'm pretty sure a!=b works everywhere these days, but that hasn't always been the case.

(eta: didn't finish the thought - I'd assume SQL influenced Excel, since it's older.)

As I'm not keeping up with recent progress of the language, how would you do that today?

If x is your variable, you can just do Boolean(x) rather than !! to make it boolean. E.g. it will convert undefined, null, 0, "", and NaN to false.

This is a much more readable cast.

Personally I think it is a good rule to never use Boolean(x), String(x), etc.

The problem is that many developers are unaware that `const s = new String(x);` creates a string Object. It looks like a string, and acts like a string, except that in some places it is not a string: for example `typeof s` returns “object”! Same problem for Boolean, Number, etcetera. Yes casts are ok, but it is easier to just say never use the value object keywords because you can end up with very wierd bugs a long way from where the value object was created.

Another example:

    let x = new Boolean(true);
    console.log(x === true);
Gives false.

Okay, thanks. And why would it be faster? Optimizing !! in the JS engine seems trivial to me.

I suppose it would be easy and might already be in some engines, but it's still discouraged because you can't rely on that optimisation (there are many engines), it's semantically incorrect, and most importantly much less readable - especially for someone not tok familiar with the JS type system.

Not for comparison, but for boolean checks I prefer to use `foo == false` instead of `!foo`, the latter is easy to overlook.

I've recently started using a kind of middle ground by putting spaces around the !. Makes it harder to miss without losing the "reads like text" property that's lost when using == false.

if ( ! isLast(e) ) reads perfectly, especially since my native language doesn't insert the "not" im the middle like english does and my brain is used to that. if (isLast(e) == false) just jolts me out of that state where code reads as fluently as text. YMMV, of course, and I have a suspicion that your native language might play a role in that...

Do all languages have `foo === false`? When testing booleans, I always do the type specific test to avoid `foo = 0 !== false` stuff

> Do all languages have ...

Of course not

This looks really nice, too bad it doesn't (and never will) support ligatures. I understand the point the author is trying to make about ligatures in the separate blog post, but boy do I love my ligatures when programming.

The blogpost makes some good points, but it's extremely selective in choosing examples to support the author's thesis.

Mainly in that it ignores many examples of orthographic ligatures that don't fit the author's narrative. A (further deep-)linked blogpost on ligatures in general states:

> Ligatures were invented to solve a practical typesetting problem. In the days of metal fonts, certain characters had features that physically collided with other characters. To fix this, font foundries cast ligatures fonts [0]

But that's not true. That is why ligatures are used by many foundries more recently, but it's not why they were invented, and it doesn't cover all traditional uses of ligatures. German and French orthography in particular contain a lot of examples that are closer to programming operators in use than the author's "fi" example.

[0] https://practicaltypography.com/ligatures.html

To me, ligatures in programming always file like a kind of syntax highlighting if that worked on the character level rather than the token level. Suppose given `difficulty = 3` your editor would highlight the `if`. That's how these ligatures feel to me.

That doesn't usually happen, though.

For example, if you type three '=' symbols in Firas Code or JetBrains Mono, you get ≡, but if you type a fourth '=' it snaps back to '===='.

I can invent some odd situations where I get a ligature in the middle of a string, but in actual coding (for me 80% JS, 10% HTML/CSS and 10% Ruby) I simply don't see any incorrect ligatures.

But most text editors don't render ligatures if the characters span token boundaries. Sublime Text at least doesn't.

How do you plan to reverse engineer the underlying keystrokes if you look at some ligature ridden code on a tutorial website?

It is nice to read. That's not the only thing we do with code. Ligatures are fine for yourself in a private setting.

It's popularity is alarming.

> How do you plan to reverse engineer the underlying keystrokes if you look at some ligature ridden code on a tutorial website?

Copy and paste it in a different font.

Well, you just have to learn all the popular ligature forms, just like you have to learn all the popular variations of letter forms (e.g. "a" and "g" both have very different variations that are popular in different typefaces).

I am not fan of ligatures because of the (although small) mental gymnastics that have to happen when reading code. It's unnecessary.

I got used to them really quickly to the point that I prefer them over regular characters. No mental gymnastics required.

Can you easily differenciate between == and === with ligatures ? That's one thing that holds me back to trying ligatures.

Yes, it’s fairly obvious. It depends on the font, but my triple comparisons actually have three bars (you can see it in the examples I think)

Of course. A `==` is two characters long, while `===` is three characters long. Also, with the font I use (Fire Code) the `===` ligature has three lines, making it even easier to distinguish.

I just had a look at Fire Code. How do you distinguish -> with ligatures from → (an Unicode arrow)?

Personally, it’s never really come up. I have no Unicode arrows in my actual source code.

On the occasion it’s in a string literal or whatever the it’s pretty obviously different, because it’s a single-width character as opposed to the double-width ligature.

The ligaturized -> is two characters wide and is pretty easy to tell apart.

So it looks like U+27F6 ⟶ rather than U+2192 →?

Sure, but in a monospaced font both of those arrows would have to fit into the same small box, so 27F6 might be the full width while 2192 would be some partial width, while a -> ligature would be two widths.

The Unicode arrow looks smaller and is positioned lower, while the ligature has the same size as -> with the dash extended into the 'arrow'. Not that I use this frequently.

The Unicode arrow is most likely throwing an error in the linter or compiler and is underlined with a red line.

For me, I just selectively use _some_ ligatures. There are a few I like (like a lambda symbol instead of `fn` in Clojure), and the rest I just don't use.

yes because === is presented as a three long parallel lines (at least in the font I use, which is JetBrains Mono)

“ligatures in programming fonts are a terrible idea”

I agree as well with the point about ligatures, but I find funny that the advice comes from a site that thinks straight up normal text with no hover, no distinct color, no distinct font and no underline is a good way to signal linked pages https://i.imgur.com/9iVMfgD.png (who would have guessed Racket was a link?)

"Ligatures in programming fonts—a misguided trend I was hoping would collapse under its own illogic."

The same could be said about so many programming conventions most people take for granted. Sometimes programmers are their own worst enemies. "just because you can doesn't mean you should" is probably the #1 rule of programming, at least for me, and ligatures definitely fit into that category.

I certainly don't blame you for not noticing the `#fbf3f3` background color on hover. However, it seems that every link is either small caps or has that trailing ° character. It looks like the former is used for internal links, and the latter for external. I agree that they're certainly not screaming, but considering that the author considers this a book, that is probably by design.

then again, the signature is indistinguishable from small cap and isn't a link

In short it’s a design choice paying homage to some other books, as well as to make the reading experience less distracting. He has a whole page explaining here, https://practicaltypography.com/how-to-use.html

It's a pretty interesting approach to the website and there's some features I never would have discovered on my own, but the author's reasoning seems pretty poor. The premise being that multi-line stretches of underlined text are difficult to read, therefore link-text (typically 1-3 words) should not be underlined.

It's also quite ironic that the author's argument against ligatures in programming fonts is that the simple substitution doesn't respect semantic difference, whilst using emphasis to signify that there is a link present

...and then he decided to put his name in small caps under the ligature article, and that one isn't a link.

I'm not a fan of symbol ligatures but what I really loathe are monospaced fonts with a single character width fi ligature so the f and the i are both half width. I've seen several websites recently using fonts that do this. It is very visually distracting, especially in code samples.

Really? So it's not monospaced? I'm having trouble imagining any monospaced font doing this.

(The ligatures in fonts such as Fira Code take up the same amount of space as the non-ligatured versions.)

On Macs, Courier (but not Courier New) can do it, though not by default.

(Open up TextEdit, enable Rich Text, select Courier, type "ff", highlight it, go to Font > Ligatures > Use All. The "ff" will now take up the width of a single character.)

I've run into a bug where certain styles of Courier Prime turns into ligatures in Google Docs. (Long story short, whether or not ligatures get enabled is a complex interplay between the OS, font, browser, and application, and not every layer always does it right.)

I'm not really sure why font designers even bother creating them in monospace in the first place though, I can't imagine any valid use for them. The only thing I can imagine is if a badly written application forces a ligature character, at least the end result will be readable rather than an empty box or something.

I can't imagine why anyone would do this either. I suppose one possibility is that some software in their web stack is converting fi to an explicit fi ligature and the monospaced font chosen by the web page doesn't support it so the browser does a substitution. When I spot another one I'll have to dig more deeply.

There's a free monospace serif-looking font called Go (made for Go, the programming language), designed by Bigelow & Holmes: https://blog.golang.org/go-fonts

I've been using Go/Go Mono as system fonts for a while, and they're one of my favorite typefaces. Their spiritual predecessors, Luxi Sans/Serif/Mono, are also worth checking out.

Go Mono is my favorite console font, alternating with Plex Mono...

I have been using that font as my main development font since it was released. Great looking font. Although I have to give an accolade to Iosevka which is easily my favourite "narrow" font.

I switched to this right after it came out - it's amazing.

Unfortunately it isn't using a usual font license. It's not really clear under what conditions you can use/redistribute it.

According to the GP's site:

> They are licensed under the same open source license as the rest of the Go project's software

Which I assume is this one: https://golang.org/LICENSE

It may not be usual, but what about the licensing terms is unclear?

It’s unclear whether I need to include a copyright for this font in every PDF I create that uses this font. SIL Open Font License explicitly doesn’t apply to documents using this font.

I'm not clear on the outcry against ligatures. This is a client-side setting and not committed to code, is that right? If so, this is like prescribing that we should use dark-mode over light-mode because I like it.

Now during the pandemic we might screenshare more often so I can disable it for that, but for development on my own time on my own screen it's nonyabizness.

People like Having Opinions About Things In Public.

For ligatures it's bikeshedding taken to absolutely ridiculous extremes. It's past prescribing night/dark mode, it's at the level of pre/proscribing colour themes in a text editor.

It is a personal choice and it doesn't affect anyone else bar me. If you don't like ligatures, I don't care, it has no bearing on whether I like ligatures (and it is a personal choice, what fonts are easier to read is always based on what I'm used to reading text in)


I disagree that it doesn’t affect anyone else. The only way it can truly not affect anyone else is if no one else knows that you use ligatures.

And dark/light is fundamentally different: it doesn’t actually change the content, just the colours. Similarly most font choices are purely presentational in effect, with the variation easily within what a normal viewer can be expected to read. (There are exceptions; for example, I’ve seen a couple of fonts go for a very old style of r in their fancy joined-writing style italics which Indians will have no trouble reading, but which has completely fallen out of use in most of the English-speaking world, certainly in Australia, and so may be difficult to read.)

But ligatures change the actual glyphs, so that your fingers must type something other than what your eyes see, and any viewer must decode the ligature’s meaning. And this is the key reason why the proliferation of ligatures in coding fonts becomes a problem for everyone.

If anyone else ever sees your screen (in person, in a screencast, or in teleconferencing with screen sharing), it has affected someone else.

At an objective level, I think it’s fairly clear that for most people in most circumstances, a light background is superior to dark, and ligatures are a bad idea. However, at a personal level, the subjective factors routinely outweigh the fairly slight objective factors.

Popularity breeds popularity. I have been exposed to ligatures in coding fonts on websites and other people’s screens. I never chose to use ligatures.

There’s an ancient philosophical question about personal freedoms in all this.

> The only way it can truly not affect anyone else is if no one else knows that you use ligatures

That covers 99.999999999% of the times ligatures are used then, that's my point.

Sure, in a situation like screensharing, using ligatures "affects someone else". A font also "affects someone else". A theme also "affects someone else". Night/dark mode also "affects someone else". That's a given. It's also something that is normally trivial to turn on or off.

And sure, very, very occasionally people use custom fonts with ligatures turned on in the CSS on websites.

> I think it’s fairly clear that for most people in most circumstances, a light background is superior to dark, and ligatures are a bad idea.

It's not clear at all. Regarding typefaces and character sets and reading comprehension, what a person is used to reading turns out to be the easiest thing for them to read (why do you use a monospaced font in your text editor?). I get that it's a fun thing to argue about because it is completely stylistic, context-sensitive and personal and has near-zero real world effects (I'm doing it now!)

> But ligatures change the actual glyphs, so that your fingers must type something other than what your eyes see, and any viewer must decode the ligature’s meaning.

As opposed to typing a collection of "actual glyphs" which the viewer must then decode back to their actual meaning via the conventions of the language? The characters available a given programming language are determined by [sensible] technical limitations, so creative use needs to be made of those to represent concepts that are already represented by single, well known characters that are not available in the PLs character set.

My beef is that talking about which fonts you like/dislike: that's a productive discussion as they're a personal thing, very often an aesthetic choice.

But banket saying "usage of this _type_ of font is bad": that's not productive in any way, it's pointless, as it ignores the huge % of people who clearly don't share this view. Saying "it's fairly clear ligatures are a bad idea": no, it's display preference, and if is forced on you, you will generally have agency to request it be changed back to something you are used to.

And this is every time coding fonts appear in HN: comment after comment stating the latter as if it's some empirical truth when it most definitely is not (and yes, similar thing for tabs Vs spaces etc, so obviously everyone paints the bikeshed, but this time it's completely tied to one person's personal computer display)

I was going to complain about them because there are a few fonts there I like a lot, but not the ligatures. Wasn't sure if it was = or == or === in the samples.

You can disable the ligatures for all those fonts and only see =, ==, === explicitly.

I agree with the author on adding ligatures where they are not needed, but one of the comments used in their justification is not quite right:

> Unicode [...] identifies each character uniquely. This way, software programs don’t have to worry that things like the fi ligature might be stashed in some special place in the font. Instead, Unicode designates a unique name and number for each character, known as a code point. If you have an fi ligature in your font, you identify it with its designated Unicode code point, which is 0xFB01.

This is true for the Roman script, but for many other scripts, Unicode does not provide dedicated code points for common ligatures. They would instead have to be denoted by two characters with a zero-width joiner in the middle (much like emojis).

Also, most Unicode experts would tell you not to use 0xFB01 in new stuff today and instead should rely on font ligatures for it. 0xFB01 was included in Unicode for cross-compatibility with older encoding schemes for systems that didn't support fonts with ligatures. Today we have support for fonts with ligatures.

This looks very nice, but I can't pay that much for a coding font like this simply because until you load it into the various pieces of software you use it is impossible to know how it will render. Especially on a non-hidpi screen.

Chances are it will look significantly different than the PDF once you load it into your terminal. Each of the three terminal emulators I have installed already render fonts very differently from each other.

The author offers a pretty good 30 day refund policy if the font doesn't work in your use case: "Triplicate has no demo version, but I do offer a 30-day return option: if the fonts aren’t your style, you can cancel your license for a refund."

As for the customer service experience, the author himself has responded (within the day even) to a couple of emails when I had questions about licensing.

They give a 30-day free trial, it seems (last item in the 5-reasons list):

"Triplicate has no demo version, but I do offer a 30-day return option: if the fonts aren’t your style, you can cancel your license for a refund."

Ah thanks, I didn't spot that. That's good enough!

> the only true serif monospace that I know of

Sun Gallant Demi is another one. Libertine/Libertinus Mono as well.

Oh cool! Thanks for broadening my horizons.

> My favourite monospaced font is Triplicate: the only true serif monospace that I know of

Also: https://github.com/yellow-type-foundry/xanhmono / https://fonts.google.com/specimen/Xanh+Mono

Cool! I hoped that line would get people to show me a few more, and it has.

The "l" looks like a big "1" in Triplicate. There is no way I will use a font like that for programming.

I agree with you and do consider the default l glyph to be a poor choice, insufficiently distinct from 1. Fortunately, the Code variant of the font goes for a curved tail on l, so that it’s sufficiently distinct.

(However, if you try to enable both the Code and Poly features—Poly meaning “don’t be a true monospace, make characters like l and i a little narrower and characters like m a little wider”—you end up with a slightly narrower flat-bottomed l glyph, rather than a curved tail. See this, for example, in https://chrismorgan.info/blog/make-and-git-diff-test-harness..., which is set in Code + Poly. Disable the `code { font-feature-settings: "ss01" 1, "ss02" }` CSS rule to see the effect of removing Poly—you get the curved tail l glyph back again. I’ve been meaning to sort out a better glyph for the combination, but I haven’t gotten round to it yet, because it’s annoyingly difficult to actually do that sort of thing.)

As mentioned in [1], Triplicate includes a Code variant which disambiguates l and 1, and O and 0, and makes other tweaks for better legibility.

[1] https://practicaltypography.com/triplicate.html

Triplicate has code-specific variants, including a curved lowercase L.

What's the decision process behind _choosing_ a font? I've always gone by look and feel but I've never felt fully satisfied with any of the (code) fonts I've chosen. I used Incosolata for a long time and in the last year I've moved to Hack. I really like Hack a lot but I am also trying harder to make more conscious decisions with my physical programming environment as I age (beyond aesthetics, caring about ergonomics, etc...).

I'm dyslexic. Because of that, I've spent a bit of time thinking about this for practical reasons. I prefer heavier sans-serif fonts with no character ligatures, but I like symbol ligatures and glyphs; they're not deal breakers. I've been using Cascadia Code, and find it usable, don't like the dotted 0 (the fact that the top and bottom of the 8 round in sharply helps offset this) or the few serifs it has. I've used Ubuntu Mono (spacing is too tight) and Source Code Pro (lines are too light) in the past.

What I look for is legibility between things like ({}), l1!|I, Oo08, mwnu, tl bpdq, ecoa, and being able to distinguish repetitio and symbols like --, ==, !!, "'`, :;, _-, and even ,.. (Something's going to try to parse that and absolutely shit itself)

I just grabbed B612 Mono.

n.b. I hadn't actually assembled those thoughts into one place before now. I apparently have Opinions about this!

Triplicate looks like Gallant, the font used by old Sun workstations. Looking like Gallant is a point in its favor (but ouch! That license fee is to its detriment.)

As far as serif monospace, NSimSun is still my favorite. It's in Windows. I love Triplicate but can't bring myself to purchase yet. I like Equity, too.

I think Triplicate is the closest to the old Selectric Prestige font, which I loved. But if anyone has NSimSun replacements (paid or free), please let me know.

A sibling post [1] mentioned Xanh Mono, which looks similar to NSimSun IMO. They both have that distinctive "Latin script alongside eastern script" serif look.

[1] https://news.ycombinator.com/item?id=25161756

Equity, a mono serif? Where do you find that one?

Equity is being mentioned as another of Matthetw Butterick’s fonts—a serif, not a monospaced font.

I like the true italics - they remind me a bit of the Light Italic typeface on the IBM Selectric (which has been discussed recently on HN I think.) IBM developed a number of beautiful and legible typefaces for its typewriters and I'd love to have them all as screen fonts.


Unless you're programming in something like Brainfuck, ligatures are simply not going to fail because the operators that have ligatures are pretty much universal. The situation of mixing up ligatures and their respective unicode chars is also nonsense, as those characters aren't typable and will only ever be used in strings, so there's no way you'd not know which it is and it's pretty easy to check anyways.

Programming ligatures provide a tangible benefit to many of us, so the author's insistence that they are a terrible idea is simply ridiculous (although, reading through some other articles on the site, not too surprising, as the site is 80% good common-sense advice and 20% poorly explained personal opinions being treated as gospel).

> those characters aren't typable and will only ever be used in strings

Raku wants to have a word with you. https://docs.raku.org/language/unicode_ascii https://docs.raku.org/language/unicode_entry

Yep, Triplicate and is far and away my favorite programming font as well, closely followed by Operator Mono. You need to pay for both, but it was easily worth it for me.

There's also CMU Typewriter text if you want another serif monospaced font. Looks wonderful in high dpi I believe. I've hacked mine to put slashed zero.

That’s a slab serif.

What about GNU Free Mono? I use it for APL development because it has nice APL symbols. The font itself uses serifs.

That’s a slab serif.

i can't find any pictures of triplicate with a dark background. could you share any? some hefty fonts (ie, go mono, courier) look so different when you change backgrounds that i am hesitant to buy without looking at a sample.


My own website has a dark theme if you have @media (prefers-color-scheme: dark), or if JavaScript is enabled, there’s a switcher in the top right hand corner. Note however that I use Triplicate T3 in the dark theme (300/700 for regular/bold), compared with Triplicate T4 in the light theme (400/700). You can fiddle with the @font-face declarations in dev tools (the font change happens in 2019b-dark.css) if you want to try swapping it out. https://chrismorgan.info/blog/rust-fizzbuzz/ has a bit of code, some other articles do as well.

ok; so i bought the font. it's beautiful! wow. thanks.

thank you! this helps. as i suspected it is the best font i've seen for programming with a light background, and just meh with a dark background. i prefer a dark background though, and the only font that i can tolerate with dark is pragmata pro. sigh being so aware of fonts is a curse.

thanks again.

Go Mono is another nice looking serif monospaced typeface I use.

More and more often, I see ligatures being used on such fonts. E.g. === or != are combined in a visually single character. Personally, I don't like that at all as I think it makes code less readable. It is probably something that you can get used to. But what exactly is the appeal of it anyway?

I suppose some might say the code looks cleaner with ligatures and they better convey the meaning of the code (e.g. ≠ is easier to understand than !=).

Personally, however, I like to see exactly what it is I am typing, exactly which symbols are being used. Ligatures distort that.

Ligatures are fine when reading prose, but I find them too confusing when coding. That's a personal preference, though. I'm sure some people have no problem with them.

I expect a significant proportion of programmers do not like coding using fonts with ligatures, so it's interesting that this website only provides the ability to filter fonts to display only those with ligatures. I would have liked the option to only display fonts WITHOUT ligatures.

Personally, however, I like to see exactly what it is I am typing, exactly which symbols are being used. Ligatures distort that.

I feel the same way.

I do think I would enjoy programming in a language that used a slightly more extended set of real characters, as long as we had solid editor and font support so typing and viewing them wasn’t going to be an issue for anyone. For example, I’d like to finally have ≠, ≤ and ≥ lining up neatly with =, < and > in my code! I could imagine a few other carefully chosen and easily recognisable symbols, such as ∈ and true arrows, being helpful for readability as well.

But the world speaks in Unicode these days, so assuming there was adequate tool and font support, I think writing these characters for real would be much better than relying on ligatures. Even where ligatures are supported, they tend to use awkwardly wide glyphs to replace multi-character combinations so they don’t break alignment in a monospace font, and sometimes the fonts with programming ligatures seem to join certain combinations in bizarre ways just because they can, even when there’s no apparent need for it.

I feel the same way.

Ligatures in coding fonts are a poor workaround for bad keyboard layouts. If you want to see ≠ then type ≠.

Julia is the only ‘major’ language I know that supports most such characters.

Ligatures in coding fonts is a good workaround for giving people options on what they see. I personally dislike ligatures, but I work with people who do like them. They want to see ≠, but typing ≠ instead of != in a shared code base is not going to happen, regardless of keyboard layout or language support.

This is also the same reason why tabs are better than spaces.

Raku / Perl 6 has been supporting unicode for operators, quotes, rational numbers, etc. for more than a decade.

Haskell has a language extension that does the same thing [1]. Now all you need is a keyboard with good unicode coverage [2].

[1] https://wiki.haskell.org/Unicode-symbols [2] https://4.bp.blogspot.com/_EKfCI8QuAaM/S7L-baZ-ZVI/AAAAAAAAD...

It's unfortunate that keyboard input is an afterthought for most systems.

OS X is probably the best overall, with easy installation (with one gotcha for development) and SIL Ukelele being a decent editor.

XKB is tolerable, overcomplicated in some ways and limited in others (really needing a layout to be paired with an .XCompose), but Linux Desktops™ make it painful to configure any layout that doesn't ship with their system.

I use a great little Windows program called WinCompose[1]. It turns Alt Gr on my keyboard into a “compose” key, so I can press that followed by a short sequence of other keys to quickly type numerous common symbols. As a result, I can type “ or † or ≤ almost as easily as I can type " or * or <. Similar functionality is available on other platforms, and I expect anyone who was typing the same symbols frequently, as programmers do, would internalise the shortcuts for them in a matter of minutes.

[1] http://wincompose.info/

Also built in to Windows these days is the Emoji (Soft) Keyboard which you can pull up with Win+. or Win+; (whichever you prefer). Since a few Windows feature updates back it even has a comprehensive math symbols section (under the Omega tab). It just needs a few more shortcuts under the math tab to make it really powerful. For instance, if you keep typing after you bring up the Emoji Keyboard it will search through Emoji and then replace your search word with your final selection, but it currently doesn't let you type search words or shortcuts for math symbols when you switch to the Omega tab.

Interestingly, the scala language previously supported either => or ⇒ and deprecated the Unicode character in favor of instructing developers to use ligatures for that aesthetic effect.

Pre-deprecation, there were formatters which would replace the two characters with the single unicode character if you wanted. If you use a language which supports unicode function names and operator overloading, you could easily add support for your unicode comparison operators.

That's not how ligatures work. You have to explicitly turn open type features on, they aren't automatic. They are additions to the character set.

Edit: Unless your reason for checking is that you explicitly want a marginally smaller file (possibly just at bytes level) to download (in which case just use one of the many online tools providing subsetting to strip unicode ranges and do something like remove everything except basic ascii?) there's no real point filtering for fonts without ligatures because, practically, that's just all of them

To each his own I guess... I find ligatures show intent, are easier to identify and help instantly identify typos (== vs ===). I also find the things that ligatures replace are usually ugly "programming specific" sequences of characters. For instance, arrow functions look much better with their respective ligature because the equals and greater than characters are guaranteed to be aligned perfectly.

I'm primarily working in Javascript, so it may make more sense to use ligatures in my dev environment. And, as others have said, ligatures need to be explicitly enabled in your editor.

> ≠ is easier to understand than !=

I respectfully disagree with this claim.

It's conventional code notation that != is a Boolean test for (in)equality; that convention doesn't apply to ≠, which is overloaded in mathematics.

It's C notation. Other languages use other notations like ~= or /= or <>. And any conceptual overloading of ≠ is a tiny fraction of the problem with = (it's too bad ASCII'67 dropped the ASCII'63 ← in favor of _).

The != notation has become pretty standard in most common programming languages. What exceptions are there in the top 20 development languages? VBA?

But, taking your point, a ligature ≠ would be overloaded in representing != and ~= and /= and <> and becomes potentially very risky.

SQL for one.

Also MATLAB: ~= Delphi: <>

And if you go a bit beyond top 20, there's Haskell: /=

I believe all of these fonts can be used without ligatures.

If I want to use ligatures, I have to explicitly enable it in my code editor.

It looks pretty, that was at least the reason I started using it. And now I’m so used to them that I can’t live without them, and I don’t get the “less readable” argument. Most of the fonts make the ligature the same width as the underlying characters, just making them look prettier. My font of choice, PragmataPro [0], has both variants with and without ligatures if you so desire.

[0]: https://fsd.it/shop/fonts/pragmatapro/

How much did you pay for it? I love typography but this looks quite pricey

I paid the full price for it (€199), and I've found it to be a worthwhile purchase. It's pay-once-use-forever and since I spend a lot of time staring at code, the price per day of use is very low. Of course, there are free fonts that do the same and look good, I used Iosevka and Fira Code before I found PragmataPro. Honestly, I just adore how the font looks, and that was the primary reason I bought it, the others being the amount of available characters and that the author is a paid professional working on it.

The thing that made the difference for me is the hinting, it's an absolute game changer on lower resolution screens.

An alternative that looks a lot like this one is Iosevka[0].

My favorite programming fonts are PragmataPro, Iosevka and Jetbrains Mono. In that order. I used to use PragmataPro for everything, but I use Iosevka for everything but my IDE these days.

[0]: https://typeof.net/Iosevka/

It's $19 if you just pick the regular weight desktop version.

Well I guess the idea is that the ligatures represent the concepts that the combination of symbols are trying to represent.

Also it looks pretty If you're staring a text editor for 8+ hours a day, it is important what you are staring at is pleasing to you.

I'll be honest, I've never grasped the perspective that sees typography as a meaningful aesthetic property of code. I mean, when I look at code, I'm not appreciating it as visual art, I'm reading it. Usually the point at which that stops happening is the point at which my brain is tired enough that it's time to go do something else for a little while and recover.

So, as long as the font I'm using doesn't actively impair legibility, which is a pretty low baseline, it doesn't really matter - and in any case, if it's a visual aesthetic I want, I'll go do it in Illustrator where I can actually have precise control over every aspect of that aesthetic, instead of forcing my programming environment to double as an installation art piece.

(DejaVu Sans Mono, in case anyone cares, or Menlo on Apple hardware since it doesn't want installing. Haven't changed it in what must be close to a couple decades by now; somebody sneakernetted me a copy of Vera Sans Mono in my earliest days of moving up from the helpdesk and I never looked back. Doesn't changing fonts impose a cognitive overhead of its own for a while?)

...all of which is to say I favor brutalism, I guess.

If you're working on code for most of the day, you will absolutely be making decisions that enhance your experience.

Could be an editor, monitor, chair, etc. It might not seem like some of those little things matter -- if I can sit in the chair, it works for me! -- but they do to some and typography is one of those things.

I don't understand folks who don't understand this. I get it if you don't personally care about typography but every developer is making QOL decisions.

I mean sure, I get that it's a QoL thing and that some people care more than others - I'm not arguing it shouldn't matter to anyone, so much as saying I have trouble grasping what specifically about it does make it matter to those who value it highly, I guess.

> But what exactly is the appeal of it anyway?

To answer this question you probably need to start broader with: why do ligatures exist in fonts at all? Then see if that applies to programming.

There's various accounts of the "reasons" ligatures came to be, but of the few I've seen all would (imo) apply equally to code as to language. The obvious one is pure aesthetic preference, but another is that ligatures came about as a way for business people of the time to differentiate letter/symbol-combinations for single repetitious use (as is done for operands: e.g. `===` has a single semantic meaning, it does not represent 3 programmatic operations in a row).

All in all though, I would guess this is about aesthetics mostly.

My own personal preference is to use ligatures in presenting code and avoid them in text editors/IDEs. I think this fits with traditional font use (writers would hand-write or typewrite manuscripts, ligatures would only be used by publishers/printers). It's possible presented code may "suffer" in readability for some unaccustomed to ligatures, so there's a trade-off to consider, but that's also true of books/articles using ligatures in natural language, and I think the problem is overstated in both cases. The nice thing is that copypasting the code doesn't force retention of the ligatures.

I can understand why it might aesthetically please some people, but can't understand how it actually helps with semantics, if one can't stand seeing "!=", it must drive them crazy to see other abstract symbols like "||", "return", "float".. imagine these are all replaced by single non-ascii obscure characters, it might be an interesting research on symbols, but i don't think it'll be a pleasant editing and reading experience for everyone

In typography there are ligatures that exist because they help readability (ex: ff fi tt) and others that are pure ornamental (ex: st). Personaly I see coding ligatures as ornamental as I can't read === faster if all the lines are merged because I need a precision in the meaning of this symbols that I wouldn't need if I was reading text where I can use, - – — (minus, en dash, em dash) and while it might look a little off no one would lost the intended meaning.

Most of today's coding ligatures merge === such that it has three lines vertically as opposed to just two (evoking a "hamburger menu" icon as others have noted), in addition it's also generally still three character widths versus two. I find it easier to visually spot the difference between the == and === ligatures in Fira Code or Cascadia Code than between the non-ligature forms and counting the spaces in between the lines. Your mileage may vary of course, but in most cases after several years with Fira Code I find the ligatures in general are much faster for "at a glance" precision than some of the non-ligature forms.

Why would copy-pasting force retention of ligatures? Ligatures don't change the underlying characters, only the graphical representation of them.

It doesn't. That's what I said.

Ah, so you did. My apologies, I misread.

I decided to try out ligatures a couple days ago. After about 5 minutes of getting oriented, I liked it better. The whole = == === thing ended up working out as a short = a long = and a three bar (giant hamburger?) were a lot easier to spot than the individual characters side-by-side. != turned into a double-width not equals symbol. So, 50% fun and 50% practical.

For instance != is just a way to write something that looks similar to ≠. With ligatures, you can actually see the symbol you're representing, and not an approximation. I suppose that is the appeal. And it looks neat.

> With ligatures, you can actually see the symbol you're representing, and not an approximation.

I think the flip side (which is why many people don't like them) is that with ligatures you can't see the actual code that you've written, only an approximation.

When I'm reading the code I need to understand what it does, the underlying characters are just a medium. I can see way quicker that a complex boolean expression is wrong when I see ≠ instead of != and ⪖ instead of >=.

I do agree with the Butterick that when presenting code to others, for example as examples, the ligatures are a big no, because in this case you actually need to see what characters you need to input.

In that case it works reasonably well, but how do you represent the difference between `=`, `==` and `===` in javascript. IMO =, == and === is much clearer and more visually distinct than ≔, = and ≡.

Mainly a force of habit. But I agree that for equalities a split sign would be clearer for most people.

I won't be going around and trying to convince people to use or not use ligatures though. I feel that it is a very personal preference much like the choice of syntax colouring theme.

I never use == in any circumstance anyway, but telling the difference between the == and === ligatures are really not hard. The === one, at least with JetBrains Mono, is much larger.

Trouble is, that argument falls apart because != is only akin to ≠ if == is actually =. If you use a language with := for assignment and = for comparison (or something similar), sure, making != appear as ≠ might make sense. But if you’re using almost any C-family language, you’ve already broken the mathematical model of what the equals sign means. After that, I side with nicoburns and say that now you’re obscuring what it actually means (in favour of something that’s more or less incorrect in mathematical notation).

So, use the right ligatures for what you're doing.

Iosevka has several presets, or can be completely configured: https://github.com/be5invis/Iosevka#ligations

I consider editor not showing or changing what you exactly type as rude (I can accept autocompletion because it at least prompts).

It also introduce a ton of (unnecessary) complexity on top of the text formatting system, which in most cases are already a mess.

I usually really enjoy customizing my shell and making it look pretty, but my first experience with ligatures was a bad one. I was learning LaTeX and my editor turned on ligatures for me (I think the vim-polyglot plugin was the culprit) and it was very frustrating. Ligatures in an unfamiliar environment make it harder to follow guides and learn from the code that you're reading. Maybe it would be a lot easier if I was using it in my native language, but it just struck me as an abstraction and one more thing to learn and keep track of.

I’m with you. It’s source code, and as such I prefer seeing... well, only the source. I don’t get why it’s so polarizing, it seems obvious to me haha

At first I hated them and thought they were pointless and weird, but now I'm so used to them that it feels a little off if I don't see them.

It helps to visually parse things a tiny bit more quickly, I think. And it makes things more aesthetically pleasing, for me. Combined symbols like == and <= really are unique, independent things that make logical sense as their own separate units.

I sort of get the point, but a lot of these fonts squash together == to look like a long =, making it really hard to distinguish == from === Can you tell from 'Iosevka Slab' that it is a triple equal sign?

I've tried most of these at some point over the past few years and eventually settled on JetBrains Mono. I love it. The story about how it was created is pretty interesting... https://www.jetbrains.com/lp/mono/ And yes, there's a powerline version.

(Not affiliated with JetBrains in any way)

I've never seen a font's design explained so well.

There's so many subliminal things that I had never thought about/considered.

But be careful: not everyone will agree with what they say in such claims. I myself disagree at least moderately with more than half of what they say:

Increased letter height for better reading experience: this makes the proportions of the letters a little awkward, and makes ascenders, descenders and capitals less distinct. There’s a reason why the height of x should be quite a bit less than the height of d or M. They say “see how much nicer than Consolas this is!” yet I strongly prefer Consolas there.

Code-specific eye movement: again, increasing homogeneity regularly actually decreases reading performance. You do want patterns to be clear, yes, but trying to make everything closer to rectangular may well be taking things too far.

Functional сonstruction: who told you tails on letters like u were “unnecessary details”? The r and g ones are more subjective (Fira Code’s r especially is perhaps unnecessarily complex), but them tails be there for a reason, as they help with orientation of the letters and pattern recognition. Note that the g retained the taily thing at the top right corner.

Distinctiveness of symbols: I certainly have no complaints here—unless it be that the top left taily thing is inconsistent with the rest of the font, as with the letter i; but doing i and l in this way is quite common in monospaces.

Cut strokes: there’s truth to the pixel grid alignment technique, so long as the size is right or hinting is employed (… which it probably isn’t, nowadays). Tech personality, yeah, that’s probably true.

Italic: seems legit.

Ligatures for code: “To reduce noise”? This is an extremely contentious claim that I happen to believe is drivel (largely because your fingers still have to think in terms of the actual characters when you were typing, so even if you’ve reduced one cognitive load—debatable—you’ve certainly introduced another). “To balance whitespace”: fairly subjective, I think; in a proportional font, you do this sort of thing via kerning, where it works easily and naturally; but I don’t much like using ligatures to achieve the effect in a monospace.

This comment - https://news.ycombinator.com/item?id=22054487 - made similar points when the font was released, and I'm in complete agreement. Those decisions feel much more like aesthetic decisions rather than functional / accessible ones.

While not as in depth... the Source Code Pro announcement page touched on some of those - http://blog.typekit.com/2012/09/24/source-code-pro/

Any font that doesn't consider these things is generally not one worth using, to be honest. They are quite literally the bar for consideration.

They have non-ligature versions as well which is nice of them to do. It's a good looking font.

I switched to coding in a proportional font, Verdana, a couple of years ago and never looked back.

That's the font you are reading this comment in, in fact.

Code is mostly words and words are much easier to read in a proportional font. Symbols are plenty clear enough in Verdana, all letters are distinguishable, and I don't use mid-line alignment so I don't see the point in a monospace font outside of the terminal.

I’m changing my editor font to Verdana now... let’s see how that works out.

Edit: it feels so wrong! Let’s see if I can get used to it.

Screenshot: https://i.imgur.com/lmOR9ze.png

I tried it about ten years ago. Turned out, old habits die hard. I had it for about a week, but went back to a monospaced font.

What language are you using such that inter-line relative column spacing doesn't affect your code comprehension?

> I don't see the point in a monospace font outside of the terminal

Why not use Verdana in the terminal?

I'm confused. In every modern language I've used apart from go and terraform, only leading indentation matters and autoformatters do not apply mid-line alignment or align subsequent lines against characters in a previous line.

edit: and maybe Haskell? the layout rules are complicated

personally I don't think lining up e.g. variable or parameter names in c style declarations improves readability at all, and it pollutes git diffs.

but I do use a monospace font in the terminal because many command line applications align their output into columns using spaces.

Good point, it is usually the leading indentation that matters most. I guess since I use Clojure mostly, I like to be able to line up pairs in a map, or a let binding. This could potentially be achieved with tabs, but I'm a spaces guy so I think variable-spaced fonts would be problematic.

> but I do use a monospace font in the terminal because many command line applications align their output into columns using spaces

Ah, makes sense.

Wouldn’t work well for ls -l.

Yes! I've been using Verdana for a decade. I still can't find a better screen font for coding.

Edit: https://i.imgur.com/JnMopk4.png

The trick to enjoying this is opting in/out on a per language or project basis.

Iosevka has a proportional variant with all the fancy ligatures that’s just delightful.

Most Smalltalk IDE's use a variable width font by default.

> That's the font you are reading this comment in, in fact.

Wrong. One of my favorite features of Firefox is that I get to choose whether websites can override my fonts. And they can't. Serifed Georgia is default, Ariel if they request sans-serif, and Consolas for monospace.

Curious. Does this prevent the browser from downloading webfonts thing ?

Yes. I just reloaded the Dev Fonts page with and without locked fonts and it only downloads them when the fonts are unlocked.

I forgot to mention that one may also set a minimum font size. That one does occasionally break a layout here or there, but it's worth it for easier reading.

These ligatures always felt like a gimmick to me, although I'm not too picky about programming fonts. Just give me non-ambiguous iIlO0 and I'm happy.

I've used a ligature font now for a while and I've really grown to like it. It's not a big difference but I especially like how >= and <= turn to the mathematical equivalent which is more readable and different from arrow functions.

It seems the Input fonts are missing (https://input.fontbureau.com) — I found this extensive font family several years ago and (in spite of regularly checking) haven't found anything better yet.


I use Input for about two years and really like it. IMHO you need a high dpi/Retina display, though. I also like Output, a new font by Input‘s author, but haven‘t tried it yet. Might be a great fonts for usable interfaces

Agreed. Actually ctrl+F'd to see if anyone else was talking about this great family.

I used to be all about Consolas, Ubuntu Mono and Monaco pretty much interchangeably... until I tried Input and never looked back

In the category of dev fonts, I'll throw out JuliaMono: https://cormullion.github.io/pages/2020-07-26-JuliaMono/ (I am not the author)

Besides various stylistic choices (most-but-not-all positive, in my opinion), JuliaMono differs from other dev fonts by having _way_ more unicode coverage. (And from other high unicode coverage fonts by being monospaced.)

Iosevka is highly active and highly customizable set that I've been sticking with after a dozen terminal fonts switching. Every time I try a new font now, I go back to Iosevka. The narrow width makes it stand out significantly from the others and it's much easier to use when having multiple columns open on the screen. I highly recommend it.

You got me when mentioning multiple columns. My setup is that I have half of my external monitor with VSCode (the other half is the browser) and most of the times three columns in there - folder structure and two files on a split screen.

I compared Iosevka with the 3 others just as narrow fonts (Inconsolata, Nanum Gothic Coding, and Ubuntu Mono). Iosevka won for me because it is taller or bolder than the others (felt more easily readable in small fonts for me), but also because it is more unique in its shape compared to regular reading fonts — the “o” is more squared for example.

Thanks for your comment! I will change to it just now!

It is also my favourite. It's just narrow enough for using with multiple columns, but not too narrow that it affects legibility for me, and it's event customizable, for my nitpicky preferences.

Yeah - also should be easier on the eyes when you read a bunch of text - less horizontal movement.

Another great aggregator that has been around for a long time and has 100+ programming fonts: https://www.programmingfonts.org/

I wonder if both these sites use some of the same code - in both ProgrammingFonts and DevFonts the language switcher is broken for me (Firefox, mac).

I've been programming for over three decades, on many different systems with many different fonts. This topic pops up every so often but I cannot help but think that to me, it's the ultimate bikeshedding...

It couldn't be more subjective than that. This, and color schemes. Having any kind of argument over the subject is an utter waste of time indeed, as it ultimately boils down to preference.

I agree, each time I find myself trying new themes or fonts, I realize I've been stuck on a very hard problem for a few days. And my brain is just trying to get something, anything, done. So I start focusing on small unimportant details to feel like something is progressing.

I use a classic VGA Bios font and never looked back.


This. I switched to it for a bit of nostalgia and never switched back.

Isn't it kind of silly that you don't have the option to chose font size. I tried a few fonts that looked good on the site but I don't code at 30px font and when I plug them to my IDE they look terrible.

You could just zoom out, though a web browser's font rendering can differ from your programming environments anyways.

The struggle for me is that browsers have their own font rendering code, so a font that looks great in Chrome, can look absolutely rubbish in Windows when used in say, Visual Studio (not VS Code). Inconsolata is a good example of this - on web pages it looks nice, but in Windows (non HiDPI) it's really badly rendered at any size under 16pt.

There's a certain style of programming font, I think due to narrow strokes and sharp curves that I at least find universally ugly and often hard to read. From this list Monoid, Iosveka, Anonymous Pro, and Share Tech Mono at least fall into that category. I think it's meant to be sort of a callback to bitmap fonts? I know the Linux console font (terminus) looks similar, but that's clearly due to technical limitations. Is there something wrong with my font rendering, or are there people actually liking this style? If you do like this style, what OS do you use? I'm wondering if there's a common trend where such fonts render better on macOS or something.

I've been using Anonymous Pro as my primary code font for at least 5 years now.

I came to Anonymous Pro through the path of previously using tewi [0]. I was big on the whole linux customization / "ricing" scene in my early years of university, and because of how my desk was set up, i was close enough to my computer to be able to read it. I ran Arch, with tewi, at a 9 point font size. I just liked how it looked.

Eventually my desk setup changed and having such a small font was no longer viable. I went with Anonymous Pro because I found it to be similar, but also easier to read at larger sizes. For a while I coded primarily in vim, so maybe there was something about just setting it once in the terminal config and having what I needed. I also picked it because patched versions existed with powerline symbols, which I was into at the time.

I now primarily use VS Code on Windows, but I still use Anonymous Pro. I think the narrow strokes and the sharp cruves that you dislike are actually easier for me to read. They give characters a kind of crisp shape, and I find that helpful in distinguishing which characters are which. When I look at the colleciton of fonts, ones like Cascadia, Ubuntu Mono, and especially Nova Mono all look awful to me, because of how rounded they are. I'm also in the crowd of people who dislike ligatures in programming fonts

If I were to pick any of the fonts from this list to try, I would probably pick Hack or Noto Mono for something a bit more robust, or Source Code Pro for something similar to the slenderness of Anonymous Pro. But I think the more important thing is knowing what you like and picking one and settling on it. It surprised me when I went back to my dotfiles and I was looking at screenshots, just how long I've been using the same font. But it makes things easy.

[0] https://github.com/lucy/tewi-font

I love all those fonts! Right now I'm using Iosevka Term at Medium weight since I can cram a reasonable amount of code in horizontal space and the style looks very appealing to me.

This is with monitors at around ~130DPI. For regular old 96 DPI monitors I used tewi, a very small bitmap font.

I'm running Linux so most things are rendering on FreeType, here's a screenshot of Iosevka Term with some random youtube-dl code: https://i.imgur.com/qQHmOX2.png

I still haven't found a font I like better than Terminus. I've tried scores and keep coming back to it. I find most fonts to take up way to much horizontal space compared to Terminus. I might try a couple of those just to see, but I'll probably just end up back on Terminus.

Posting the Matthew Butterick's definite ''ligatures are bad'' take, in case anyone is interested.

Q: Ligatures in programming fonts? A: Hell no https://tinyletter.com/mbutterick/letters/q-ligatures-in-pro...

> And not because I’m a purist or a grump. (Some days, but not today.) Programming code has special semantic considerations. Ligatures in programming fonts are likely to either misrepresent the meaning of the code, or cause miscues among readers. So in the end, even if they’re cute, the risk of error isn’t worth it.

> Bottom line: this isn’t a matter of taste

Bottom line: this is a matter of taste, like syntax highlighting, use of bold/italic/font face, because everyone configures its own editor to their own taste.

Ligatures are nice but when you want to show the code to someone, or when you're reading a snippet for reference, you need to know exactly what keys to press to make that symbol. Assuming everyone knows the underlying glyphs for a combined ligature is not productive. I wouldn't want reference websites and documentation to use these fonts for example.

Oddly this site doesn't show the italic variants of fonts, unlike https://www.programmingfonts.org which was on the front page some time ago iirc.

Luculent, my favorite:


Beautiful, thanks! Good language support, includes some variants with the hints included in the glyphs. Nice!

Since I've switched to Roboto Mono I've never looked back. It's quite simply the easiest to read that doesn't have any 'weird' characters to look at.

It has the perfect thickness and clarity imho.

I keep wanting to change but nothing beats Monaco for me. Perfect font.

Same here. I could spend hours upon hours minimaxing this, but why? Monaco is as close to perfect as makes no difference (with https://github.com/Karmenzind/monaco-nerd-fonts so a nice prompt works).

Nice website but the problem is that it shows the fonts at 18px size when most people use their editors at 11 or 10px sizes. Many fonts look radically different at such small sizes.

I wonder if a survey would hold that to be true - I use my editor at 16 on Linux/18 on Mac. My browser zoom is also on to differing levels for different sites - I have HN at 160%.

I think it also depends quite a bit on screen DPI so comparisons/generalizations are a bit difficult

I can‘t get away from Lucida Console because all those more recent fonts seem to be only designed for HiDPI use.

I was literally just looking for this two days ago when I had to reinstall my main system and of course ended up searching here. [0]

One thing I noticed: I really want a different font for my terminal than for my editor – for the terminal I went for DejaVu Sans Mono, it's clean but still has some character, especially the dotted 0.

[0]: https://news.ycombinator.com/item?id=7360996

Am I the only one who uses a proportional font for coding? I find it more readable for the same reason it's more readable in books and other printed media.

> Am I the only one who uses a proportional font for coding?

No, I do it too.

> I find it more readable for the same reason it's more readable in books and other printed media.

OTOH, its really annoying when you edit code from someone who decided to try to "beautify" code by using alignment beyond indentation.

Which one do you use? I love proportional font but find most of them not suitable for code. Input Serif is the only proportional programming font I can find but it looks too old school.

Georgia, modified to put a slash through the zero, and a small horizontal line, like a serif, on the l. Theory being, letters in serif fonts are easier to distinguish since visually they're more different from each other. Same reason the body text of books uses something like Times New Roman, only headings use a sans serif font.

I've been using Verdana for ~10 years. I've tried others but keep coming back to it. It continues to be a very consistent and elegant design for screen.

Try the sans variant, it looks almost indistinguishable from monospace font but more comfortable to read.

Whenever I come across a list like this I hope to find some useful new proportional coding typeface. Nope, not this time either, 100% monospaced. I guess I’ll stick with Input Sans.

I did use proportional fonts with REBOL, Ruby, CoffeeScript and JavaScript. Tried it with tab-indented Clojure code too.

However, 1-2 space indented code becomes just too ambiguous when rendered with proportional fonts, because the spaces are way too thin. I wish editors would render em or en-sized spaces instead, at least for the line-leading spaces. That way we would get the same indentation as intended with monospaced fonts, but still save horizontal space, while maintaining readability...

I would like to, but I hate tabs (due to the jumps it causes in horizontal cursor navigation, and also due to the nonlinear behavior when inserting/deleting characters preceding a tab in a line), so I would need an editor that widens spaces at the start of line to get sufficient visual indentation at four spaces.

Interesting. I find that the usual four spaces give me the ideal indent length in proportional fonts.

in Verdana 4 space indentation is about 3 ordinary characters wide. I find that perfect. code indented with 2 spaces is more problematic though.

My favorite recent font discovery is Simplex Roman. Designed in 1967 for early CRT vector displays by Dr. A. V. Hershey (for the US Naval Weapons Laboratory!), and released into the public domain.

Incredibly pleasant looking even today: http://paulbourke.net/dataformats/hershey/

OpenType conversions: https://github.com/scruss/AVHershey-OTF/tree/master/otf

Reminds me of vector arcade games like Asteroids and Tempest... By the way, another cool public domain font is the one used on all US interstates — 1948! https://en.wikipedia.org/wiki/Highway_Gothic

This feeling of roundedness reminds me of APL385 / APL386.


I’ve always liked the look, but I use Fira Code in practice because it is more readable and narrower.

'l' and 'I' is rendered the same way in Simplex. I mean, exactly the same. Also little difference between '0' and 'O'.

the i has got a little cute circle, like the j! https://twitter.com/Doomlaser/status/1308021841324367872

I've been a happy Inconsolata user for years. It looks great, characters are unique, and it stays out of the way.


I find ttf fonts generally smudge the letters together and can make things hard to see. proggy[1] is quite good if misc-fixed[2] is not available.

  [1] https://proggyfonts.net/download/

  [2] https://en.wikipedia.org/wiki/Fixed_%28typeface%29

I don't see ligatures solving any important problem. If you think they do, I'd rather change syntax highlighting to recognize !== and others as a single token.

It's like multi-select in text editors. When you think about it, it's actually an inferior form of search&replace. Inferior because it interacts badly with off-screen matches. I find arguments of kakoune users unconvincing.

My personal opinion is - and I'm fine taking negative karma for this - that ligatures mostly appeal to the front-end developers among us. To the people who abuse the words "beautiful" and "gorgeous", and admire web pages which have a single text column using up 1/3 of screen width.

> If you think they do, I'd rather change syntax highlighting to recognize !== and others as a single token.

Your syntax highlighter probably already recognizes single tokens as single tokens.

> It's like multi-select in text editors. When you think about it, it's actually an inferior form of search&replace.

I’m thinking about it, and it isn’t. Sometimes search and replace is an inferior form of multiselect. Multiselect is a less flexible form of macros, but provides immediate feedback.

> My personal opinion is - and I'm fine taking negative karma for this - that ligatures mostly appeal to the front-end developers among us. To the people who abuse the words "beautiful" and "gorgeous", and admire web pages which have a single text column using up 1/3 of screen width.

This is an unpleasant statement and apparently even you recognize that.

Some HN users love to look down on front-end development as if it's some sub-par category of developers, for some reason.

Let's do the same kind of pretentious generalization - I'd wager they are the same who think any language of higher level of abstraction than than C++ is an utter waste of time.

Edit: did I hit a nerve? I don't even believe that second statement, but it's a good example of how pretentious that comment sounded.

Sure, some do. I can't speak for them. What annoys me personally is that sometimes they seem to praise very arbitrary stylistic choices as objectively superior. I think front-end developers are more prone to fashions than other kinds of developers. The blogs seem to go through phases.

That's making a lot of assumptions. They simply might be more prone to write, read and react blog posts as a general rule. Their work is also more visible than most developers' work, being customer facing.

Gotta also keep in mind the FE landscape has radically shifted in the last 5-6 years after being almost dormant for a long while - more or less coinciding with ES2015 and the emergence of reactive frameworks ala React/Angular/Vue.

I have to agree with my sibling commenter -- you are taking a pretty strange and rather aggressive stance on this, and throwing out some ad-hominems within that.

Multi-select: Useful if I want to do a find-replace, but only within certain select results for the "find" part. If I know where they are I can use Cmd+D or multi-select to just find those quick rather than crafting a nice regex find-replace query with "only in selection" etc.

Ligatures: It's SUBJECTIVE. I dunno why you're throwing out ad hominems like "only for frontend developers who like <things I think are bad>". I am looking at code for 8-12 hours a day. If ligatures make the code nice to look at, why the heck do you care what my code looks like? My ligatures aren't being pushed into your environment.

This is like judging someone as "lesser" than you because they like a different mouse because it's comfortable for them...

> I don't see ligatures solving any important problem.

I see ligatures as solving, imperfectly, the problem of "my language has clumsy operators because it wasn't designed with support for unicode operators" lining up with the preference of "I prefer less-clumsy operators".

If you don't have the first problem then, even if your language also supports ASCII multicharacter operators, its just an autoformatter issue.

Aside from the ambiguity with similarly-appearing genuine single characters, programming ligatures tend to not really solve the problem they set out to in monospaced fonts, where you end up with a single symbol which invariably preserves the width of the ASCII multicharacter symbol, which either introduces extra empty space or extra visual weight or, often, both.

> My personal opinion is - and I'm fine taking negative karma for this - that ligatures mostly appeal to the front-end developers among us.

I've seen more praise for them from corners of the Haskell/Idris community than from the much larger front-end community. I don't think there is any real correlation between working in front-end and preferring fonts with ligatures.

This is a curious position to take given that it's mostly a personal choice. People will like what they like, and that's perfectly fine! No need to denigrate frontend devs, or anyone, for a stylistic choice.

I'm fine with people having aesthetic choices. I find front-end developers and their fashions mildly annoying.

I think this post would fit very well at /r/unixporn, similar to ASCII art, pixellated graphics or low poly models.

This is quite literally nothing but a website letting you preview how fonts look. What's "r/unixporn" about that? What a bunch of condescending baloney.

Ligatures were created to prevent crashes of overlapping bits of characters. But this is an issue that shouldn't really occur in a monospace font.

I kind of agree with your statement about multi-select, but even so, I love to use it!

(I "kind of" agree because a sibling comment is right that multi-select is a restricted form of macros, not search and replace. Because the things you can do with the multiple cursors are more than just search and replace.)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact