
GitHub dropped Pygments - mkonecny
http://www.greghendershott.com/2014/11/github-dropped-pygments.html
======
abhinavg
I honestly don't see a problem here. They decided to change a backend library
for a non-essential system in their product. Most services don't ask for
permission or make announcements when they make changes like this.

 _The approach seemed to be, if things break, people will report it and we’ll
fix it._

While this may not be the best approach, the number of languages supported is
too high for a person to check each one manually. Generally, I imagine they
wouldn't expect a change like this to break anything significant.

 _[people] use it as a portfolio. [..] To suddenly doink the appearance of
people’s portfolios is unfortunate._

It is very unlikely that syntax highlighting errors in GitHub will affect
someone's chances of getting a job.

Sure, this switch could cause some issues but they don't seem to be severe
enough to kick up a fuss over.

~~~
Argorak
I beg to differ. Github pushes its code rendering as far as possible,
including providing widgets to embed code snippets into you blog. It is also
the _main content they display all the time_. That's not "non-essential".

Just switching the library and breaking things at a whim is problematic.

Also, the number of languages may be 316 (including some oddballs like
"Unified Parallel C") but that's still a possible number to check for at least
for major, obvious breakages. Still, for people that do use Unified Parallel
C, adequate highlighting might just be the reason to choose that platform and
use it to write your blog in, instead of writing a custom highlighter for
prism.js.

Sorry, if you business is code and you decide to support 316 languages, expect
people to hold you on that promise.

That said, also: errors happen. But that isn't a reason to give them a pass,
just not to put too much weight on such things. It doesn't break the platform
at large, but terribly inconveniences some users, and they are very right in
being upset, too.

~~~
tomcorrigan
> expect people to hold you on that promise

What promise did github make?

~~~
Argorak
The promise any service makes. To solve my problems and to work _as a service_
for me.

~~~
resetti
That's neither how promises nor the laws around them work. GitHub owes you
nothing except what was explicitly spelled out when you signed up.

Half the difficulty of running a business comes from customers with a sense of
entitlement not understanding this.

~~~
Argorak
The other half being providing a service they find worthwhile that doesn't
change at every whim.

Taken to the other extreme, a constantly breaking Github doesn't have any
value proposition.

Promises are not always explicit and not at all related to laws.

The next Transformers being something to look forward to is a promise, but
that doesn't mean not liking it is in any way wrong or that I could sue
someone for it. I can choose to leave the movie and never go see one again.
The producers of Transformers certainly owe me nothing, but they also cannot
tell me how to feel about their handling of the material.

Github promises the most awesome code hosting around. That's a very different
thing for many people. And to some people you can live up to the promise, to
some people you cannot and it's perfectly fine for those to feel let down.
Calling all those people "entitled" is, quite frankly, insulting.

As I said: putting this like it is the end of the world is overreaching, but
it is a valid complaint and a valid sentiment. Saying that this is the most
important thing on Github, because it happens to be specific your problem is
entitlement.

Finally, it isn't true that you are only bound by spelled out things. The law
many people cite so often has the concept of Good Faith:
[http://en.wikipedia.org/wiki/Good_faith_%28law%29](http://en.wikipedia.org/wiki/Good_faith_%28law%29)
and similar fun things that extend beyond that. So Github _does_ owe me beyond
their ToS. (I appreciate that this is probably not a case covered by this)

It's a common sentiment in these circles that only the rules written on the
contract are the ones that count, while nothing can be further from the truth,
widely varying from legislation to legislation.

~~~
scott_s
Agreed. A business relationship is more like personal relationships than I
think some technical people think. Pointing at the contract is a failure
condition.

------
isomorphic
This sort of thing feeds my paranoia about GitHub being a giant single point
of failure in the open-source world.

I know the argument: Someone, somewhere has a copy of each repo checked out,
so we (the nebulous "we") could reconstruct everything from the diaspora of
".git" directories.

It just bothers me to think how dependent OSS has become upon GitHub.

~~~
shurcooL
> GitHub being a giant single point of failure

What is our definition of a "point"?

If you have an external hard-drive backup of your laptop, that's 2 points of
failure, right? If someone else has 10 external hard-drives that they keep in
different places, that's 10 points, yes? But what stops you from calling all
those hard-drives "a giant single point of failure"? If all of them are
destroyed, the data is lost.

I just don't get these arguments... The chances of all GitHub data being lost
is probably less likely than BitBucket and SourceForge combined.

~~~
isomorphic
By "failure," it never occurred to me to mean a technical or operations
failure.

I'm thinking: shut down due to the business model not working, or some other
business-model variant, such as gradually getting intolerably crappy like
SourceForge. Cash flow isn't great; let's introduce "sponsored" code. Etc.

------
latkin
F# highlighting is also now totally gone with this change. Code is highlighted
with some random lexer than doesn't even understand // comments. Rather
frustrating, given that a lot of F# development is centered around GH, and GH
themselves use F# in a couple of places.

Browsing the issues list, this isn't just "fringe" languages, either. Perl,
PHP, Go, and Clojure all appear to have regressed to some degree.

------
Matthias247
I don't know about pygments but my experience with writing a custom
highlighter for Sublime Text (aka Textmate, Atom and what Github seems to use
now) was that it is not really a good and reliable system for highlighting.

It is really easy to highlight simple things (keywords, numbers, ...). However
when it comes to more complex scenarios (e.g. where the type of a word depends
on the previous one) then the singleline regex based mechanism shows it
weakness. Due to that many language support plugins will yield wrong results
when you start to split things like function declarations over several lines,
even though it's perfectly legal in the languages. Some things can be worked
around with the start/end regexes, but nesting those multiple levels deep can
get quite akward and I don't think that they were thought of for things beyond
braces and multiline comments.

Therefore I don't know if Githubs move here is a really good choice. However I
think their main motivation might be that this file format already has such a
big ecosystem due to Textmate, Sublime and Atom and the parser has a high
performance so that they went for it.

~~~
jessaustin
I really would have expected a highlighter written in Coffeescript to do a
better job highlighting Coffeescript.

[https://github.com/atom/highlights#using-in-
code](https://github.com/atom/highlights#using-in-code)

(Generic identifier looks the same as class identifier looks the same as a
property in an object literal looks the same as a string. I guess maybe orange
is just the color used left of an equal or colon, but in that case the string
color should be different.)

------
cespare
I assume the new syntax highlighter is way, way faster than pygments. It's
written in C++ rather than Python. (Atom uses the same grammar format, but a
Node implementation.)

~~~
walterbell
Why not give existing users the choice of migration and timing?

~~~
scott_karana
Giving users the choice of "slow" in a webapp means that both hardware _and_
software deployment/management/purchasing is greatly complicated.

~~~
walterbell
Existing users are being served by existing hardware and software. It wasn't
"slow" for them before.

Many companies provide existing users with advance notice of technology
migration, so they can plan and adapt.

Why is advance customer notice incompatible with Github ops planning?

~~~
__david__
It's not like they broke git, or some actual important interface. They stopped
syntax highlighting on non mainstream languages until new lexers can be
written. What on earth would you as a customer have done if they had said,
"syntax highlighting in the browser for <your-favorite-language> is going to
go away in a week"? Are you going to migrate away from github? Or shrug and
say, "bummer"?

Github did the most efficient thing: break it and let the people who actually
care fix it.

~~~
walterbell
> _It 's not like they broke git, or some actual important interface_

Does the vendor or the customer decide what's important to the customer?

~~~
JetSpiegel
GitHub is free, the repo owners are not the customer.

~~~
lmm
Many of us are paying GitHub for private repos.

~~~
technomancy
Seems unlikely that this is true for the affected languages like Racket
though.

~~~
soegaard
I for one am a paying customer :-)

------
slantedview
It's worth noting that even syntax highlighting on common languages like Java
is currently messed up on Github. I hope it's fixed eventually, but kinda lame
to take something that wasn't broken and break it.

~~~
needusername
Linguist has trouble telling C and C++ apart.

------
hawkice
GitHub: a product so close to our hearts that even extremely well meaning
changes that really do help in many cases can sting sometimes.

I normally wouldn't understand this type of thing (others say they don't see
the problem and it's quite clear where they are coming from), but in a way I
_do_ see the author's point of view. When you build something people really
care about, any change, no matter how minor, has the opportunity to impact
someone. That's why we all build things, isn't it?

------
ivan4th
Seems like Common Lisp syntax highlighting suffered, too.

------
shurcooL
Interesting coincidence, as I've just changed the highlighter in my Go library
for offline rendering of GitHub Flavored Markdown [1] 23 hours ago.

[1] -
[https://github.com/shurcooL/go/commit/6aad35a0a60fd67927f446...](https://github.com/shurcooL/go/commit/6aad35a0a60fd67927f446e140367f932f1b46b2)

------
frontsideair
I understand the author's exasperation, but the post is surely filled with
loaded words and wild speculations. It may get the message across, but this is
not the way to start a conversation.

------
ttwwmm
Rendering of reStructuredText disappeared in GitHub Enterprise ~6 months
ago... I wonder if the reasoning was the same. More limited resources in the
GHE VM environment?

------
alayne
Racket is a fringe language. Github has about as many Prolog repositories as
Racket repositories.

If Racket syntax highlighting was causing performance issues that were
noticeable to Github, performance must have really sucked. Why should Github
let Racket drag down its capacity?

~~~
walterbell
Is that the message an open-source vendor wants to send to developers: your
code is welcome, unless it's a new and unproven "fringe" language?

How would a "fringe" developer feel about that vendor's brand after their
language has become successful? Would they like/trust/recommend the vendor to
upcoming developers?

~~~
alayne
Racket isn't new. It's a scheme which has been in development for around 20
years.

Reading their thread, it sure sounds like they want to work with the community
to make Racket code viewing a good experience.

------
GFK_of_xmaspast
"""pygments.rb had an interesting history of trying to use a Python library in
Ruby on a high-traffic web site. They had tried various approaches. The final
approach — piping to a long-running Python process — seemed to work well. """

That doesn't fill me with a lot of confidence in this thing.

------
_pmf_
GitHub is not your personal vanity site.

------
jarcane
It is still difficult for me to express my opinion of this move without simply
resorting to strings of profanity. Frankly, I suspect Atom has more to do with
it than anything.

~~~
walterbell
Why is Atom more strategically important to Github than existing developers?
Is there an economic belief that Atom will reach some larger base of untapped
developers who don't know how to use other editors?

If a vendor cannot be trusted to host your content without regression, why
would you trust that vendor to supply your mission-critical editor?

~~~
stingraycharles
No, but the article highlights that maybe they are using Github's traction to
get a better syntax highlighter for Atom. As in, instead of waiting for a
large community of Atom users contribute Atom syntax highlighting, they simply
push the same engine onto Github and let that community take care of the
syntax highlighting they actually care bout.

If this were the case, it would be slightly evil, but very clever business-
wise. But we don't know, so all this is is a small conspiracy theory.

