Live data from Hacker News

Writing a Kubernetes CRD Controller in Rust

technosophos.com

41–50 of 76 posts

Re: Writing a Kubernetes CRD Controller in Rust

#41

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (…

I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).

Re: Writing a Kubernetes CRD Controller in Rust

#42

Earlier quoted context omitted.

Rust complexity is not encapsulated in libraries that parses JSON or YAML, or others. Rust complexity is embedded in the following: in order to get something to work, you effectively need to solve a puzzle. Solving the puzzle is fun and feels very good once completed, and the prize is definitely worth it when performance and safety are critical. I highly doubt that "solving the puzzle" makes sense in the context of a…

Even with respect to dealing with JSON, good luck deserializing a structure with borrowed references. People will tell you not to use borrowed references, but sometimes you’re at the mercy of a library author and even if you’re not it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields, right after you got everything working just because you can’t figure out ho…

> it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields

Some refactorings in Rust has brought back memories of refactoring struggles with highly coupled code bases, where one seemingly small change ends up requiring touching many many areas of the code.

The omniscient need to define ownership across a code base seems to make it easy to introduce high coupling, which is unavoidable unless you start using shared_ptr/RC all over the place.

Re: Writing a Kubernetes CRD Controller in Rust

#43

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (…

> Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (or rather, type safety and correctness simply aren’t nearly as important as velocity from an economic perspective).

I think this really depends on the the higher level abstraction you get to use in rust -- case in point being the original post. I'm not sure if this is a result of the rust code just being done that much later but the Rust in there is much simpler to read and understand than getting stated with a golang codebase (whether via kubebuilder, or others) outside of scaffolding your code base -- there's just less moving parts and less noise.

Golang shines when it comes to developer fungibility -- it's simpler to onboard, train, and hire go developers. It's also easier for those developers to make mistakes, but compile type typechecking will constrict the mistake "space" (more so than ruby/python/vanilla js), and performance will get a boost. If Java is the mouse trap because C/C++ were too hard, Go is a better mouse trap on almost every axis (though I think generics in Go 2 are sorely needed).

> Rust is getting better all the time—non-lexical lifetimes and rust-analyzer have provided a surprising improvement in development velocity, but Go is still in another class. Personally I think Go is the best language for developing quickly—even better than Python for non-toy projects (I say that as one with 15 years of Python experience and almost a decade of ago experience).

I agree here, though I personally favor Typescript for building quickly (at least it is for me) if you add Typescript to it. Performance is great because most simple things are not CPU bound at the API layer, ecosystem is enormous (finding value can be difficult), and it's relatively easy to deploy (though Go is easier). I largely stopped keeping track of Go once I'd written some stuff in rust, but I do still recognize it as an excellent choice for building systems quickly and with some (type) protection as opposed to other options, with easy deploys.

I'd love to get your thoughts on recent "modern" Python and it's shiny parts and warts though. I used it last year for a client and found the modern stack to still be pretty disappointing compared to what I knew was possible with server-side JS -- typing use being sort of incomplete still (mypy was a little awkward to use), async still being a little bit awkward, GIL still being a thing.

Re: Writing a Kubernetes CRD Controller in Rust

#44

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes.

You give some Go and Rust code to some team that never used either language, I can tell you right away that the Rust code will never be properly understand.

Go is easy to read and to maintain, I can't say the same for some Rust code. Go itself has been stable for years, there is no new keyword, std lib is the same, almost no changes ( beside modules ).

When you look at Rust they're adding thing much faster and it feels like C++ at times, the mental overhead to keep up with that is not trivial.

Re: Writing a Kubernetes CRD Controller in Rust

#45

Earlier quoted context omitted.

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (…

I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).

I don't think any ML languages are going to be able to qualify for best language for fast development. They are a paradigm shift for too many developers, which means you're going to pay a price getting up to speed.

Compilation time is generally not the bounding factor for development speed these days. Theoretically, compile time is zero for scripting languages so that's at least one point against weighing compile time heavily. I think the key benefit of OCaml and other ML langauges over Rust right now is actually higher kinded types, dependent types, and things in that realm of abstraction -- which you're probably not going to be using unless they're built into some library you're making use of, so the benefit is kinda moot there. Feels like the best power/weight for abstractions in codebases is the typeclass (or Traits in rust), most of the stuff above that is not great for fast development unless it's already in place.

And if we're talking about ML languages, I'm firmly in the Haskell camp because I think it has a better ecosystem (more than any research language should), an incredibly good runtime system (they've got the best native+green thread implementation I've ever seen), and fantastic abstractions for working with shared memory (when you need that). The whole "if it compiles, it works" is generally true. No need for a holy war, but if OCaml is in the race for fast development (which means that ML is in the race), then I'd pick Haskell over it to start on ecosystem/adoption, production readiness and features -- if you can manage to keep your developers from climbing the ladder of research-level abstraction.

Re: Writing a Kubernetes CRD Controller in Rust

#47

The library used in the this post has gotten much better since this post was written (in 2019) Recently the ability to do `exec` and `attach` was added. It should reach feature parity with the Go version soon once `port forward` is added. https://github.com/clux/kube-rs

Apart from that, the runtime module has also been overhauled completely since this blog post. In particular, the new `Controller`[0] adds a bunch of stuff over `Informer` to make it usable in production (merging duplicate queued events, parallel execution, delayed retries, fixed a bunch of internal race conditions, etc). We really need to make a 2020 edition of this blog post, but we do at least have an updated example controller.[1]

(Not to dunk on TechnoSophos, none of that existed back when the blog post was written.)

Disclaimer: Co-maintainer of kube-rs

[0]: https://docs.rs/kube-runtime/0.47.0/kube_runtime/controller/...

[1]: https://github.com/clux/kube-rs/blob/8611e5cdd23d4ff487fdcea...

Re: Writing a Kubernetes CRD Controller in Rust

#48
post #36

The library used in the this post has gotten much better since this post was written (in 2019) Recently the ability to do `exec` and `attach` was added. It should reach feature parity with the Go version soon once `port forward` is added. https://github.com/clux/kube-rs

Hmm! Interesting. I'm wondering if adding a test framework like kubebuilder is on the agenda. I'm not a great fan of it (kubebuilder) but the simple-to-use (in a relative term, i.e. as simple as it can get with Go) is a huge benefit. So you won't have to deploy after every build to see how your changes look like.

We don't currently support anything like Kubebuilder's envtest helper, but it is on our radar (and I finally got around to making an issue for it[0]). The rest of Kubebuilder's testing page seems to be general for Go's test framework (in which case Rust should have native equivalents).

Disclaimer: Co-maintainer of kube-rs

[0]: https://github.com/clux/kube-rs/issues/382

Re: Writing a Kubernetes CRD Controller in Rust

#49

Earlier quoted context omitted.

I agree with all of this, with one nitpick intended to self-aggrandise. You can actually nominate particular types be stored in particular etcd servers -- GKE does this to put Events into a separate etcd from everything else. However, it still has problems. Firstly, you can only define it for inbuilt types. Secondly, it's common for different objects to cross reference each other through objectRefs and the like, whic…

>"You can actually nominate particular types be stored in particular etcd servers -- GKE does this to put Events into a separate etcd from everything else." Interesting. Is this documented anywhere?

The --etcd-servers-overrides flag can do it. I could swear I'd seen a proper writeup in the Kubernetes docs, but couldn't find it again.

What I said was slightly wrong. It's not that you nominate Kinds, it's that you nominate which etcd servers get which etcd key paths. You can essentially work it out because the path structure is consistent.

Re: Writing a Kubernetes CRD Controller in Rust

#50
post #44

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes. You give some Go and Rust code to some team that never used either language, I can tell you right away that the Rust code will never be properly understand. Go is easy to read and to maintain, I can't say the same for some Rust code. Go itself has been stable for years, the…

I will take a longer on-boarding in return for better long-term code any day of the week.

I’ve been down the “developer speed above all else” rabbit hole with Python, and I don’t think it ever ended up working out meaningfully better than the “think the problem through first” approach.

Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion. Also the error handling is far inferior to the more principled approach taken by Rust/Haskell.

> ...I can tell you right away that the Rust code will never be properly understand.

I think this is an unfair characterisation: if I did this with my c#-writing coworkers, I think they’d certainly get a cursory understanding of Go quicker, but it wouldn’t take that much longer to get a grip on Rust and they’d write better and more correct code in Rust.

Post reply on HN