Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go fonts

blog.golang.org

Post reply on HN
Print view View original

151–160 of 182 posts

Re: Go fonts

#151

Post by jerf »

LeonidasXIV wrote: post #102
sjellis wrote: post #71

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.

> very few programming languages You mean apart from Tcl, Python, Java, Factor, just about every Smalltalk apart from GNU Smalltalk, Racket, possibly Ruby…

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

Re: Go fonts

#152

Post by vvanders »

creshal wrote: post #81
SanFranManDan wrote: post #34

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.

> 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 hope they aren't planning on going down the path of golden-image testing, if so they're in for a world of pain.

Re: Go fonts

#153

Post by nurettin »

adrianN wrote: post #136
nurettin wrote: post #110

Earlier quoted context omitted.

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 o…

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.

Re: Go fonts

#154

Post by nurettin »

kalleboo wrote: post #115
nurettin wrote: post #110

Earlier quoted context omitted.

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 o…

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

Re: Go fonts

#155

Post by jerf »

sambeau wrote: post #112
enneff wrote: post #14

Earlier quoted context omitted.

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.

I was surprised to see that you didn't add any Go-specific code ligatures (e.g. for 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

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

Re: Go fonts

#156

Post by EdiX »

modeless wrote: post #72
randomdata wrote: post #57

Earlier quoted context omitted.

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…

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.

Re: Go fonts

#157

Post by tyingq »

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

Re: Go fonts

#158

Post by fs111 »

bhrgunatha wrote: post #135
pvg wrote: post #99

Earlier quoted context omitted.

Whoa there. I was asking a question, somewhat incredulously. Maybe the person who wrote that comment is misinformed. Maybe they know something we don't. Nowhere did I suggest they were 'JetBrains shills' and neither should you, unless you have some evidence of it.

In the UI options there's an option for GTK but I've just checked (both IDEA and PyCharm) and I think it's just a theme. I genuinely thought it was using GTK widgets.

That is most likely the GTK look and feel that ships with java swing. It is an emulation, not native.

Re: Go fonts

#159

Post by reikonomusha »

wickawic wrote: post #38
jjn2009 wrote: post #17

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.

Re: Go fonts

#160

Post by talideon »

4ad wrote: post #142
talideon wrote: post #114

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.
Post reply on HN