The Bash compatible syntax is just one representation of an underlying cross-language API. You can also write code in your preferred language, provided there's an SDK for it. (Currently: Python, TypeScript, Go, PHP, Java, Elixir, Rust, .NET)
But if you're talking specifically about shell or a "native" REPL in a safer language - I also want to scratch that itch. Some day I'll dust off https://github.com/vito/dash :)
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?
Yeah that's a good point. There are definite trade-offs to going for only one or the other. If there's a nice way to support both without too much maintenance overhead, that'd be my preference. There are a few popular Go libraries which support that, like https://github.com/spf13/viper - which we'll probably consider switching to as part of a general CLI overhaul.
For a long time now we've been primarily focusing on the core design, concepts, and architecture at the expense of documentation and introductory material and outreach - we've never had a dedicated technical writer, so documentation is really best-effort. Now that the dust is settling on our roadmap I feel a lot more confident in increasing our focus on onboarding, operability, and developer/user experience in this coming year. :)
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!
Funnily enough if you leave the tab in the background, the events queue up and when you tab back there are a bunch of cards bouncing around at once: http://i.imgur.com/dNObRGb.png
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.
Concourse just talks to Garden, it's up to the Garden backend whether or not it actually does containerization. So on Windows it just does the world's worst containerization (cd'ing into a directory), though it at least guarantees that the processes all die.
You pretty much got it right. That page is still a bit rough; we'll give it some TLC soon.
Workers are just machines running a container management daemon (much like a Docker daemon) and a volume manager (a custom daemon for managing caches and efficient artifact propagation between containers). Not sure how you got to Cloud Foundry though, it's not really related. Garden lives in the Cloud Foundry GitHub organization, as it's also used by Cloud Foundry, but you don't need to know anything about CF to use Concourse.
Concourse supports Linux, Windows, and OS X. You can see an example of this here:
That command would just be `fly` or something else coming from Concourse. To me it makes more sense for the entry into the system to be safeguarded with validation, and then possibly bring your own filesystem-based configuration management system that goes through that same front door, building on trusted tools from Concourse itself. Mucking with files on disk that directly affect a live system (shipping production code!) seems like a recipe for disaster.
We run browser-based tests in our own pipeline (I'm on the Concourse team). We just use `xvfb-run` around our test script. We also build VirtualBox images using a systemd-based Garden backend running on a dedicated server (not a VM).
I find these approaches better than risking test pollution, especially when it comes to building VMs and spinning up desktop apps.
The main value we get from it is having a nice Go API and not having to overhaul everything using Garden every time some shiny new container tech comes out.
Yup (is). You'd just run `concourse web` and then `concourse worker` on the same machine. If all you have is a Mac Mini there's one gotcha, though: currently none of the resources will run on OS X, as they're built as Docker images. So you'll still need at least one Linux worker somewhere.
I think the next step from us may be to start building Vagrant boxes that just spin up a worker, parameterized with credentials to register with a Concourse `web` instance. That way you can run Concourse on OS X for iOS testing/etc. and still have all your resources and Linux containerization when you need it via a tiny local VM.
But if you're talking specifically about shell or a "native" REPL in a safer language - I also want to scratch that itch. Some day I'll dust off https://github.com/vito/dash :)