Potentially going (back) to Rust for the control-plane?

[shaneutt]

When we started this project the control-plane was originally written in Rust using kube-rs. We made the move to Go with controller-runtime as this helped us move faster and iterate faster at the time due to the more mature ecosystem there for building operators/controllers.

Fast forward to now and there are some reasons we may want to re-consider:

• the maturity of the kube-rs ecosystem has grown significantly since we last evaluated it, including improved status support
• several of the contributors to this project have expressed a general preference for programming in Rust over Golang
• there are higher level projects on top of kube-rs available now: https://github.com/olix0r/kubert

In a more general sense as well: @astoycos and I attended a Kubecon talk by @kflynn where he responded to a question about why they are doing controllers in Rust instead of Go with (I am paraphrasing) something along the lines of "There are several reasons, but if nothing else because having more languages as options for Kubernetes is better for the overall health of the community" to loud applause from Andrew any myself. This project is also uniquely poised to help continue to grow the Rust part of the ecosystem as we're the first Rust project, and the first use of kube-rs in upstream Kubernetes.

So the benefits I see from switching to Rust are:

• our efforts will likely help grow the maturity and adoption of Rust for Kubernetes and be in support of kube-rs
• more unified language, tooling and build systems for the project
• we will spend more time coding in Rust (this may not be considered a benefit for some)
• we want to rewrite the control plane anyway

On the flip side there are costs we might anticipate by switching:

1. it will take longer to build and maintain the control-plane (at least at first) as the ecosystem is less mature
2. it may reduce the amount of new contributor engagements that we get, as Go is currently a more common language
3. this will reduce our impact as a reference implementation for Gateway API, which has been one of our stated project goals.

Some food for thought, everyone actively contributing or even just generally interested in the project please feel free to respond to the poll, and then in general if you wanna leave some comments with your thoughts that'd be great.

[mlavacca]

A strong YES from my side, for all the reasons in the pros, plus some thoughts related to the listed cons:

1. it will take longer to build and maintain the control-plane (at least at first) as the ecosystem is less mature

I agree, but given the alpha stage that Blixt is still in, I think we can take this steering pretty light-hearted, as Blixt is not mature as well, and our maturity can grow along with the Rust ecosystem.

3. this will reduce our impact as a reference implementation for Gateway API, which has been one of our stated project goals.

I always saw "being a reference implementation for Gateway API" as "being a tool implementors can test their L4 implementation against", and not "being a bunch of code to take inspiration from". if the latter analogy is the one we have in mind, then I agree it's a limitation, otherwise, the language we use should not matter much in my opinion.

[shaneutt]

So "being code to take inspiration from" was in fact a big part of the goal when we said reference API, however I'm starting to even think given how this project has organically grown it would be better to drop that goal anyway and let some other repository (maybe even the main one) house some kind of reference implementation based on Go/ControllerRuntime.

[kflynn]

It's hardly a bad thing to have references in multiple languages...

[shaneutt]

It's hardly a bad thing to have references in multiple languages...

I would be shocked of us implementing a Gateway API control plane in Rust didn't have the effect of encouraging more Gateway API implementations in Rust in the long run.

[astoycos]

+1 From my side I have tried writing Rust based k8s controllers here and in the bpfman and had many struggles, so doing it here with a community of operator experts would be great!

[shaneutt]

We've let this soak for a little while, and it seems like the majority of community members and people interested in the project are in favor. We'll give this a week more to soak: if anyone has any strong arguments against this change that they would like to articulate, please let us know in the comments here so we can consider them. Otherwise we'll probably do a zoom next week to start doing to planning and creating some issues for the change.

[shaneutt]

We had a sync today and we've decided as there's been no vocal outcry, we are going to start the project of rewriting the control-plane in Rust, which @aryan9600 has graciously agreed to lead. We will consider this discussion closed now and we'll start creating the milestone and issues to track the effort. Thank you everyone for your input!