HackerTube.dev

Stanford Seminar - Google's Steve Yegge on GROK

Stanford Online · 29.8K views · 2012-10-24 · 1:20:29

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

Steve Yegge's Stanford seminar on GROK, Google's internal large-scale, cross-language source code analysis system. It covers how the system helps with code search and understanding across Google's huge codebase.

On Hacker News

HN refers to it as the main public description of Google's internal code analysis tooling, and as a precursor of ideas like LSP.

Recommended by 3 HN people across 4 months · HN mentions 2013–2024

Topics

Search by tags

What people said

dunk010 · 2018-10 · Strong recommendation

Steve Yegge talking about the system he built at Google, called Grok: [VIDEO] . If we have anything half that good in the wider programming community in twenty years time, I will be very surprised.

Read the original HN comment ↗
dunk010 · 2024-02 · Recommendation

LSP is basically an open(-ish) source implementation of Google’s internal tool called Grok. Grok was made by Steve Yegge, a formerly famous tech blogger. Steve Yegge uses emacs, and half his motivation was to equalise editors by moving the language processing elements to an external place that’s shareable by all. He has a great talk on it: [VIDEO] . So it’s, like, not an accident that emacs can leverage this :-D. Though I never see anyone giving him credit.

Read the original HN comment ↗
SwellJoe · 2016-07 · Recommendation

Yes, and they've open sourced part of that here (at least, I think it is related, and is also called "Code Search"): [LINK] But, their public code search was not the same as the internal thing, as far as I know. The internal beast sounds kind of awesome. Here's his talk about it from a few years ago: [VIDEO] I think the really useful thing (beyond a mere search engine that has indexed a lot of source code) is the comprehension of the "guzzintas" and "guzzouttas" of the code, more than merely a naive word search; i.e. knowing how pieces interact, so you can search for functions that work with a particular kind of object, for example, or objects that have the same properties, or code that interacts with the same API you're working with, whatever.

Read the original HN comment ↗

Sources

Video by Stanford Online, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources