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

81–90 of 102 posts

Re: The Safety Boat: Kubernetes and Rust

#81

Post by lmm »

nindalf wrote: post #63
lmm wrote: post #57

Earlier quoted context omitted.

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.

In practice you have fearless concurrency in every other ML language I know, because they're all immutable-first. It's true that if you wrote some code that mutated data then it wouldn't be concurrency-safe, but why would you do that?

Re: The Safety Boat: Kubernetes and Rust

#82

Post by [deleted] »

dnautics wrote: post #49
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.

Agreed. Worked with a senior who "learned go in a week" then faffed around for months (to prod! because he had the implicit trust of management because he was "a genius") deploying broken software with tons of concurrency bugs because he didn't know how to manage shared state.

[deleted]

Re: The Safety Boat: Kubernetes and Rust

#83

Post by acdha »

monkpit wrote: post #38
acdha wrote: post #31

Earlier quoted context omitted.

Depends on your definition of average: I found that to be the case with significant programming experience with traditional languages (notably not something like Haskell) so I think it’s plausible since the compiler, editor, and documentation are rather above average for newcomers. In particular, Cargo providing a lot of easy tools and the compiler providing really helpful error messages seemed to be useful for the t…

And your definition of “proficient”!

Yes, I’m using it in the sense of “can successfully develop a program which does the job” with the assumption that it’ll still take more time to do it quickly, use more advanced techniques, etc.

Re: The Safety Boat: Kubernetes and Rust

#84

Post by amrx101 »

steveklabnik wrote: post #28
Thaxll wrote: post #26

I don't believe for one second that it takes just a couple of weeks to an average SE to be proficient in Rust.

It really depends on so many factors it’s extremely hard to tell. We’ve brought folks at Cloudflare up to speed roughly that fast. “average” and “proficient” are both very variable in that statement, imho.

For me it was 3 to 4 months, I had switched from Golang to Rust. Its been 8 months now and I believe that I have hang of things now.

Re: The Safety Boat: Kubernetes and Rust

#86

Post by xrd »

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…

Does anyone here have any experience using Kotlin and can compare concurrency (with coroutines) to either Go or Rust? When I was doing more Java I really liked the approach Kotlin took with concurrency, but reading the comments here I'm sure I didn't understand the issues at the depth that is needed.

Re: The Safety Boat: Kubernetes and Rust

#87

Post by e12e »

steveklabnik wrote: post #39
sitkack wrote: post #36

Earlier quoted context omitted.

They started with >1 Klabnik units and every person you bring up, it creates a larger pool of folks to lean on for support.

I can’t take credit here, while I am around to answer questions, getting folks going is not my job. It is true that we have a chat room with a bunch of folks, of which I’m part.

I wouldn't discount what gp is saying though - having an (or a few) experts on hand from the start, can help training the first new convert "the right way" and they can then mentor the next one and so on.

Even just by being availabletto answer questions or help with code review. Doing some pair programming sessions would probably be useful too.

Re: The Safety Boat: Kubernetes and Rust

#88

Post by kyllo »

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.

I have learned both and agree with this statement. I think that Rust is harder to learn if you've only worked with high-level, GC languages, and don't have a background doing lower-level programming in C/C++/Obj-C, as well as some experience with functional languages.

Going from something like Java or Python to Rust, one would have a lot to learn.

Re: The Safety Boat: Kubernetes and Rust

#89

Post by jononor »

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?

Very curious as to why you would want to do that? If you want a network service, WASM does not seem to help with much, only complicate things?

Re: The Safety Boat: Kubernetes and Rust

#90

Post by Rusky »

sa46 wrote: post #59
Rusky wrote: post #47

Earlier quoted context omitted.

Data races are a kind of race condition, no?

I wasn't sure. After a bit of research, this seems to be a debate [1]. Using the common definitions, it's possible to have a data race that doesn't cause a race condition. [2] It's also possible to have a race condition without a data race. [1] https://en.wikipedia.org/wiki/Race_condition#Data_race [2] https://blog.regehr.org/archives/490

I would argue that "a data race that doesn't cause a race condition" is still, itself, a tiny race condition- just a contained one.

But you're right, this is just choice of terminology. :)

Post reply on HN