Go fonts | Hacker News Reader

Go fonts

blog.golang.org

295 pointsstablemap170 comments

This reminds me of Java applications that you can immediately tell are Java because of the weird font.

I don't see an advantage over using native system fonts. As far as I know you don't need a license to use fonts installed on the system running the application. Why does the font need to be bundled? The wide spread adoption of this is going to make go programs stick out like a sore thumb.

Jetbrains are the only example I've come across that provide an option for native UI elements in Java apps.

To expand on your point.

What about the combination of fonts and UI elements I've chosen for my desktop environment. Will this new UI toolkit ignore those choices I've made and stick to using their own font?

It's bad enough already, for example on linux, where there are already two incompatible UI toolkits being used for the majority of applications, GTK and Qt. It's already difficult enough getting a consistent UI for applications that use both.

Eclipse is — or was, I haven't used it since 2006 — also great. Instead of using the horribleness that is Swing, they wrote their own toolkit, SWT, which uses native UI controls, and it's the only Java app I've ever used that had a native look and feel. (They did a lot of custom rendering, of course, but it was still able to feel native.)

What options for native UI does IDEA provide? It's mostly a Swing app.

> I don't see an advantage over using native system fonts

As touched on in the article, you need a standardized font you have control over for automated testing, to make sure you're getting reproducible results. OS fonts are too inconsistent for that.

Now, why they couldn't use any of the literally hundreds of other open-source fonts instead that Google made…

I suspect partially to avoid the Google branding (which seems like a good reason), and partially because of Rob Pike's Bell Labs and Plan 9 history (which would be more nostalgia than anything else, but not necessarily a bad reason).

That was one of my first thoughts.... imho Noto looks better, and the monospace font is pretty hideous imho. I like Inconsolata/Consolas, but there are many other options that are libre licensed and better looking imho.

As to other comments, mostly agreed on using system fonts.

> As touched on in the article, you need a standardized font you have control over for automated testing

Why? Just standardize the font when running in test mode. I expect system applications to use my system fonts.

Yeah, that's the part where it stops making sense. System fonts are good enough for human consumption.

I hope they aren't planning on going down the path of golden-image testing, if so they're in for a world of pain.

I don't respect the self-imposed "x-platform native UI experience" constraint anymore. Even windows slowly rebuilt its user interface and experience over the years.

It isn't a user demand, it doesn't put any pressure on support, frankly I have no idea what these people who spread all this custom drawn vs native control polemic were thinking.

Also, if you are making money, who cares if you drew some of your controls on a canvas instead of trying to goad some restricted native elements into acting and drawing like you want them to?

> who cares if you drew some of your controls on a canvas instead of trying to goad some restricted native elements into acting and drawing like you want them to

Because now your app will break in HiDPI, for screen readers, automation tools, the next version of Unicode. Expected behavior like tabbing, keyboard shortcuts, system spell-checking breaks.

Why, then, doesn't firemonkey have any scaling or layout problems? Not all applications need any of the system level services that are coupled tightly with the system widgets.

> Why, then, doesn't firemonkey have any scaling or layout problems? Not all applications need any of the system level services that are coupled tightly with the system widgets.

I can't speak for Firemonkey specifically, but a lot of cross-platform toolkits of its ilk have horrible problems when rendered on 4K displays.

Were you ever forced to use something like SAP? The UI gives its users cancer because "for historic reasons" they do everything themselves instead of using normal widgets and shortcuts.

I've used SAP, Oracle Forms, Navision and a custom made framework written over 20 years in my current company. They all impose constraints on their users with their weird interfaces. However, users just need to get used to it and I haven't met a single person other than the developers themselves who overthink this subject in such an obsessive manner.

In the early days of windowed operating systems, absolute consistency in the look and feel helped people navigate unfamiliar apps. The proliferation of widgets on the web, and the use of different devices with different standards, has destroyed that rationale. The only thing consistency is good for anymore is establishing branding.

Because then you will have an interface that has been goaded into acting and drawing like you want it to, instead of having an interface which looks and acts in ways which feel normal and familiar to users of the target platform.

Maybe you want that, as an app developer, but as a user I'd really like it if you'd stop, and I'm happy when the platform makes this sort of thing difficult.

What really changed my mind was the MLOC delphi application I maintain as part of my dayjob. People don't think "oh wow I wish this was a ctrl-v instead of shift-ins and what am I ever gonna do if this file dialog looks kinda weird and unfamiliar? and oh no, the context menu in this grid is actually a window with a handle and not the default menu that was originally intended by the win32 api gods? Give me cancer or give me death"

No, they just busily work X hours and go home. They only care about getting their job done and if that means getting used to the interface they do so. We actually have users who've been around for about 20 years and you should see how fast they can enter some of the stuff.

Well, sure, employers are free to waste their employees' time and make their lives complicated in all sorts of ways; that's what the paycheck is for. So what? It's still a crappy way to design apps, and I'm not going to respect it just because people successfully get away with it.

You must notice they are building a new UI toolkit with opengl es backend. They apparently don't care about native system.

The page itself is set in the proportional version of Go. I found it distracting to read because of the uneven character widths. The majority of the characters (like 'b', 'd', 'f', 'k', 'l', 'o', and 't') are narrow, but some common letters (mainly the 'e' and 'c') are round and wide, with generous space around them. I can't get past the impression that I'm reading paper that wrinkled when it went through the printer. Even the name "Go" has a wide G, awkwardly large space, and narrow "o". Perhaps it's an artifact of the browser rendering, because it's less noticeable on the alphabet sample image.

The monospaced example reminds me of TeX-produced CS papers at first glance. I'll have to give it some time.

There are some bad kerns too. Look at "Yet" and notice the 'e' is not tucked under the 'Y' at all.

The alphabet sample image has problems too. The space after uppercase G is plentiful compared to the space after uppercase V. Granted VX is not a common letter combination but still this shows some bad kerning nonetheless.

Also I find the hyphen surprisingly wide (in the proportional version). In fact so wide that I keep thinking it's an en–dash and it reduces my reading speed: my brain has to slow down and mentally correct it to hyphen.

> Also I find the hyphen surprisingly wide (in the proportional version). In fact so wide that I keep thinking it's an en–dash ...

So did I! At first I thought that they had inserted en-dashes by some mistake.

The monospaced font looks very old, I don't like the look of it.

The proportional one is ok but it can't be used for programming. In part because of the reasons you gave but especially because there is almost no gap between the two = characters in == and @ is almost superscripted, which looks wierd.

I'm going back to Sans Regular (whatever it is on Ubuntu). It has its own problems (I and l look the same) but it's still better.

Yes! You put your finger on it -- it looks old!

That's not necessarily a bad thing. Instead of "old" you could call it "retro". But it definitely reminds me of the formatting of K&R, which makes sense as the Go team see themselves as the heirs of the K&R tradition.

When I saw the monospaced font, I immediately thought "Courier". The differences are subtle, must less pronounced than the similarities. I wonder why they didn't just make a monospaced version of the Sans?

"The experimental user interface toolkit being built at golang.org/x/exp/shiny includes several text elements, but there is a problem with testing them: What font should be used?"

I am really amused by this opening. I guess it is part of the culture to "recreate" something unnecessary and perhaps better when there is resource to spare.

Font licensing is complicated and Chuck is a friend. It was very important to us that Go programmers be unencumbered when distributing programs that use this font.

Why is it not possible to just use the system font for these UI elements?

because they are reinventing the wheel for a UI toolkit it seems?

While possibility is another question entirely, from a design standpoint I can definitely see why an app might want to bundle the font together with the rest of the package. It guarantees a homogeneous user experience.

Sure, but generally native applications should use the system font settings to keep things consistent.

Being self consistent is not important, being constant with the environment is important.

That ship sailed long ago. I fired up the mail client in windows 10 for the first time in a while yesterday and it had this weird galaxy background. It looked like an access app an amateur would throw together.

System native doesn't neccesaraly mean high quality or standards compliment. Take windows control panel as an app which still has zero effort put into standardisation, I get that it's pretty much a dead man walking but they could at least try polish it up.

homogenous for who?

for the end-user? nope, because this application doesn't look like the rest of their applications, and ignores their preferences.

for the developer? yes, because their application will look the same regardless of platform it's deployed on.

But as we've learned with Responsive Design, having a single "my way" of presenting an interface regardless of end-user preferences and device capabilities is a Bad Thing. Interfaces need to be configurable by the user not fixed by the designer.

I like the font, though. Makes my code look sexy, and that's hard to do ;)

> there is a problem with testing them

Maybe they're comparing the rendering of the UI toolkit against reference bitmaps, so always need to use the same font, so want to distribute the font in the repository?

That's what Ahem is for: https://www.w3.org/Style/CSS/Test/Fonts/Ahem/

The blog post explicitly stated testing as the reason why Go needed a font that could be freely redistributable.

I help maintain/develop an app that allows users to draw and simulate logic circuits on a canvas. Text plays a minor but important role for labeling various components, showing bit and hex values, etc. The app uses system fonts, and it's a huge mistake. The sizes and exact layout and connectivity of various logic blocks depends on text size, and when that changes (and it does from platform to platform), it leads to lots of subtle and hard to notice errors. I've spent a lot of time tracking down every logic dependence on character width and making those all platform-independent heuristics instead of using the actual font metrics. Which makes the UI often look terrible (but at least it is a consistent and functionally correct terrible). I would much rather the app bundle a freely redistributable font and be done with it.

I don't know what toolkit you are using, but when I want to place text with e.g. SDL_ttf, I can compute the width and height of a string knowing its font. IMO relying on a specific font is exactly like throwing magic numbers in a codebase. I can understand that it simplifies things, but it doesn't feel right.

The sizes and exact layout and connectivity of various logic blocks depends on text size

I have used many schematic editors and they all handle different font sizes correctly, even letting you choose different fonts and styles within the same document. It is not difficult to figure out how much space a piece of text takes up, and scale the other elements to fit.

If the actual connectivity of the parts in your schematic changes with font size, then I will quite frankly say "you're doing it wrong".

It seems to me that having a specific UI toolkit font would not help you in your case.

If Go maintainers decide to change the font metrics you will have the same problem. Distributing your own font (as you have mentioned) is the right way to go.

If the Go maintainers change metrics, you can still distribute the old version, or even modify the new version back to the metrics you want and distribute the result. That's the advantage to friendly licensing.

Meanwhile, the rest of the world just doesn't hardcode the font face, and we seem to survive without "encumbrance" problems.

This isn't hard coded, it's a free default.

What's wrong with Noto or Open-Sans? Or for that matter Inconsolata?

The Go fonts just don't look very good at all imho.

I'm surprised that people haven't commented on the implicit story here: the intention to deliver the "Shiny" cross-platform graphical toolkit for Go. If that happens, Go becomes one of the very few programming languages with a default cross-platform UI library.

I hope not with that font. It looks amateurish.

The font appears to be a refined version of Luxi Sans, which in turn is a refined version of Lucida Grande, which had been OS X's system font for 1.5 decades. Personally, I probably wouldn't call Bigelow and Holmes amateurs.

Let's hope it won't be as ugly as the Java crap. Or Tk.

Do you mean the old Java crap, like

https://netbeans.org/images_www/screenshots/platform/jmonkey...

https://netbeans.org/images_www/screenshots/platform/nbAWSAd...

https://netbeans.org/images_www/screenshots/platform/lg_soft...

https://netbeans.org/images_www/screenshots/platform/GGSSEph...

https://netbeans.org/images_www/screenshots/platform/platypu...

https://netbeans.org/images_www/screenshots/platform/blueMar...

or the new Java crap like

http://fxexperience.com/wp-content/uploads/2011/05/Charts-Ba...

http://docs.oracle.com/javafx/2/best_practices/img/saleshist...

https://blog.idrsolutions.com/wp-content/uploads/2014/03/vie...

No need to go further, just look at jconsole bundled with latest Java. It looks like crap to me.

jconsole is a very old, discontinued program, but it looks alright to me: https://www.dropbox.com/s/ji9hahszxttpetx/jconsole.png?dl=0

The newer bundled jvisualvm also looks fine: https://www.dropbox.com/s/549exowkau3ry3t/jvisualvm.png?dl=0

Funny, Java, using the default UI widgets, always looks a lot closer to this on my system:

https://i.stack.imgur.com/9UwJK.png

The screenshots are of the default widgets. The only question is which is the selected look-and-feel (for the "old" Swing toolkit), or the style sheet (in the new JavaFX).

Yes

Yes. Both look ugly and not even close to native.

On my Mac they look as close to native as any other app, which is to say that applications no longer have a uniform look anymore anyway. Chrome, Firefox, Twitter, my email client and all of my editors look no more "native" than modern Java apps like NetBeans or IntelliJ.

If you consider that many gui apps are written with HTML right now, I wouldn't worry about the looks of the toolkit as much, as long as it integrates and behaves as expected in X and Wayland and Windows and macOS and iOS and Android. That's more important than a skin, although I know many users prefer their platform's "native look", but what's native anyway, with mobile apps and web apps styling in many different ways. Even native Windows and macOS apps, which has a native look and feel, these days prefer to use a custom style, with most of the time following the design of vast empty white spaces and large controls, assuming everybody uses a 4k display.

What I'm trying to say is, if this comes out of the box and works reliably, then it'll attract more developers given the other ease of deployment aspects of Go.

> very few programming languages

You mean apart from Tcl, Python, Java, Factor, just about every Smalltalk apart from GNU Smalltalk, Racket, possibly Ruby…

Python has a default cross-platform UI library?

Well, it has tkinter

Yes, Tkinter, a Tk wrapper.

And what percentage of "all programming languages" is that?

No, there really aren't that many. Even fewer that are "professionally" usable. (I am not committing to Go's toolkit joining that latter set as I've not yet seen or used it.)

Elements of the proportional font, like the little foot on the 'a' remind me of Lucida Grande. Lucida Grade was the original OS X system font, which B & H also developed. This is not their first rodeo, its all about licensing.

The monospace is clearly an offspring of Lucida Typewriter. It is slightly condensed, a touch heavier, and with some obvious code-friendly variations (like a single-storey 'g' and a crossed zero) and a quirky, asymmetric curve inside the bowl of the 'b', 'd', 'g', 'p' and 'q' that I've instantly warmed to.

I'll give it a red hot go and develop in it for a day, but those chunky slab serifs are much busier than the Menlo I've preferred since 2009.

Definitely has a Lucida Grande feel to it, which, if I recall correctly, was one of the font on Plan9. The Go Mono isn't close to Lucida Grande Mono, but certainly looks like an interesting update.

Yeah, Plan 9 used Lucida Sans Unicode, of which Lucida Grande is a derivatives with very minor modifications.

Personally I use Lucida Grande for all my programming.

Go Mono is closer to (or a remake of) the Pelm font from Plan 9.

Interestingly strange they wouldn't just choose an existing open source font that got along with their license. I guess even you've got Google's wallet behind you it opens a lot of doors.

I agree, but then again the end result is another open source font family available for everyone to use, so I'm not complaining.

It confuses me even more considering that Google is behind it. Google just announced fonts for all unicode characters. [1] Why create an extra font that will cause every app to look like a "Go" app instead of a native Windows/Linux/Mac app?

[1] https://www.google.com/get/noto/

Google isn't behind it. Some Google employees who work on Go are behind it (well, and Chuck Bigelow too).

But as keeps getting said: it's about the licensing.

As I understand it, some of the main developers are being paid by Google to develop the language. The main page is also hosted by Google. Even though the language is technically open, that makes it a Google language for me. Not in a negative sense, it means that they should profit from it.

I still don't understand why they would have to license the Google fonts for testing and using them as standard fonts. EDIT: I just saw that Noto is available with an open license, just not the Go license. But I still think Google would relicense it to Go, seems like something Google would do in this case.

I was referring to the Go font, not Go itself; I thought that's what you were referring to.

The monospace font reminds me of the console on old Sun workstations running SunOS.

It's pretty hideous. The alphanumerics feel rather slapdash, like this whole thing was put together by the foundary on a Friday afternoon and made to meet the minimum requirements but without much love.

It's easy to fix though. Just pour more Knuthian bullshit on it until the hackers think its flaws represent important aesthetic decisions. It was made by an important type foundry adhering to the strictest mathematical principles, after all!

> The monospace font reminds me of the console on old Sun workstations running SunOS.

Yes! It really does: http://toastytech.com/guis/sv411boot.png

But I think it's mostly to do with the non-uniform line thickness (look at the asymmetry of the 'x').

To me it looks better than the SunOS font, but it certainly does resemble it. That's probably why it looks "old" to me, and not in a particularly nostalgic way. Then again, I didn't use Suns all that much.

I've actually been trying to find a PCF or TTF variant of that Sun font. If anyone can point me to it, I'd be grateful. Maybe in some folder of opensolaris or illumos?

I love that they actually included Bigelow's explanation of each decision made. So often (especially in the realm of programming fonts, it seems) decisions on letter forms in new fonts seem to be made "because it looks nice", but there is, in fact, a science behind it all. Indeed, Go Mono ticks every item I look for in a programming font (one of only 2 or 3 programming fonts that does): - slashed 0 - easy differentiation of 1, i, l, and | - open lower-case g - proper kerning and adequate width of r, n, and m

Unfortunately, I don't see myself switching away from Menlo to Go Mono for a silly and purely aesthetic reason: 5 point raised baseline * . Yes, yes...I know that's how pretty much every font has done * since forever, but after working with the vertically centered, six-pointed * in Menlo (and SF Mono), it's hard to go back.

Do you write OCaml or C (comments) by any chance? I've often found it hard to discover a typeface that has

    (* this is a comment *)

vertically centered. My usual choice is Fira Mono because it looks great and centers * vertically, though I would love a serif monospace font. Maybe Go Mono will be revised but I doubt it will be updated anytime soon.

When you say "6 point" do you mean it's bigger than usual?

Is there a place to obtain SF Mono without an Apple Developer account if you don't happen to have a macOS installation handy?

I've found the vertically centered "" to be far superior almost everywhere. Definitely for comments, but even for pointers (yes, I do write a fair bit of C) it becomes clearer that the glyph is part of the type signature, and not just a footnote.
By "6 point" I mean the character itself has 6 "arms", instead of the typical 5. For my taste, it makes the glyph feel more balanced.
There is this repo: https://github.com/hbin/top-programming-fonts . Unfortunately, I'm not familiar with the legality of obtaining Menlo without OS X/macOS. It is a variation on Bitstream Vera Sans, which is AFAIK Open Source, but I am completely ignorant when it comes to how licenses apply to fonts (as opposed to code).

As for SF Mono, that seems to be impossible to obtain even if* you have macOS and an Apple Developer account (only the UI fonts are available for download). I managed to dig them out of the Xcode application bundle and install them as system-wide fonts, but was greeted with a very scary warning stating that installing these fonts could destabilize my entire system (so far my OS is still running, though)...YMMV.

Centered double quotes?

Gah...silly markdown-not-really-markdown formatting. Should have been: "*"

pretty soon you will not be able to compile go without it being written in the correct font. thus making go code the same no matter where it is written or displayed!

Brings a whole new meaning to homoiconicity

Homoiconicity has more to do with code in language X being directly written syntactically and semantically as a convenient data structure manipulable in X. It does not have to do with consistency in appearance.

Love that screenshot. Reminds me of rebuilding Emacs, opening it up, and immediately remembering that I forgot to enable Xft or something.

This fonts are pretty cool. But I don't understand why they just used Roboto or Noto fonts.

Roboto appears to be licensed under Apache 2.0. Noto under SIL Open Font license.

As these fonts are purportedly intended for testing purposes, presumably they will be included in the package. Adding additional licenses to the codebase complicates the usage. You might agree to the terms of the Go license, but not the Apache license, for instance.

Since this new font is licensed under the Go license, there is only one set of terms you need to agree to. This is a much better situation for many reasons.

Considering the openness of these licenses the concern is silly. The tiny disadvantage of having an extra open license is heavily outweighed by the much higher quality and unbeatable coverage of the Noto fonts.

Also, considering that Google owns Noto and has relicensed it in the recent past, it would probably be possible for them to ship it under the Go license too.

Unfortunately if you use Noto fonts with Go Rob Pike and Nigel Tao will hunt you down, show up to your house and kill you and your entire family, so you have to factor that in to your choice.

> Adding additional licenses to the codebase complicates the usage.

Not really if the additional licensed parts are tests. Most things don't ship their dependencies' tests in the final binary.

From the designers of the Lucida typeface family.

The monospace serif typeface has pleasant, natural thick-thin strokes, giving it a substantial, typewriter-y appearance instead of the weak lines in most monospace serif typefaces -- remember Courier New?

Yep, Bigelow & Holmes, also the designers of the Luxi font family.

The monospaced font looks like an iteration on Luxi Mono [0], fixing some of the major issues (lowercase-ell vs. one, uppercase-o vs. zero).

The proportional font likewise looks very similar to Luxi Sans [1], the main differences I see being again the lowercase-ell and zero glyphs.

[0] https://www.fontsquirrel.com/fonts/Luxi-Mono

[1] https://www.fontsquirrel.com/fonts/Luxi-Sans

I see there's a black-on-white Gopher hiding at U+F800 in the middle of the BMP Private Use area (U+E000..U+F8FF). Besides that, only Latin, Greek, Cyrillic, and a few box drawing glyphs are provides. Are there any plans from the Go Fonts team to provide glyphs for all characters in the BMP, and beyond?

Nice. it looks interesting.

Do i need it? don't know. Will it be useful? might be.

I don't see any reason to complain. It's a completely free font people.

I see no downsides to this.

Exactly. On some other forums people complain like someone is forcing them to use it! I don't understand it at all. How does it affect their life in any way?

Don't like it? Don't need it? Move on with your life...

The screenshot vaguely reminds me of a scanned copy of code from the 80s.

Yes, it definitely gives the code a retro feel. My first impression is that I like it.

Why does a programming language need its own font?

Why not?

But seriously, it's of great benefit to Go programmers to have a font that shares the same license as Go itself. Most fonts are not so unencumbered.

Because it's extra, unnecessary cruft. May as well throw in generics as well, and inheritance and may as well develop your own OS for go while you're at it.

As you can tell I think this is just a silly waste of time for a compiler. Non native applications are near universally ugly and poorly designed and adding a custom font is just another slap in the face.

> Because it's extra, unnecessary cruft. May as well throw in generics as well, and inheritance and may as well develop your own OS for go while you're at it.

False equivalences are fun. :-)

> As you can tell I think this is just a silly waste of time for a compiler.

But the people who did this have nothing to do with the compiler.

Extra cruft from a technical perspective, but it is clear that the law was the primary driver here.

I was surprised to see that you didn't add any Go-specific code ligatures (e.g. for <- like Fira Code provides[1]).

Has there been any thought into providing a variant with some? While I could see why some might be against them I think they're rather fun and can make code more readable.

[1] see for example https://github.com/tonsky/FiraCode

This is honestly where I thought this was going when I saw the title. It would be cool for a font to be invested in the language it's used to describe to the point where it supports features of that language.

I use Fira Code for JS, HTML, and CSS and it's great. Very rarely to the extra fun ligatures get in the way, and when they are printed they look absolutely gorgeous. I wish all/most code samples in tutorials and articles were set in it so they would be a pleasure to read.

But these fonts left me scratching my head.

fyi you can get most sites to honor your font with a combination of the browser's default monospace font and extensions like Stylish.

even this comment box respects Fira Code, see[1]

[1]: https://imgur.com/a/LjbS3

There aren't that many places where Go's syntax would make such things useful. There's := and // for comments. A case could be made for [] to indicate slice. Reading over some code the only other one that seems to come up a lot is (), which is just "calling a function with no arguments" and I'm not sure I'd want that particularly distinguished. Comments are generally already color coded, so that really just leaves :=.

Although I could make a case for making :+ some sort of ligature that makes it obvious I just screwed up by holding SHIFT too long. :) You won't see it by scanning my code base, but I definitely type it a lot....

The font is ostensibly for the experimental UI, so that the font license would not encumber the code using the UI toolkit. That said, they did seem to put effort into making sure Go source code would look pretty.

Good question. Why does it need a mascot too at first place, I don't know either.

A mascot is just a type of logo, and logos definitely have their uses.

I just got this set up on a Linux system and I think these fonts are absolutely fantastic. This is the only "programmer's font" I've tried that was ever any good.

I 2nd that. Before I've usually ended up with PT Mono, but this Go font is bit more pleasing to work with. Thanks Google.

I like them but they won't be replacing PragmataPro which has ligature support and works in everything I use, is nicely condensed without feeling cramped and is just beautiful to look at.

Screenshots: http://imgur.com/a/tiE76 first image is Pragmata second Go font, no contest for me.

I used to use Pragmata, but have since switched to Iosevka. It's similar in width and also supports ligatures.

I think these are made in preparation for high-DPI screens.

The serifs are short enough that I couldn't see them all on my regular screen (particularly the right-hand serif on the lowercase 'w'). But on my phone I would be able to see it perfectly well. On a high-DPI screen, the text isn't blurry or anything. They didn't focus on the rendering at all it seems, but made their screenshots in high resolution.

The monospace font looks interesting. Fixed-width serif fonts are not that common.

But creating fonts for Go? That sounds like a solution in search of a problem.

Fixed-width serif is exactly what I wanted! It's refreshing to be able to switch from serif to sans-serif, I do that on my Kindle about once a month and the text immediately becomes less boring.

This looks like an improved version of Luxi. I couldn't use Luxi Mono because O and 0 look the same, but this fixes that. I had been looking for a serif monospace font for a long time and this looks great.

Did anyone else try to use it in xterm or rxvt-unicode?

In xterm and Emacs the vertical spacing seems to be too small, making it look pressed together.

In rxvt-unicode the only problem is that the renderer displays it stretched horizontally like a short but wide block.

The vertical line of the box-drawing characters (U+2502 and etc.) is not long enough.

While you are at it, can you guys complete the APL symbols?

Wish they had talked to Fabrizio Schiavi..

You mean the Pragmata font?

Yes, that's the Pragmata guy. I first paid for his font in January 2004, and he still sends out updates. (I did upgrade to Pragmata Pro in 2011, but still). He's been doing nifty program specific ligatures lately.

These look exactly like the Plan9 fonts (which IIRC were also by Bigelow&Holmes). Ironically, the Plan9 folk seem to shun TrueType in favor of bitmap fonts... I'm pretty sure the Raspberry Pi Plan9 image I'm running at my home office only has bitmap fonts installed.

Plan 9 uses Lucida Sans Unicode, which was the OS X system font (as Lucida Grande) until recently. There is a resemblance between this font and Lucida Sans Unicode, they come from the same foundry, after all, but they are significantly different.

> Ironically, the Plan9 folk seem to shun TrueType in favor of bitmap fonts.

It's true Plan 9 uses bitmap fonts, but that's just how the technology was implemented (so you could use BitBlt, etc), there is no shunning of trye type fonts.

Clearly you haven't been on 9fans over Summer :)

Was there a font thread you're referring to?

The monospaced font reminds me of Luxi Mono (with the 0 solved) and of the Sun console font.

When reading this, I wanted to check the x-heights of letters, as they seemed proportionally shorter than for example Roboto.

Ended up not checking, but coming across an article by Google on typography in general, part of their Material Design. https://material.google.com/style/typography.html#typography...

Yuck, the monospace font feels too dense, and dislike the serifs.

I think the rendering is horrible too, with plenty of colour fringing and unevenness.

The monospace font reminds me of the generic "Asian product manual font" - although the individual shapes are slightly different, it has a similar feeling to MS Mincho:

http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-...

Images of the way a font was rendered on some output device are always going to look weird and wrong on another one.

The monospace is kind of okay, I guess, but considering the competition there's nothing special about it. Many users will be coding with colour keyword support anyway, so the idea that it's going to be super-great for Go code is strange.

I found the proportional font really hard to read.

It's not as if Google can't do good typography:

https://fonts.google.com/about

So this seems like a rather self-indulgent and not wholly successful side project.

You do realise that B&H designed the original OS X system font, Lucida Grande, right?

And also the original MacOS font, Chicago!

It's a pity when newer typefaces don't have lighter weights — they look far better on high resolution displays than normal/regular weights, which look almost bold.

My favourite example and what I use daily, Office Code Pro Light: https://raw.githubusercontent.com/sjrmanning/darkokai/screen...

Thanks for the recommendation! going to swap it in as a replacement for Fira Mono for a while, see how it feels.

Wow. Gorgeous.

This is MacOS font rendering for you, in Linux normal weight looks normal

Or rather, in macOS it looks normal and in Linux it looks too thin.

Agree - I find these fonts deeply unpleasant, and would never choose to work with the monospaced option.

It's a matter of personal opinion of cause, but I find it extremely easy on the eyes. Some one else posted a screenshot with some code displayed using the Go font, and it's extremely readable, to me at least.

Yup. Horrible fonts IMO. I would never, ever work with these.

I love serifs and haven't found a good monospaced serif font yet. This one looks good but has some minor bugs like spacing and * not being centered vertically for the times you write OCaml or C comments. I'm trying it out anyway because I've been missing serifs in my terminal and editor for too long.

Go has a cross-platform GUI toolkit? Should I wait for it instead of learning Qt/C++?

It's experimental, so I wouldn't. Pick it up when it gets better.

Qt/C++ skills are both good to have anyway, so it won't be time wasted.

Is it just me, or is every other font produced by Bigalow and Holmes essentially Lucida?

This is much closer to Luxi (especially the monospace font) than to Lucida.

Yup, but Luxi itself is essentially a remix of Lucida.

I usually prefer DejaVu fonts [1]. One of the best fonts for terminal and coding under free license.

[1] http://dejavu-fonts.org/wiki/Main_Page

It'd be nice to see font examples with syntax highlighting as well.

https://s22.postimg.org/x92shc4wx/Screenshot_at_2016_11_16_2...

Rust not Go but same idea

Looks like a good font choice once you get used to it.

The first example shown in the post reminds me of the boot up font you would see on an old SPARCstation.

I hope this UI toolkit will take the good parts of CSS and HTML, and perhaps toolkits like React.

Honestly how could serif be a good idea? I do not see the appeal at all.

Why wouldn't they just use Google Droid? Strange.

From the comments here so far, it seems really important that they could be under the same permissive license as the rest of the project.

Another reason to not just use Google fonts is to make sure they do not - even if unwittingly - give an impression that the Go language is controlled by Google. This is an open source initiative (at least in spirit) and needs to make choices akin to its roots.

Not a bad font. Personally prefer Anonymous Pro.

Reply on news.ycombinator.com