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

61–70 of 102 posts

Re: The Safety Boat: Kubernetes and Rust

#61

Post by adev_ »

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.

> t. C++ developer with a mixed std::string/QString/BSTR codebase.

This has absolutely nothing to do with generics.

None of std::string or QString are generics. They are just an example of historical alternative implementations for 'reasons' ( portability/speed) that create a lesson the long term

Re: The Safety Boat: Kubernetes and Rust

#62

Post by Proven »

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…

What is rocket surgery?

Re: The Safety Boat: Kubernetes and Rust

#63

Post by nindalf »

lmm wrote: post #57
melling wrote: post #27

“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.” I’ve heard people brag that Haskell is a great language because it’s supposedly…

Yes, for much the same reasons. Pretty much any ML-family language has the same effect; just having proper sum types, polymorphism and first class functions (and not having null) goes a long way to preventing huge classes of bugs.

The critical feature enabling fearless concurrrency is Rust's borrow checker though, something that the other ML languages don't have.

Re: The Safety Boat: Kubernetes and Rust

#64

Post by slavik81 »

adev_ wrote: post #61
mappu wrote: post #10

Earlier quoted context omitted.

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.

> t. C++ developer with a mixed std::string/QString/BSTR codebase. This has absolutely nothing to do with generics. None of std::string or QString are generics. They are just an example of historical alternative implementations for 'reasons' ( portability/speed) that create a lesson the long term

It's also unavoidable. It's not like you can pass UTF-8 Go strings to UTF-16 COM interfaces. Somebody wrote code to convert a Go string to a BSTR and vice versa. You can do the exact same thing for std::string if you want.

Re: The Safety Boat: Kubernetes and Rust

#65

Post by Klasiaster »

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 the borrow-check puzzle if you don't need a shared state. Of course you would not want to pack your code with Arc+Mutex or data copying if performance matters, but it's fine for a beginner to start with when writing Rust and then learn to do the optimized borrow version a bit later when needed.

Re: The Safety Boat: Kubernetes and Rust

#67

Post by pjmlp »

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.

Re: The Safety Boat: Kubernetes and Rust

#68

Post by gas9S9zw3P9c »

wrs wrote: post #20
steveklabnik wrote: post #16

Earlier quoted context omitted.

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.

This is very true. I recently ported large portions of Go code to Rust, and while it was somewhat of a steep learning curve and a fight with the compiler, in the end I felt very comfortable that the result is correct, fast, and had good abstractions.

Go was so "easy" that I was immediately productive, but this resulted in often suboptimal and messy code that I had to refactor over and over again due to concurrency, abstraction, or performance issues.

True productivity is hard to measure.

Re: The Safety Boat: Kubernetes and Rust

#69

Post by gameswithgo »

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.

Re: The Safety Boat: Kubernetes and Rust

#70

Post by eecc »

jerf wrote: post #24
wrs wrote: post #20

Earlier quoted context omitted.

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.

Even accounting for what you say, it's a short learning curve compared to most languages. It's not like there's any programming language in the world where you just read the manual through once and, boom, instantly you know exactly how to architect a multi-person-century project right out of the gate or something.

Hmm, that’s a bit of a straw man you’re making here. No one is arguing better languages will magic complex architecture efforts, we’re talking about basic state management here... garden variety implementation details
Post reply on HN