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.

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.

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.

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.

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

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.

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?

Seems like Common Lisp syntax highlighting suffered, too.

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

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.

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?

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?

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

GitHub is not your personal vanity site.

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.