Commenters discuss the viability of using serverless functions for distributed ray tracing, with some praising the innovation while others question the cost efficiency compared to traditional GPUs. The creators clarify that the project is an exploration rather than a production-ready solution and highlight the flexibility of their platform.
12 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4StanfordSNR
gg
C++2018–2025
StanfordSNR / gg
gg
The Stanford Builder
20Distinct people
26Mentions
3Explicit recommenders
988GitHub stars
What to know before exploring
What it is
The Stanford Builder
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Oh yes! I was thinking about the V8 isolate flavor of stateless functions (Cloudflare, Fastly, etc). I had forgotten about the containerized Linux microVM stateless functions…
conradev used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2018-03-12 19:12:19 UTC to 2025-06-20 21:19:18 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
26 sourcesCOconradev·Jun 20, 2025Recommendation phrase
Oh yes! I was thinking about the V8 isolate flavor of stateless functions (Cloudflare, Fastly, etc). I had forgotten about the containerized Linux microVM stateless functions (Lambda, Cloud Run, etc). They have everything, and my favorite use is https://github.com/stanfordsnr/gg
Funnily, enough, the V8 isolates support stdio via WASM now
In What would a Kubernetes 2.0 look likeYou can already do this anyway…
https://github.com/StanfordSNR/gg
In We are still early with the cloudBut the cloud can and will be a fundamental part of the new developer tools.
Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used https://modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews: https://twitter.com/jonobelotti_IO/status/158291976221638656...
This cost me about 5 cents.
Developer environments and workflows built around the idea that you won't compile and run code on your own device can do wild things at the press of an Iphone app button.
U.C Berkeley has called part of this vision 'serverless for all computation', https://kappa.cs.berkeley.edu/.
edit: Another user also pointed to Stanford's 'gg': https://github.com/StanfordSNR/gg.
In We are still early with the cloudSomewhat related: https://github.com/StanfordSNR/gg
In Outrun: Execute local command using processing power of another Linux machineRunning it locally will always be faster as long as your machine is not a bottleneck (#cores, ram, ...). I think the use-case for distcc et al is to enable less-powerful machines to run builds faster by levering other machines. That’s exactly what we use it for at work. Our developers have not-so-powerful laptops and with distcc/icecc they can utilize the power of our build agents in the server room.
Also interesting to read: https://github.com/StanfordSNR/gg
In Distcc – distribute builds across multiple machines simultaneously (2006)I just ported the continuous build for https://www.oilshell.org/ to sr.ht for this reason:
http://www.oilshell.org/blog/2020/11/fixes-and-updates.html#...
A contributor added .travis.yml about 3 years ago, before I had ever used it. But I've been around the block enough to know that getting stuff for free is temporary. (And to be fair, I did like Travis CI free service a lot better than I thought I would.)
So when I needed to enhance the continuous build back in January, I did it with a PORTABLE SHELL SCRIPT, NOT with yaml. Both Travis CI and sr.ht provide Linux VMs, which are easily operated with a shell script.
The script called "Toil" does the following:
1. Configures which steps are run in which build tasks (both Travis CI and sr.ht can run multiple tasks in parallel for each commit)
2. Logs each step, times it, summarizes failure/
Read the rest
success
3. Archives/compresses the logs
3. Publishes the result to my own domain, which is A LOT FASTER than the Travis CI dashboard. (sr.ht is very fast too; it has a great web design.)
This ended up working great, so I have multiple CI services running the same jobs, and publishing to the same place: http://travis-ci.oilshell.org/
(I plan to create srht.oilshell.org for security reasons; it isn't ideal that both services have a key to publish to the same domain.)
----
I think this is the future of the Oil project: shell scripts to enable portability across clouds. If you want to be fancy, it's a distributed or decentralized shell.
This is natural because shell already coordinates processes on a single machine.
- A distributed shell coordinates processes across multiple machines (under the same domain of trust)
- A decentralized one does so across domains of trust (across clouds)
-----
Really great work in this direction is gg:
https://buttondown.email/nelhage/archive/papers-i-love-gg/ comments: https://lobste.rs/s/virbxa/papers_i_love_gg
which is a tool that runs distributed programs across multiple FaaS providers like Amazon Lambda, Google Cloud Functions, etc.
https://github.com/StanfordSNR/gg
My "toil" script is a lot more basic, but an analogous idea. I would like to create a slightly tighter but improved abstraction that runs on multiple cloud services. Notes on gg here:
https://github.com/oilshell/oil/wiki/Distributed-Shell
If anyone wants to help, get in touch! If you are pissed off about Travis then you might want this :) I think these kinds of multi-cloud setups are inevitable given the incentives and resources of each party, and they already exist (probably in a pretty ugly/fragile form).
In addition to improved local compilation, the constraint space for compiler design is also changed by cloud compilation. Distributed deterministic compilation like [1] would permit community-level caching. Distribution reduces the importance of peak computes - if prompt compilation requires a hundred cores, that could be ok.
Community caching reduces the importance of worst-case performance - if some rich type analysis of a standard library takes days, that might be tolerable if it only needs to happen once. If optimization decisions can become a discrete things-on-the-side, like current execution traces for jit, then there's a new opportunity for human-compiler collaboration - "lay out the data in memory like so, when the cpu cache has this shape". I'm looking forward to the ferment of hobby languages starting to explore this new sp
Read the rest
ace. What would you do differently in designing a language, if the language community was served by a single giant instance of a compiler? How might that change the economics of language development? PLAAS?
[1] https://github.com/StanfordSNR/gg Sort of checksums-and-argument-lists to make gcc deterministic, as for a cache, but farmed out so `make -j100` runs on amazon Lambda.
https://github.com/StanfordSNR/gg - should be almost the same as the GCC/LLVM thunk extractor. You have to pay for the borrow checker, but LLVM IR optimization passes should be the same complexity.
In Linux kernel in-tree Rust supportGitHub repo: https://github.com/StanfordSNR/gg
Intro article in packt: https://hub.packtpub.com/hello-gg-a-new-os-framework-to-exec...
> The functional approach and fine-grained dependency management of gg give significant performance benefits when compiling large programs from a cold start.
In case of Inkscape, when running “cold” on AWS Lambda, gg was nearly 5x faster than an existing icecc system, running on a 48-core or 384-core cluster of running VMs.
In From Laptop to Lambda: Outsourcing Everyday Jobs to Transient ContainersCompile on AWS lambda when using a slow local machine
4 points · Open discussion> uses a sophisticated caching system to avoid needlessly rebuilding artifacts
Reminded me of the Stanford Builder gg[1], which does highly parallel gcc compilation on aws lambda. make -j2000.
So with a zig cc drop-in, you might get highly-parallel cross-compilation?
Though the two caching systems might be a bit redundant.
[1] https://github.com/StanfordSNR/gg
In Zig cc: A drop-in replacement for GCC/ClangGg: Outsourcing Everyday Jobs to Thousands of Transient Functional Containers
1 points · Open discussionhttps://github.com/StanfordSNR/gg can do builds in the cloud. Their USENIX talk is really interesting
In Hacking on Clang is surprisingly easyShowing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.