41–50 of 102 posts
> 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".
I don't believe for one second that it takes just a couple of weeks to an average SE to be proficient in Rust.
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?
Conceivably you could compile all of the CPython runtime into WASM, just that you’d be left with a big binary that gets passed around all the time over the wire.
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…
> AFAIK this is not currently done. That's correct; we're still working on these abstractions. It's the end goal that most folks have in mind, though.
I don't believe for one second that it takes just a couple of weeks to an average SE to be proficient in Rust.
> 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".
Earlier quoted context omitted.
> AFAIK this is not currently done. That's correct; we're still working on these abstractions. It's the end goal that most folks have in mind, though.
Can you explain and/or link to the issues? I thought Futures were the abstraction that lets you choose a runtime?
Other major abstractions that are missing so far include async versions of the Read and Write traits, a Stream trait for the async equivalent of the Iterator trait, and perhaps a way to spawn new tasks.
This series of interviews covers these in more depth: http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...
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.
> 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".