One of my pet ideas is a new programmer's editor that uses proportionally as much compute resources as Emacs did in the late-80s. An amount of computing that would show up as a major line item on your department's timesharing bill.
1000 cores costs around $50/hr, so if it boosted my productivity measurably it'd be worth it. Searching all public github code for strings matching around my cursor seems like the sort of thing these 1000 cores should be doing.
I have a similar idea where the cores are put to work optimizing the produced binaries (profile-guided optimization, genetic algorithms, SAT solvers/theorem proving, etc). You could of course also do static analysis and all forms of testing (generative, property-based, unit, integration, performance, etc.).
Permission to "view and fork" is not the same as permission to copy and paste into a proprietary software product (i.e. this may not be legit for use by "enterprise" developers)
Interesting idea, would definitely make you increase the efficiency of your time at the editor if it costs you $50/hour! But you don't need 1000 cores to fire off a bunch of search requests. Network calls are generally IO bound so even one or two cores can handle lots of requests.
Some napkin math - as of late 2013, GitHub's main Elasticsearch cluster had ~128 shards of ~120 GB [1]. Obviously they have more data now, and it's not clear whether the number of shards includes replicas, but at current EC2 on-demand prices[2]:
A hybrid multi-layer cache system would likely be more cost effective and still perform nearly as well as dedicated RAM (depending on how the data is structured/sharded/queried).
1000 cores costs around $50/hr, so if it boosted my productivity measurably it'd be worth it. Searching all public github code for strings matching around my cursor seems like the sort of thing these 1000 cores should be doing.