Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Safety Boat: Kubernetes and Rust

msrc-blog.microsoft.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: The Safety Boat: Kubernetes and Rust

#71

Post by wwright »

pjmlp wrote: post #67
Klasiaster wrote: post #65

Good article but it somehow suggests that because there is no garbage collection you would need to fight the borrow checker. This is not fully true because you could put your data in a Box (so that it is stored on heap instead of the function's stack) and you can wrap it in a mutex with reference counting (Arc+Mutex or Rc+RefCell), which roughly gives you what garbage collection does. Also cloning can avoid solving t…

It doesn't give the productivity that GC allows for writing GUI code and UI designers. Imagine having JetPack Composer, SwiftUI, Qt designer, or WPF/UWP Blend in Rust.

Qt is actually a good example because C++ has a similar memory model to Rust (at least with respect to GC). The Qt solution was basically to give everything a “Cow” (copy on write) wrapper, and to use an event loop-based, somewhat manually-annotated GC for objects that want it.

Rust could totally do the same thing, and you could probably make it way easier to use than the mess that is Qt.

Re: The Safety Boat: Kubernetes and Rust

#72

Post by klitze »

It has a weird taste that Microsoft is preferring Rust over Golang considering that Golang is a Google thing.

Don’t get me wrong, all technical arguments are correct and rust does have advantages for cloud software. But this also comes quite handy for MS. :)

Re: The Safety Boat: Kubernetes and Rust

#73

Post by wwright »

Matthias247 wrote: post #54
roblabla wrote: post #4

Earlier quoted context omitted.

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…

> That is the case, but it's super awkward to use. That's really the case for any language where an eventloop is not part of a builtin runtime (like it e.g. is with Javascript or Dart). E.g. in C++ we also have boost asio, libuv, libevent, wagle, seastar,GUI framework eventloops in GTK, QT, etc. The thing is once you are in async land, nothing is interoperable anymore in most environments. Whether that's ideal or not…

IMO it’s more that the Rust community has fostered a culture of doing things carefully and doing them well whenever possible (I mean, it’s the language that will argue with you for hours over reference lifetimes, after all).

Re: The Safety Boat: Kubernetes and Rust

#74

Post by pjmlp »

klitze wrote: post #72

It has a weird taste that Microsoft is preferring Rust over Golang considering that Golang is a Google thing. Don’t get me wrong, all technical arguments are correct and rust does have advantages for cloud software. But this also comes quite handy for MS. :)

VSCode support for Go, and some Delve improvements, were actually developed by Microsoft.

Re: The Safety Boat: Kubernetes and Rust

#75

Post by pjmlp »

wwright wrote: post #71
pjmlp wrote: post #67

Earlier quoted context omitted.

It doesn't give the productivity that GC allows for writing GUI code and UI designers. Imagine having JetPack Composer, SwiftUI, Qt designer, or WPF/UWP Blend in Rust.

Qt is actually a good example because C++ has a similar memory model to Rust (at least with respect to GC). The Qt solution was basically to give everything a “Cow” (copy on write) wrapper, and to use an event loop-based, somewhat manually-annotated GC for objects that want it. Rust could totally do the same thing, and you could probably make it way easier to use than the mess that is Qt.

Having dealt with Gtk-rs, and their current solution being the clone! macro, I am not so sure.

Remember that not only is GUI development with proper tooling very interacting, instead of the FOSS alternatives of code-compile-check visually, there is also the whole eco-system of third parties selling component libraries, with no control how they get integrated into the component toolbox.

So whatever solution one comes up with,it needs to be more productive than forcing users to scatter Rc>, or fix their code that broke compilation, just because moving a widget on the GUI tree invalidated the borrow checker assumptions.

Re: The Safety Boat: Kubernetes and Rust

#76

Post by pjmlp »

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…

Plenty of Kubernetes stuff is actually written in Java, .NET and other languages, not necessarily Go. Thankfully.

Re: The Safety Boat: Kubernetes and Rust

#77

Post by pjmlp »

akiselev wrote: post #56
steveklabnik wrote: post #16

Earlier quoted context omitted.

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

Go is the golden standard for extracting the most value out of unexperienced computer science grads but it is not the measuring stick, not by a long shot.

Java did it first, catching up with 1996 here.

Re: The Safety Boat: Kubernetes and Rust

#78

Post by jpgvm »

gameswithgo wrote: post #69
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…

I think learning Rust will be harder than Haskell for a lot of people.

Hmm I don't think so. Haskell is so fundamentally different to imperative languages that it requires basically throwing away everything you know about programming.

To learn Rust you simply need to understand how values are kept track of by the compiler. Once you develop an intuition for this it's the same as any other modern imperative programming language.

Re: The Safety Boat: Kubernetes and Rust

#79

Post by ernado »

oconnor663 wrote: post #50
ernado wrote: post #40

> we caught a significant race condition It is a data race, not a race condition. > and which passed the race checker for Go No, it is not. https://github.com/helm/helm/pull/7820#issuecomment-60436062... There is a comment by issue author which is literally a go data race detector warning. Like "WARNING: DATA RACE".

IIUC, the point is that the code has been in prod for a year, but the race detector only just now found the bug? But I could be wrong.

It is right, race detector is not enabled by default and you should explicitly run tests with it or tell compiler to enable it - it is not compile-time, but run-time.

But still, it detects this error.

Re: The Safety Boat: Kubernetes and Rust

#80

Post by alvarelle »

ashtonkem wrote: post #13
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!

But with rust you have to re-learn the language every six weeks as it changes so fast. (/s)
Post reply on HN