Hacker News Reader

Comment by cespare | Hacker News Reader

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

View on HN

Your assumption is correct. The blog post links to an issue in which an official statement (and a graph) can be found:

https://github.com/github/linguist/issues/1717#issuecomment-...

>By using TextMate grammars we also get some nice features like highlighting SQL inside Ruby heredocs. But the main motivation was improving performance.

Most important link in this thread.

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

Given the discussion going on at https://news.ycombinator.com/item?id=8650952 , this sounds like it might also increase the risk of exploit.

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.

Large blobs, then. I misspoke.

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

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

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

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

Many of us are paying GitHub for private repos.

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

I for one am a paying customer :-)

"Web 2.0: don't like it? Tough shit."

That's the nice thing about actual software with actual versions that you actually install: it doesn't change out from under you at someone else's whim. No sane person would use a "Cloud" C compiler. Of course, GitHub is just a mashup of online backup and Facebook, so it doesn't matter if it breaks.

Dear downvoters, have you heard of the Streisand effect? This thread now has the most downvotes (-14) of the many comments I've posted on HN. There is nothing factually incorrect in my posts. Why does this question deserve five downvotes?

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

Edit: -20 downvotes. Previous record was -3.

People are downvoting you because you're bikeshedding like a madman. The post I'm replying to will soon be downvoted too, because you're whining about getting downvoted.

Thanks for the explanation, and the new word.

Here to help :-)

This situation is very different from the Streisand effect. In the Streisand effect a single party is trying silence everyone else. Here everyone is trying to silence you.

They are nearly opposite situations. A minority trying to silence a majority vs a majority trying to silence a minority.

In both situations the majority wins.

That is true if all downvoters are independent.

Keep in mind that HN has cultural norms for downvoting, it is explicitly not for "silencing" opinions.

> HN has cultural norms for downvoting

Those cultural norms are not written into any of the faqs or guidelines and they only exist within a subset of the users of the site.

I don't know why you were downvoted so heavily! I would have thought that a few downvotes would have been enough.

"Those cultural norms are not written into any of the faqs or guidelines "

Cultural norms usually aren't, that's why they're culture.

But those cultural norms are also only strong in a small subset of users. Plenty of people vote to agree or disagree, and this was acknowledged by pg. "Don't down-vote to disagree" is something brought over from Reddit and there is some strong resistance to it in some long term users (here longer than six years).

Complaining about downvotes is one of the easiest ways to accumulate them.

Downvoting is (afaik) for not meeting the norms of polite / intelligent discourse as opposed to "we disagree with your opinion". There are opinions which if expressed breach out taboos - the usual range if racism sexism etc - but this is certainly not the case here.

So no, I think downvotes for a comment that is polite, intelligent, on topic and part of a discussion was the wrong use of downvotes.

I still don't agree with it of course :-) User choice is a bugger on cloud services especially where they are shelling out to run the pygments lexer.

On top of which is probably the interesting issue that there is no longer a binary on/off for most features. AB testing, feature toggles, stayed rollouts all mean we never quite know which version of a service we are running.

I don't think it is necessary for Github to provide choice for this sort of thing. It isn't a ground-breaking, massive change to their main product. To me, it seems like an unnecessary choice that would only create confusion and make their product more difficult to navigate and use.

Reply on news.ycombinator.com