Writing a Kubernetes CRD Controller in Rust

In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines.

I agree with your overall point, and I think the advantages of Go are especially relevant in a team setting: Go's categorical aversion to complexity makes it much more difficult to write code that someone else will not understand, where Rust projects can become relatively impenetrable when they wade too far into getting "clever" with the more esoteric aspects of the type system.

Also the learning curve is real: you can take a Javascript developer and get them writing Go code in a couple of weeks. If you hire someone who's not experienced with Rust for a Rust project, you may be paying them for months just to get up to speed.

Don't get me wrong, I'm a huge fan of Rust and use it for almost all of my personal projects currently. But I think the idea that Rust can become the main programming language in all settings comes from a place of heavy bias. Rust is definitely on one extreme when it comes to complexity, and it's a more relevant trade-off for some use-cases than others.

aside - I know it's a minority opinion, but I actually think that Swift is a sweet-spot language in terms being simple to program in like Python (by aggressively obviating away low-level details), but giving you many of the powerful tools for correctness which Rust has, like algebraic types. It's a shame that it's painful to use in all but a few "blessed" applications.

Certain languages give you better tools than others in terms of reaching a good design. Go for instance puts you in a bit of a "jail" in terms of complexity which prevents you from going too far off the rails. Rust uses a strict compiler to categorically prevent whole classes of issues. So yes in some sense bad code is a "people problem" but the right tools can go a long way to mitigate it.

> Rust may be faster to read, but you can hit some very rough patch and serious head scratchers.

I think this is where Rust's type system can often be a double-edged sword. I have run into more than a few libraries which try to make things "simple" to use by leveraging traits solve problems in a somewhat magical way, but in my experience this often makes it very difficult to trace what's actually going on. I find that Rust code is not all that self documenting, and it relies heavily on documentation in order to be understandable. And quite a few libraries are strong on per-item, per-function documentation but there's a gap in terms of high-level docs explaining the intended use of the library.

https://olm.operatorframework.io/docs/

I think it depends on your domain. If you are working in a mission-critical space where every bit of static analysis saves hours or days of testing, then yeah, the more static analysis the better. If you’re building web systems software (things like Kubernetes) or even ordinary application software, then you get benefit from a little static analysis, but returns quickly diminish beyond a certain point. I think Go hits the sweet spot and Rust is generally excessive (development is slowed down much more than necessary). Swift might also hit that same sweet spot; I haven’t used it much. I have heard that it has some maturing to do before it’s ready for more than Apple GUI apps, but that might be dated information.

I think people over-index on abstraction, especially in a professional setting. I think humans have a harder time understanding abstractions than they do in dealing with concrete problems, and I think Rust (and many other languages) encourage us toward the most abstract code we can conceive of whether or not that abstraction is actually necessary. And not only are people bad at understanding abstractions, but making good abstractions is a skill, and I’ve seen way too many bad abstractions created when no abstractions are necessary at all. On the other hand, sometimes abstraction really is necessary or helpful (and contrary to Go’s critics, these cases are not to elide error handling boilerplate or to facilitate generic map functions or other “hyper-localized-abstractions”) and in these cases Go can be quite painful.

> 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.

My opinion is that using Python these days is painting yourself into a corner. Developers need more rails to keep them from writing shitty code and Mypy isn’t yet mature enough (and its pace of development seems glacial). Further the package management is still worst-in-class. I’ve never worked on a Python project that didn’t hit some major performance bottleneck that the Go/.Net/Java tier of languages wouldn’t have struggled with at all, and unlike that tier of languages, Python leaves you with no better options. Async makes a lot of applications faster, but it also allows for some pernicious bugs (“Guess Who Is Blocking The Event Loop And Bringing The Whole Application Down!” is not a fun game to play even with Python’s tooling). It’s particularly unpleasant if you don’t have a type checker because you’ll find yourself forgetting “await” a lot even in the kind of code that you would think is so simple that it doesn’t need tests. Mostly I think we have better options these days—my go-to is Go (pun unintended) but I’ve heard good things about TypeScript as well. If you really need Python for some data science stuff or something else, I would try to contain that bit as much as possible by making it its own tiny microservice or calling into it as a sub process call or similar. I would not write more than necessary in Python.