edvald

I can recommend dub techno for coding, works a treat for me at least. Nice and steady, relatively fast tempo but not too aggressive or intrusive. And crucially, no lyrics, which I find distracting when coding or writing.

Thanks for flagging! We'll fix that.

No definitely not, this is just for WIP branches. I usually don’t even push these, unless it’s something big that I need early review on.

One trick I employ for myself is:

  throw "TODO" // <comment with some additional context to remember>

Substitute for your language's syntax of course.

I find this especially handy when writing test specs, but it's also handy when creating new functions etc. For tests I lay out the test descriptions with just this one line in the function body. For new functions/methods I can define the function and its return type (assuming a type-safe language) which makes the code using it compile, but leaves the implementation TBD.

The placeholders are then implicitly flagged in test runs and easily found. Basically my text search results for 'throw "TODO"' become my TODO list.

OP here, so I'm of course biased but I'm actually also a fan of the Tilt team :)

Overall, Garden has a broader focus, an added emphasis on testing, as well as capturing all the relationships between your services. The goal is for you to be able to use the same tools and workflows across development and testing/CI, and (as of our new release) the same environment as well.

For an apples-to-apples with Tilt, Garden does a lot of the same things when developing locally, but Garden additionally covers unit+integ testing and allows you to define all your bootstrapping workflows (e.g. migrations etc.). Tilt has a really good UI for local builds+deploys, but you wouldn't currently use it to run tests, or work with remote clusters.

The key thing we're adding in this release is not just an ability to work with remote clusters, but to do it _really fast_. Even faster than locally sometimes, because you can allocate more resources and share build+test caches with your team and your CI.

Plus—and this is more important for the long-run—Garden is designed to be pluggable to work with more platforms than Kubernetes. So you'll be able to use serverless, custom/legacy platforms etc. with the same tools when we release the plugin SDK later this summer.

Hope that's useful.

I actually worked one summer doing exactly that, back when I was 15. Without any doubt, the absolute worst job I've had. I'd previously worked summers in my uncle's _fresh_ fish processing and that was totally fine. The stuff we were racking and drying at that other place though was anything but fresh. Ugh, the textures, the smells, it's all coming back to me... Kinda hard to reconcile that as a delicacy.

It sure was formative though. All uphill from there, haha.

It's always a balancing act. Make the abstractions really stiff, and you can optimize heavily for that context. Too loose, and it becomes opaque and hard to reason about. And messy.

That's why we spent so much time working out the plugin mechanism, and figuring out what's native to the core framework. Terraform, for example, nails the infrastructure stuff quite well and strikes a good balance there, so we used that as a reference. But we added specific primitives for developing the application layer, and made that pluggable through a similar approach. Providers figure out the _how_, but the relationships in the graph are predictable.

Case in point, we now have a handful of different ways to deploy code. There's a Helm module type, which is very flexible but carries all the complexity and manual effort you need to make Helm charts. On the other side there's OpenFaaS, which is very constrained in features, but super easy to get going. So you can pick and choose depending on the level of abstraction you need.

Plus you'll soon be able to make your own, so you can tailor the abstractions to your needs, but keep the consistency of a single core dev tool.

I'm a fan of OpenFaaS. It's a simple, smart design, and Alex has done great work in building a community around it. We found it easy to adopt and support for garden.io, and it fits very neatly into the Kubernetes ecosystem.

I agree to some extent. One of the key value propositions of Kubernetes is indeed in its abstractions, which are mostly quite good. And I really like its declarative approach.

However, I've been dealing with its ins and outs for a while now, partly because I'm developing tooling around it, and I've found there are already a lot of idiosyncrasies in there. Some APIs have very frustrating flaws, and most annoying of all is how tightly some core functionality is coupled to kubectl. A remarkable amount of logic is embedded in the CLI, as opposed to the API layer, and if you really get in the weeds you're likely to start pulling your hair.

Which is to say, even once you get through the learning curve, you may still find yourself struggling with it as you use it. Sometimes when you declare your intent, you find that it just doesn't work, and it can take a while to figure out why. Before you know it, you're using various operators that are meant to mask some of the deficiencies in the core orchestrator, and by extension you're outside of the core abstractions. And don't get me started on Istio... (but that's a tangent).

Anyhow. If you're not trying to do anything unusual, it's a good orchestrator. Not perfect, and for sure heavy, but a good choice for a lot of use cases.