Live data from Hacker News

GitHub dropped Pygments

greghendershott.com

71–80 of 133 posts

Re: GitHub dropped Pygments

#71

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.

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

It's organizationally a single point of failure. The company could easily decide to shutdown access to all of it's servers and everyone relying on github for issue tracking, etc would be screwed.

Re: GitHub dropped Pygments

#72

Earlier quoted context omitted.

The new highlighter may be faster, but is syntax highlighting frequently a bottleneck at GitHub? That seems unlikely.

In large diffs, it can definitely be a problem.

There is no syntax highlighting in the diff view, so I doubt it.

Re: GitHub dropped Pygments

#73

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…

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.

Re: GitHub dropped Pygments

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

Re: GitHub dropped Pygments

#75
post #55
post #52

Earlier quoted context omitted.

https://bitbucket.org/ https://www.codebasehq.com/ https://www.fogcreek.com/kiln/ https://about.gitlab.com/gitlab-com/ I must admit, I rather like bitbucket, you can get free private repositories with them too.

Thanks for mentioning GitLab, we offer unlimited private repo's and collaborators and an on-premises version too.

We've been happily using GitLab for months now, can't recommend it highly enough. If there was an open source bug tracking/ticket app that played nicely with it I'd switch all of our teams over to it sooner rather than later.

Re: GitHub dropped Pygments

#76

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…

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.

Re: GitHub dropped Pygments

#77
post #76

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…

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

> expect people to hold you on that promise

What promise did github make?

Re: GitHub dropped Pygments

#78

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.

How hard is it for people to switch, if they want/have to? They might be dependent on GitHub issues. That might be preventable by using some issue tracker that can actually be put under git (like Ditz), though I guess it makes collaboration with non-owners of the repository more difficult. Other than network effect, what else is it that binds people to GitHub?

Re: GitHub dropped Pygments

#79
post #76

Earlier quoted context omitted.

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

> expect people to hold you on that promise What promise did github make?

The promise any service makes. To solve my problems and to work _as a service_ for me.
Post reply on HN