> Why do Go articles so often have no syntax highlighting?
Rob Pike, one of the 3 original Go architects, has stated in the past he doesn’t like syntax highlighting [1].
> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals. — Rob Pike
Maybe Sergey Kamardin, the author of this article, is following Rob Pike’s philosophy. That being said, the website has references to a Go library called Chroma [2] which purpose is to colorize source code. The library borrows ideas from a popular JavaScript library called “highlight.js” [3] and that is why you can also see “highlight” CSS classes. The website downloads this CSS file [4] which contains a couple of instructions to make the code look the way it looks.
The official Go Blog has popularized this type of design [5] and many Go programmers has adopted it in their own websites.
> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals. — Rob Pike
Yeah everyone "knows" this, but where's the proof? I've never seen any proof that syntax highlighting helps someone who knows their code well. Things that are supposed to be common knowledge like this often turn out to be false when someone eventually decides to challenge their assumptions.
I programmed for a full decade with Notepad alone. I don't think colored keywords are important, though I use syntax highlighting today.
There are probably tasks you can perform quicker when you're accustomed to syntax coloring, since the brain tends to capitalize on association with easily detected features. Finding the start of a function could be such as task, but the gain would be low (a few 100s of milliseconds, I'd guess).
At the same time, it might slow down other tasks, which can be harder to identify. I was just changing some html template, and I made a dumb "extra quote"" error because of highlighting. It probably took me more than a minute, which would offset a great number of small speedups.
I guess the conclusive proof won't be easy to find.
Why would I know whatever code I'm reading well? Most of the time I'm reading code it's unfamiliar to me, like for instance library code, picking up a project after a long break, or in this case on a blog.
Well, he has a point. If you need a variable to be colored to know it's a variable, then I'd argue that you don't really know what you're doing.
If you don't need a variable to be colored to know it's a variable, then why do you color them?
A counter argument would be that you have this huge visual cortex in your brain which can use cues like this to help you quickly find what you're looking for.
A counter argument to that would be that you should know your code well enough to not need to rely on anything like that.
When I started programming, I had notepad and that was it. I didn't need colors. I use colors now, though. What's that say? I have no idea.
Not everything you do is about need. I think highlighting helps reduce some of the cognitive load involved in mentally parsing a code block. Especially in a language you might be unfamiliar with. I also happen to like the way it looks.
> A counter argument to that would be that you should know your code well enough to not need to rely on anything like that.
that's not a counter argument to that. nobody in the world no matter how brilliant knows giant complicated codebases inside out. and the best way to parse those is to use colors to aid your brain in differentiation. otherwise its all one garbled mess.
Article has very bland design, making it hard to read the embedded code. Comments are light grey on white, not easy to read on some screens.
The Go Tour has no syntax highlighting, but the design on the pages are fit for the purpose of learning the language: https://tour.golang.org/welcome/1
The typical Go-presentations (http://go-talks.appspot.com/github.com/SatishTalim/slides/sa...) tend to be very short and readable, but you'll find www-pages/videos about Go having both syntax highlighting and not, good design and not. Good Go code tend to be short. Many gophers prefer syntax highlighting, so there's no need to force-adopt "opinions" when not strictly necessary or ideal. Alot of Go is very community and stdlib-driven though.
I don't think that's the reason, otherwise I'd see it evenly in all languages and not only Go. I don't think Go users inherently value typography more than users of other languages
Rob Pike, one of the 3 original Go architects, has stated in the past he doesn’t like syntax highlighting [1].
> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals. — Rob Pike
Maybe Sergey Kamardin, the author of this article, is following Rob Pike’s philosophy. That being said, the website has references to a Go library called Chroma [2] which purpose is to colorize source code. The library borrows ideas from a popular JavaScript library called “highlight.js” [3] and that is why you can also see “highlight” CSS classes. The website downloads this CSS file [4] which contains a couple of instructions to make the code look the way it looks.
The official Go Blog has popularized this type of design [5] and many Go programmers has adopted it in their own websites.
[1] https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/kG3B...
[2] https://github.com/alecthomas/chroma
[3] https://highlightjs.org/
[4] https://gbws.io/scss/syntax.min.css
[5] https://blog.golang.org/go-fonts