> The fact that I couldn't point to one page on the docs that shows the tl;dr or the what problem is this solving Here's what the very first page of our docume

> The fact that I couldn't point to one page on the docs that shows the tl;dr or the what problem is this solving Here's what the very first page of our documentation says (https://docs.dagger.io https://docs.dagger.io). I'd love suggestions for making it more clear. Welcome to Dagger, a programmable tool that lets you replace your software project's artisanal scripts with a modern API and cross-language scripting engine. [...] Dagger may be a good fit if you are... - Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful. - A platform engineer writing custom tooling, with the goal of unifying application delivery across organizational silos. - A cloud-native developer advocate or solutions engineer, looking to demonstrate a complex integration on short notice. Benefits to development teams: - Reduce complexity: Even complex builds can be expressed as a few simple functions. - No more "push and pray": Everything CI can do, your local dev environment can do too. - Native language benefits: Use the same programming language to develop your application and its delivery tooling. - Easy onboarding of new developers: If you can build, test and deploy, they can too. - Caching by default: Dagger caches everything. Expect 2x to 10x speed-ups. - Cross-team collaboration: Reuse another team's workflows without learning their stack. Benefits to platform teams: - Reduce CI lock-in: Dagger functions run on all major CI platforms - no proprietary DSL needed. - Eliminate bottlenecks: Let application teams write their own functions. Enable standardization by providing them a library of reusable components. - Save time and money with faster CI runs: CI pipelines that are "Daggerized" typically run 2x to 10x faster, thanks to caching and concurrency. This means developers waste less time waiting for CI, and you spend less money on CI compute. - Benefit from a viable platform strategy: Development teams need flexibility, and you need control. Dagger gives you a way to reconcile the two, in an incremental way that leverages the stack you already have. > https://docs.dagger.io/quickstart/562821/hello https://docs.dagger.io/quickstart/562821/hello just emits "Hello, world!" which is fantastic if you're writing a programming language but less helpful if you're trying to replace a CI/CD pipeline We went back and forth on this. On the one hand, starting with "hello world" makes it plain that Dagger Functions are "just functions", and then gradually introduces more concepts, such as a native `Container` and `Directory` type. On the other hand, you're right that "hello world" is not useful on its own, so you need to read through more pages before a realistic example. Note that this criticism applies equally to all "hello world" examples everywhere. In any case, this is a valid criticism and I'm tempted to try going straight to a build function as you requested. > Related to that, I was going to say "try incorporating some of the dagger that builds dagger" but while digging up an example, it seems that dagger doesn't make use of the functions yet <https://github.com/dagger/dagger/tree/v0.10.2/ci#readme https://github.com/dagger/dagger/tree/v0.10.2/ci#readme> which is made worse by the perpetual reference to them as their internal codename of Zenith. So, even if it's not invoked by CI yet, pointing to a WIP PR or branch or something to give folks who have CI/CD problems in their head something concrete to map into how GHA or GitLabCI or Jenkins or something would go a long way You are absolutely right, we have started porting over our CI to functions, but have not finished yet.