Live data from Hacker News

GitHub dropped Pygments

greghendershott.com

11–20 of 133 posts

Re: GitHub dropped Pygments

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

Re: GitHub dropped Pygments

#12

Earlier quoted context omitted.

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

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?

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

Re: GitHub dropped Pygments

#13
post #4

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

What is actually being used for syntax highlighting now? Linguist doesn't appear to contain any C++.

Re: GitHub dropped Pygments

#14
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?

Re: GitHub dropped Pygments

#15

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.

I don't think it's paranoia. I think it factually is a single point of failure, which is a bad thing(tm). And GMail is a single point of failure for my (and my companies) e-mail, and that bothers me too, despite the fact that I'm not doing anything about it :)

Re: GitHub dropped Pygments

#16

Earlier quoted context omitted.

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?

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

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

Re: GitHub dropped Pygments

#17
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?

Re: GitHub dropped Pygments

#18
post #14

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?

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?

Re: GitHub dropped Pygments

#20

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.

The counter-argument is true, though. I have a server that I'm able to log in via SSH. I just backed up one of my repositories like so:

    sircmpwn@homura ~/s/K/kernel master> ssh irc.sircmpwn.com git init --bare kernel
        Initialized empty Git repository in /home/sircmpwn/kernel/
    sircmpwn@homura ~/s/K/kernel master> git remote add backup irc.sircmpwn.com:kernel
    sircmpwn@homura ~/s/K/kernel master> git push backup master
        Counting objects: 4735, done.
        Delta compression using up to 8 threads.
        Compressing objects: 100% (1765/1765), done.
        Writing objects: 100% (4735/4735), 7.62 MiB | 650.00 KiB/s, done.
        Total 4735 (delta 2954), reused 4699 (delta 2930)
        To irc.sircmpwn.com:kernel
         * [new branch]      master -> master
Post reply on HN