vito

Happy to hear from a Concourser! The transition to Dagger isn't fully defined yet, but we're getting there. It's taken a lot of time to find the right primitives and build a solid engine for maximal caching, but we're excited about what we're launching soon. It covers the middle parts of a Concourse pipeline really well (build + test, CI checks) but we still need to solve the beginning/end (monitoring inputs, shipping/releasing).

What you aren't including is the chronic cost of maintaining the status quo, which is the entire reason for making the change. Sometimes making no decision costs you more than making a risky one - and if the decision is risky, you'll want to investigate it first.

During that investigation you discover things (like having to implement your own components) and try to account for how much they'll subtract from the time and energy you save. If the calculus works out, you keep going. If it doesn't, you stop. We kept going, and now we can ship complex features and optimizations to both UIs within a day or two.

The compiler will tell you if the types aren't compatible, and this is only for primitive comparable types. What `min()` implementation could you have that even does something different?

(Concourse co-creator/OSS lead here.)

Our CLI hasn't really aged well and that's something I'd like to address soon - probably going more in the direction of config files instead of flags/env vars. It'd be a lot easier to document with a proper schema. Thanks for the feedback and sorry the experience is still pretty rocky!

All it really proves is HN's tendency to tear down projects for any arbitrary reason they can find.

I'm curious to know how your flow through the docs went. We inlined "getting started" into the main page, and had the Setting Up section show "vagrant up" first, and we have warnings above sections that are not critical to know before learning Concourse itself, which then take you right to "Hello World". It's already optimized for "Concourse made easy" - but perhaps our navigation is not?

I should probably add a warning above the BOSH section though, or even the binaries section.

The trouble is, reality is complicated, regardless of whether it's documented or not. I've found that a lot of open source projects simply don't document things to give an illusion of simplicity; people just forget all the manual labor they had to do after downloading that .deb and installing it across 10 machines and maintaining those machines over time. Our docs cover BOSH as our preferred tool for clusters. If you don't want to use BOSH, just use the binaries and your own deployment tool.

We don't build .debs yet; as soon as we do other people will want .yum, and another will want Docker images, so we built the binaries that will feed into those first, which is often what I look for when kicking the tires on something anyway.