So, knowing all that, we were motivated to create our own solution by three things: There are some newer, code-specific open source projects out there, but they definitely don’t work at GitHub’s scale. The user experience is poor, indexing is slow, and it’s expensive to host. You can read a bit more about our journey in Pavel Avgustinov’s post, A brief history of code search at GitHub, but one thing sticks out: we haven’t had a lot of luck using general text search products to power code search. To be fair, we’ve tried and have been trying, for almost the entire history of GitHub, to use existing solutions for this problem. Why would you do that? Aren’t there plenty of existing, open source solutions out there already? Why build something new? At first glance, building a search engine from scratch seems like a questionable decision. We call this search engine Blackbird, but before I explain how it works, I think it helps to understand our motivation a little bit. So, how does it work? The short answer is that we built our own search engine from scratch, in Rust, specifically for the domain of code search. One question we hear about the new code search experience is, “How does it work?” And to complement a talk I gave at GitHub Universe, this post gives a high-level answer to that question and provides a small window into the system architecture and technical underpinnings of the product. From launching our technology preview of the new and improved code search experience a year ago, to the public beta we released at GitHub Universe last November, there’s been a flurry of innovation and dramatic changes to some of the core GitHub product experiences around how we, as developers, find, read, and navigate code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |