Live data from Hacker News

Go fonts

blog.golang.org

41–50 of 182 posts

Re: Go fonts

#41
post #13

Earlier quoted context omitted.

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?

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.

Re: Go fonts

#42
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.

Re: Go fonts

#43
post #13

Earlier quoted context omitted.

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?

> 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?

Re: Go fonts

#44

Earlier quoted context omitted.

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

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.

Re: Go fonts

#46

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…

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

Re: Go fonts

#47
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.

Re: Go fonts

#48

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.

Re: Go fonts

#49
post #13

"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.

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

Re: Go fonts

#50

Earlier quoted context omitted.

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

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.

Being self consistent is not important, being constant with the environment is important.
Post reply on HN