Live data from Hacker News

Portable and Interoperable Async Rust

ncameron.org

1–10 of 71 posts

Re: Portable and Interoperable Async Rust

#4

Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?

Go is a very different language than rust. Go has automatic memory management & garbage collection. This automatically disqualifies it from being used in many scenarios that rust is designed to support, like embedded systems.

Go’s runtime model just makes stuff like this vastly simpler. Rust can’t impose the same kind of runtime model that go has.

Re: Portable and Interoperable Async Rust

#5
post #4

Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?

Go is a very different language than rust. Go has automatic memory management & garbage collection. This automatically disqualifies it from being used in many scenarios that rust is designed to support, like embedded systems. Go’s runtime model just makes stuff like this vastly simpler. Rust can’t impose the same kind of runtime model that go has.

While Go isn't designed for embedded systems, it can run on them.

TinyGo is another Go compiler intended for embedded systems. And now its officially sponsored by Google.

https://tinygo.org/docs/reference/microcontrollers/

Re: Portable and Interoperable Async Rust

#6

Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?

It's extremely challenging to make async that is usable without introducing a garbage collector or a whole lot of runtime overhead.

A better comparison would be between the Rust and C++ paths to async - C++ also spent years designing their async system, and the end result is divisive at best.

Re: Portable and Interoperable Async Rust

#7
post #5
post #4

Earlier quoted context omitted.

Go is a very different language than rust. Go has automatic memory management & garbage collection. This automatically disqualifies it from being used in many scenarios that rust is designed to support, like embedded systems. Go’s runtime model just makes stuff like this vastly simpler. Rust can’t impose the same kind of runtime model that go has.

While Go isn't designed for embedded systems, it can run on them. TinyGo is another Go compiler intended for embedded systems. And now its officially sponsored by Google. https://tinygo.org/docs/reference/microcontrollers/

TinyGo is awesome.

Re: Portable and Interoperable Async Rust

#8
On a somewhat unrelated note: What consequences did the Rust mod team resignation lead to? The last thing I heard was the blog post: https://blog.rust-lang.org/inside-rust/2021/11/25/in-respons...

But I haven't seen any public discussions on the future of Rust governance, how to make the core team accountable, or other consequences since.

Re: Portable and Interoperable Async Rust

#10

Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?

The saddest part of learning Rust was discovering that there are no goroutines and that async works like Python and everything needs to be written twice to support both async and blocking styles. Like it was 20 years ago all over again and I'm still trying to mix Twisted and stdlib Python. I got all excited thinking of how the borrow checker would work so well with coroutines, only to discover it got nobbled because Rust's use cases include embedded systems and no runtime (like in a golang 9MB hello_world.exe). I have no idea if Rust could evolve its concurrent programming support to something better than Go's, even if it did drop some of its shackles.
Post reply on HN