colin353

Colin here (I'm the "named employee"). I don't mind being called out, FWIW. I'm proud of what we built.

We would definitely have implemented sorting by recency if it was trivial to implement. But as I said before, our data shows that it is infrequently used, and to scale our search index, we designed it in a way that makes this kind of sorting tricky.

Sometimes to ship products like this, tradeoffs have to be made, and I continue to think we made the right one. Nevertheless, it's good for me and the team to hear feedback like this so we can continue to improve the product.

Ah, you need to log in to get access to the new code search!

Yes, we're working on bringing it to GitHub enterprise right now.

Great point. Yes, we initially focused on zero-config approximate code navigation. But we do intend to support build-based code navigation in the future, since the approximate code navigation experience can be pretty poor for some languages (e.g. C/C++).

We have not done this yet, but we do intend to.

Actually, our search engine is so fast that syntax highlighting the search results is often slower than finding them... so if we store the language tokens directly in the index, we'll be able to directly emit syntax highlighted snippets and make it even faster.

It may also enable some interesting search capabilities in the future, like searching within comments or by code structure.

Good question. We still construct ngrams for it, exactly the same way. So for example, we might extract `aaa`, `aaa`, and `aaa`. Or we may extract `aaaa` and `aaaa`, or perhaps `aaaaa`. Then we deduplicate to find the unique ngrams and look them up in the index.

So it's possible that a document containing `aaa` might match our ngram search, but we double check after retrieving them and exclude them from the result set.

We have fixed it behind a feature flag that isn't yet rolled out. Still experimenting with it. But expect to see that resolved in the next couple weeks

Positive feedback feels nice, but negative is way more useful to making a great product.

We're changing an website that millions of people use every day. Hopefully we mostly have a positive impact. But if we're making it worse, even in a small way, that matters a lot to be aware of.

Appreciate the feedback.

> static view of the core

Not sure what you mean by that, can you elaborate?

FWIW we are working to more tightly integrate code search into the code view.

And absolutely, performance matters a lot to us. Sorry for the slow experience, you're not the only one, particularly outside the US. Only thing I can say is we're working on it.

I'm guessing you are in our Code Search Technology Preview (which was at cs.github.com), which gives you access to this new UI as well.

By the way, feel free to opt out if you hate the new UI - it's super easy to opt out from the code view page, or from the feature preview menu.

We're not using server side rendering extensively at GitHub (yet) but are experimenting with it on some React pages. Hoping to make the pages even faster than the previous Rails/ERB pages