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

Portable and Interoperable Async Rust

ncameron.org

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Portable and Interoperable Async Rust

#41

Post by pornel »

ezekiel68 wrote: post #35

I take the opposite tack. Who, precisely is clamoring for this? Why not "let 100 flowers grow" (present condition) and allow the various solutions to mature to the point that a de facto standard emerges? The claim is made: "choosing a runtime locks you into a subset of the ecosystem," to which I answer, "So, what?" If I want to log my server events or take advantage of a protocol encoding method or compress my data -…

The portability is needed to let many runtimes grow without pains of fragmentation. Currently tokio dominates, and you either use tokio, or you lose access to a large portion of the ecosystem.

This doesn't have to be a blessed runtime in std, but could be just a set of common interfaces (basics like AsyncRead, sleep, and spawn), so that async crates don't have to directly depend on a specific runtime.

Re: Portable and Interoperable Async Rust

#42

Post by ezekiel68 »

camdenlock wrote: post #2

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?

Funny you should ask that... about 6 years ago, Mozilla released an event-handling library written in go named Heka. It made use of go's built-in goroutines and channels and what made it really cool was that it had an embedded lua interpreter so people could update lua scripts in their event processing systems to alter the behavior (such as reformatting dates, etc) without needing to re-compile the solution. It got pretty popular and you can still find YouTube tutorials on using it to this day.

Unfortunately, according to one of the lead developers, the system couldn't keep up with Mozilla's throughput and reliability requirements due to limitations of go's built-in features.[0] They announced they would re-write a new solution in c ("Hindsight") and they basically left an entire community of users high and dry due to not being able to salvage the go-based project, since it relied so heavily on the built-in features.

[0] https://heka.mozilla.narkive.com/9heQ11hz/state-and-future-o...

Re: Portable and Interoperable Async Rust

#43

Post by nojito »

skohan wrote: post #31
nojito wrote: post #22

Earlier quoted context omitted.

The rust core team is/was never accountable. Which is fine because the language work is done elsewhere thankfully.

What about the former core team member who also raised similarly-vague alarm bells about Rust's governance, and Amazon's involvement? I'm somewhat invested in Rust, and it's a bit worrying to see this from two places.

Why? The language related work takes place elsewhere.

The term “core team” is just a misnomer.

Re: Portable and Interoperable Async Rust

#44

Post by justsomeuser »

ezekiel68 wrote: post #35

I take the opposite tack. Who, precisely is clamoring for this? Why not "let 100 flowers grow" (present condition) and allow the various solutions to mature to the point that a de facto standard emerges? The claim is made: "choosing a runtime locks you into a subset of the ecosystem," to which I answer, "So, what?" If I want to log my server events or take advantage of a protocol encoding method or compress my data -…

The issue is that the async await keywords are part of the standard language but then you are forced to pick an non-standard runtime.

Your Go example is not quite comparable:

Go: (Lang, libs)

- You can mix and match any libraries.

Rust: (Lang, runtime, libs)

- Now you can only choose the libraries for your runtime. This dilutes the time investment of crate developers and the utility of Cargo crates, as you want a general async thing but it is tied to a specific runtime.

I think the Rust team should of included a solid zero config runtime but allow it to be replaced.

Re: Portable and Interoperable Async Rust

#45

Post by skohan »

nojito wrote: post #43
skohan wrote: post #31

Earlier quoted context omitted.

What about the former core team member who also raised similarly-vague alarm bells about Rust's governance, and Amazon's involvement? I'm somewhat invested in Rust, and it's a bit worrying to see this from two places.

Why? The language related work takes place elsewhere. The term “core team” is just a misnomer.

I mean, I am pretty far from all of that and I'm not really sure how it works. It's just generally a bit worrying when you hear from a few independent sources: "don't trust (X), they're behaving badly"

Re: Portable and Interoperable Async Rust

#46

Post by epage »

skohan wrote: post #45
nojito wrote: post #43

Earlier quoted context omitted.

Why? The language related work takes place elsewhere. The term “core team” is just a misnomer.

I mean, I am pretty far from all of that and I'm not really sure how it works. It's just generally a bit worrying when you hear from a few independent sources: "don't trust (X), they're behaving badly"

To clarify then, the two groups made accusations against different people:

- A core team member made an accusation against Amazon

- The mods had concerns with the lack of oversight of the core team

Re: Portable and Interoperable Async Rust

#47

Post by geodel »

bishop_mandible wrote: post #9

"Wenn man nicht mehr weiter weiß, gründet man einen Arbeitskreis." - Ancient German proverb. (Translation: "If you don't know what to do next, you set up a working group")

Well Rust is always about dozens of teams, myriad committees, sub-committees , groups, sub groups, work groups, governance boards, foundations and so on. Although I don’t know they have such huge budget to run fortune 500 or government style bureaucracy. Or is that same people appear at ten different places.

Re: Portable and Interoperable Async Rust

#48

Post by varajelle »

pjmlp wrote: post #11
cute_boi wrote: post #3

Earlier quoted context omitted.

zero cost abstraction and no gc

Same could be said for C++, and yet while C++20 also doesn't have an official runtime on std (C++23 will fix that assuming executors land), the vocabulary types required for interoperability across runtimes are part of the co-routines design.

Rust also has the vocabulary types required for interoperability, such as Future and Waker. Or what exactly make C++ more interoperable?

Re: Portable and Interoperable Async Rust

#49

Post by vlang1dot0 »

geodel wrote: post #47
bishop_mandible wrote: post #9

"Wenn man nicht mehr weiter weiß, gründet man einen Arbeitskreis." - Ancient German proverb. (Translation: "If you don't know what to do next, you set up a working group")

Well Rust is always about dozens of teams, myriad committees, sub-committees , groups, sub groups, work groups, governance boards, foundations and so on. Although I don’t know they have such huge budget to run fortune 500 or government style bureaucracy. Or is that same people appear at ten different places.

Budget doesn't really have anything to do with it. The vast majority of people on a team or working group aren't paid to work on Rust; they're volunteers.

Re: Portable and Interoperable Async Rust

#50

Post by pjmlp »

varajelle wrote: post #48
pjmlp wrote: post #11

Earlier quoted context omitted.

Same could be said for C++, and yet while C++20 also doesn't have an official runtime on std (C++23 will fix that assuming executors land), the vocabulary types required for interoperability across runtimes are part of the co-routines design.

Rust also has the vocabulary types required for interoperability, such as Future and Waker. Or what exactly make C++ more interoperable?

Does it? https://book.async.rs/overview/std-and-library-futures.html

C++ ones can interoperate with any type that plugs into the compiler magic expected by the co-routines code rewrite.

If you want to deep dive into how Visual C++ does it, and how WinRT gets plugged into C++ co-routines, here is a very lengthy set of blog posts.

https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10...

Now back to Rust, how can I interoperate across tokio, async-std, smol and fuchsia-std, as easy as I can between WinRT, and others?

Post reply on HN