A lot of important devops tools like Kubernetes and Grafana are written in golang, and it’s often handy to be able to import their code to use in your own code to automate those things.

But again, you're now a developer.

And I'm asking who are these developers using IaC tooling? It seems to me like it was made for ops.

All power to you if you take on both roles, but that's a good way to get burned out. I'm a devops person so the devs can focus on just code, and I can focus on making the best and safest infrastructure for them to run their code in.

I feel like the distinction between the two is fairly contrived these days. I'm an SRE, and we're constantly building tooling to help us better manage infrastructure, improve reliability, improve DX, etc. On the flip side, we also push a lot of the responsibility for infrastructure management to our devs: we maintain the modules and IaC pipelines, and the developers hook up the building blocks they need. It can actually help avoid burnout because our team doesn't become a bottleneck for infrastructure provisioning.

Say what you want about IaC in Go or other programming languages, but it can definitely help strengthen the whole "developers own their infrastructure" since they don't have to learn an additional language syntax.

Those developers are working on “Internal Development Platforms” and building their own abstractions on top of tools like Kubernetes and Grafana to simplify things for developers. This page explains it pretty well: https://internaldeveloperplatform.org/what-is-an-internal-de...

A big benefit is the compiler catches bugs so you don’t have to wait around for your Python program to crash at runtime. Also, if the type system is more “legit” then you can skip a ton of defensive parsing of inputs.

Could be more about developers who know Golang and Rust wanting to deploy their apps (no need to pigeonhole anyone into just dev or just ops)

I don't really see a distinction between developer and ops person in this context. The whole point of all of these tools is to make infrastructure into code. Go isn't the choice I would have made but it's fine.

I've written a bunch of k8s operators in go (and rust more recently). That's how basically everyone working with k8s does once you reach a certain level of complexity.

I don't really understand, in fact, why you'd use yoke instead of just writing an operator with kubebuilder or kube-rs.

Supposedly it's a package manager as well, so if there's a package, you'd be able to use it without writing any code.

Writing your own operator is a lot of complexity when what you want to do is deploy a package.

Via Yoke's AirTrafficController, it's easy to define a package as a CRD and its implementation (a program that takes the CR and outputs the desired underlying resources) and the AirTrafficController takes care of the rest.

You no longer need to think about reconciler loops, figuring out any orphaned state, etc.

Being a developer is not necessarily a life-long goal of ops people. I like playing with all the toys in the toybox - sometimes I need to write code to make things play the way I want. I went to school to become a programmer, and discovered that while I enjoyed programming for myself, I hated doing it for others -- otoh, I had been working as an ops guy to pay beer money, and found that it was a lot more aligned with my interests.

Most of these tools though, are written by engineers who don't want to understand the tools they were given, and want to write their own. Even the vaunted pulumi's 'aws-native' package is just built on top of cloud control which is built on top of cloudformation which is often cited as the reason terraform (which pulumi is based on top of) was created: "eww, I don't like that tool".

Which is all to say - people write code because they have a problem - engineering, operational, it doesn't matter. Assuming an ops person wants to become a developer is akin to assuming all developers want to become managers, and that all managers want to become TV stars. The logic presumes a viewpoint that simply isn't true.