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

[conradev]

One other thing to note is that it's not just syntax highlighting, it's also recognizing the language a given repository is written in.

Some of my repositories that use Logos[1] are now incorrectly classified as a combination of Ruby and Scala[2].

[1] http://iphonedevwiki.net/index.php/Logos

[2] https://github.com/conradev/Tweaks

[lelandbatey]

Yep. And now Github thinks my Makefile is JavaScript: https://github.com/lelandbatey/link_grab

[greghendershott]

I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary:

For many languages this is a significant and distracting degradation in the presentation.

I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reasonable choice.

The situation now is that they've replaced a library that had been handling highlighting thoroughly, with a variety of text-editor lexers that mostly are not. People like me who already contributed to Pygments, aren't feeling motivated to do this all over again for no good reason. So it seems likely the lexers will remain poor for quite a long time. Which is unfortunate.

Finally, at the time I wrote my blog post, I was speculating about the motivation because GitHub hadn't explained why, yet. Someone later did explain ("because speed") in the issue thread.

[res0nat0r]

Are the majority of languages now broken, or just a small niche subset that don't see much use vs. ruby, python, etc?

If a few minor languages hardly anyone uses as compared to the whole site might need some fixing, this still seems like a win from Github's side of things since per the graph the change did in fact significantly improve render times.

[Demiurge]

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

And if it does, the problem lies not with the syntax highlighting, not even close...

[muyuu]

Also, not a great idea to rely on some "cloud" 3rd party service to host your portfolio IMO - at least not exclusively. Maybe I'm old-fashioned.

That said, I don't think anyone will bin a candidate because Github didn't highlight his or her code properly.

[regularfry]

It's not that people necessarily choose to host portfolios on github, but more that employers will treat whatever's on there under your name as a portfolio regardless.