The Safety Boat: Kubernetes and Rust • Hacker News Board

Re: The Safety Boat: Kubernetes and Rust

#11

Post by empath75 » Sat, May 02, 2020, 11:23 PM UTC

roblabla wrote: post #4

shock wrote: post #2

> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them with their own tradeoffs and problems. Also, many of the implementation details are tied to specific runtimes, meaning that if you have a dependency that uses one runtime over another, you’ll often be locked into that runtime choice. My understanding of how asyn…

That is the case, but it's super awkward to use. Basically, you cannot await a tokio future on an async-std runtime, or an async-std future on a tokio runtime. You can, however, have both runtimes running at the same time, and use some form of message-passing to bridge them. It's definitely easier to only deal with one runtime. Ideally, we should have some kind of abstraction to allow crates to support both runtimes…

I was looking at smol and it seems to have a good pattern for working with all the other run times.

Re: The Safety Boat: Kubernetes and Rust

#12

Post by [deleted] » Sat, May 02, 2020, 11:24 PM UTC

roblabla wrote: post #4

shock wrote: post #2

> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them with their own tradeoffs and problems. Also, many of the implementation details are tied to specific runtimes, meaning that if you have a dependency that uses one runtime over another, you’ll often be locked into that runtime choice. My understanding of how asyn…

That is the case, but it's super awkward to use. Basically, you cannot await a tokio future on an async-std runtime, or an async-std future on a tokio runtime. You can, however, have both runtimes running at the same time, and use some form of message-passing to bridge them. It's definitely easier to only deal with one runtime. Ideally, we should have some kind of abstraction to allow crates to support both runtimes…

[deleted]

Re: The Safety Boat: Kubernetes and Rust

#13

Post by ashtonkem » Sat, May 02, 2020, 11:24 PM UTC

zozbot234 wrote: post #9

It's a bit weird to see "several weeks" of effort being described as a problematic learning curve. At least the blogpost makes it clear that the effort pays out hugely but still, "several weeks" is not rocket surgery. It's not learning Haskell or category theory! ISTM that they're just running with an assumption that most devs wouldn't be professional and committed to this, which strikes me as an unwitting gatekeepin…

Learning a new framework in a familiar language might take a few weeks. A few weeks for a new language is really fast!

Re: The Safety Boat: Kubernetes and Rust

#14

Post by comex » Sat, May 02, 2020, 11:25 PM UTC

mappu wrote: post #10

shock wrote: post #2

> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them with their own tradeoffs and problems. Also, many of the implementation details are tied to specific runtimes, meaning that if you have a dependency that uses one runtime over another, you’ll often be locked into that runtime choice. My understanding of how asyn…

Going off on a tangent, but this exact problem would be a worst-case scenario for Go getting user-defined generic types instead of only the current blessed ones. t. C++ developer with a mixed std::string/QString/BSTR codebase.

But strings are not generic types...

Re: The Safety Boat: Kubernetes and Rust

#15

Post by zxcmx » Sat, May 02, 2020, 11:28 PM UTC

mappu wrote: post #10

shock wrote: post #2

> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them with their own tradeoffs and problems. Also, many of the implementation details are tied to specific runtimes, meaning that if you have a dependency that uses one runtime over another, you’ll often be locked into that runtime choice. My understanding of how asyn…

Going off on a tangent, but this exact problem would be a worst-case scenario for Go getting user-defined generic types instead of only the current blessed ones. t. C++ developer with a mixed std::string/QString/BSTR codebase.

So much this. Have seen apps where there were 4 diff string types brought by external dependencies and then like 3 or 4 more to deal with from diff Windows APIs.

Re: The Safety Boat: Kubernetes and Rust

#16

Post by steveklabnik » Sat, May 02, 2020, 11:28 PM UTC

zozbot234 wrote: post #9

It's a bit weird to see "several weeks" of effort being described as a problematic learning curve. At least the blogpost makes it clear that the effort pays out hugely but still, "several weeks" is not rocket surgery. It's not learning Haskell or category theory! ISTM that they're just running with an assumption that most devs wouldn't be professional and committed to this, which strikes me as an unwitting gatekeepin…

Go has a shorter time, and that’s the measuring stick in this area.

Re: The Safety Boat: Kubernetes and Rust

#17

Post by rvz » Sat, May 02, 2020, 11:30 PM UTC

> For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place

While the possible security benefits of Rust is interesting in software like Kubernetes, it seems like this whole blog-post is an implicit RIIR proposal for the Kubernetes ecosystem from a Microsoft software engineer which isn’t going to happen anytime soon.

> Rust has made great progress in the past year with its async story, but there are still some issues that are being worked out.

On top of that, there are still many crates that aren’t using async-await yet and most are not even 1.0, thus are not stable. I would not touch such crates if they are still immature or even unsafe.

Realistically, a Rust Kubernetes is possible but practically the effort of a production ready version is measured in years.

Re: The Safety Boat: Kubernetes and Rust

#18

Post by steveklabnik » Sat, May 02, 2020, 11:36 PM UTC

rvz wrote: post #17

> For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place While the possible security benefits of Rust is interesting in software like Kube…

Kubernetes is an ecosystem. It doesn’t need to be written in Rust for Rust components to play a part. Helm is not Kubernetes, for example, though your comment seems to blur the two. There are folks writing stuff to interact with the broader ecosystem in Rust. That’s one of the interesting bits of networked systems! You can be heterogeneous with languages more easily when the network/api is the boundary.

Re: The Safety Boat: Kubernetes and Rust

#19

Post by mappu » Sat, May 02, 2020, 11:48 PM UTC

conroy wrote: post #3

I looked into WASM / WASI last week but couldn't find an answer to this anywhere: can I write a network service in Rust and compile it to WASM / WASI? I know that wasmtime can execute a WASM module and give it access to a file system. Can that filesystem contain a socket that the WASM module can interact with?

You could speak FastCGI (or plain HTTP) over stdin/stdout, although that won't get you accept(2) semantics without some other kind of layering.

Re: The Safety Boat: Kubernetes and Rust

#20

Post by wrs » Sat, May 02, 2020, 11:48 PM UTC

steveklabnik wrote: post #16

zozbot234 wrote: post #9

It's a bit weird to see "several weeks" of effort being described as a problematic learning curve. At least the blogpost makes it clear that the effort pays out hugely but still, "several weeks" is not rocket surgery. It's not learning Haskell or category theory! ISTM that they're just running with an assumption that most devs wouldn't be professional and committed to this, which strikes me as an unwitting gatekeepin…

Go has a shorter time, and that’s the measuring stick in this area.

Go appears to have a shorter time, because you don't realize how much higher-level stuff you're just expected to do The Right Way, with no support from the language or libraries. So you're free to think you've finished learning Go, but then the actual learning begins.