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

31–40 of 71 posts

Re: Portable and Interoperable Async Rust

#31

Post by skohan »

nojito wrote: post #22
crtc wrote: post #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.

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.

Re: Portable and Interoperable Async Rust

#32

Post by zaphar »

KingOfCoders wrote: post #28
stubish wrote: post #10

Earlier quoted context omitted.

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…

I only have rudimentary knowledge of Golang (but think the blocked/green automatic scheduling is excellent). How does go nest aync calls? func f() { } func g() { } func h() { go g() go f() } What happens on f() Are the g() and f() calls inside h() blocking? Or are they async and the block happens at the point of return? Which would be the main difference to languages with an async keyword, were you need to be explici…

The go keyword executes the called function asynchronously so g() and f() won't block h(). If you need a computed result from g() or f() then you'll need to use a channel or a shared mutex guarded value to get it. A channel is the correct default choice and the mutex should only be used if you need it for performance or other reasons.

Re: Portable and Interoperable Async Rust

#33

Post by c-cube »

skohan wrote: post #30
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?

I think part of it is because computer science hasn't really nailed the right abstraction for concurrent code execution. For instance, C is a great abstraction. You take assembly language, abstract away manual management of registers with variables and pointers, add structured types to describe memory layout, standardize flow of control operations, and add functions to enable code reusability, and you have something…

Zig has tagged unions and the corresponding switch expressions, is that not equivalent?

Re: Portable and Interoperable Async Rust

#34

Post by carlmr »

mseepgood wrote: post #15
cute_boi wrote: post #3

Earlier quoted context omitted.

zero cost abstraction and no gc

All design trade-offs have a cost. In this case the costs are reduced usability and async struggles.

Zero-cost abstractions is used to mean zero runtime cost (in release builds), so if an abstraction would break that it wouldn't be suitable for this goal.

Like adding a GC for the async feature.

Re: Portable and Interoperable Async Rust

#35

Post by ezekiel68 »

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 -- all of these and every other "big" choice I make locks me into a similar library ecosystem niche. I despise this "everything's amazing and nobody's happy" vibe. The async library authors have plenty on their plates without some sub-committee crashing in and dictating their features and release schedules.

By the way, using Go as an example is a joke since -- from the early Go bootcamp I attended in 2014, the best practice has been to use a 3rd-party http router (these days: gorilla? httprouter? chi? etc) instead of the one provided in the standard library. Instead of being _told_ what to use, let's get back to being interested enough that we read the docs, take in the reviews & benchmarks, and decide for ourselves.

Re: Portable and Interoperable Async Rust

#36

Post by epage »

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

From what I've heard, they are still working things through. These things take time and we just had a holiday in the US.

Re: Portable and Interoperable Async Rust

#37

Post by shellac »

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?

Sibling comments have explained the detail. The pithier explanation perhaps is that rust is intended as a 'systems language', and it interprets that as meaning there should be no runtime. Or, more simply, it ought to be possible to call a rust function from C without providing an additional argument that encapsulates rust 'environment'. (C effectively defining this area)

Go and Java (with Loom) have these lovely facilities, but it is hard to interface with them if your language lacks these features. I find it odd that C#, javascript, and python don't provide the smoother async Go experience despite having runtimes / VMs.

Re: Portable and Interoperable Async Rust

#38

Post by skohan »

c-cube wrote: post #33
skohan wrote: post #30

Earlier quoted context omitted.

I think part of it is because computer science hasn't really nailed the right abstraction for concurrent code execution. For instance, C is a great abstraction. You take assembly language, abstract away manual management of registers with variables and pointers, add structured types to describe memory layout, standardize flow of control operations, and add functions to enable code reusability, and you have something…

Zig has tagged unions and the corresponding switch expressions, is that not equivalent?

I was not aware of these, either it was added since I kicked the tires on Zig or I just wasn't aware of it, but yes it looks pretty good!

The one drawback I see is that it seems a bit verbose: i.e. the tag set itself has to be declared as a separate enum, and then the tags need to be repeated inside the union.

So it looks to be slightly bolted-on and unergonomic (similar to TypeScript's implementation) but I haven't worked with it so maybe I am missing something.

Re: Portable and Interoperable Async Rust

#39

Post by scns »

skohan wrote: post #16
Zababa wrote: post #13

OCaml is currently going through something similar, with some solutions in sight. The "motivation" part of the eio ( https://github.com/ocaml-multicore/eio ) documentation is a great introduction: "The Unix library provided with OCaml uses blocking IO operations, and is not well suited to concurrent programs such as network services or interactive applications. For many years, the solution to this has been libraries…

How does programming with "effects" actually work? I've read the linked page, and I understand the advantages they're claiming, but I don't see any explanation of what effects actually are .

The last time [0] Effects were discussed, these recommendations were made [1],[2].

[0] https://news.ycombinator.com/item?id=28838099

[1] https://www.youtube.com/watch?v=hrBq8R_kxI0

[2] https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Re: Portable and Interoperable Async Rust

#40

Post by epage »

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.

He is a current core team member, not former [0].

I'm not too worried about his claims. His claim was about the Foundation being shadow-controlled by Amazon (they employed the board chair who had more influence while they lacked an Executive Director). The foundation manages the assets (donations, legal marks, etc) and has no control of the actual language. For Amazon to take control, theyd have to get the board involved and then leverage the assets against the developers. Nothing like this has happened and there is now an Executive Director.

When observing that incident, I noticed that those joining the bandwagon didn't seem to have direct knowledge of the situation. Those that did, stayed quiet or made general statements about the claims not being accurate regarding why there wasn't an Executive Director yet (interim or not). To me, this suggests something happened that, professionally, people feel should be kept confidential and I try to support that by not doing further speculation.

[0] https://www.rust-lang.org/governance/teams/core

Post reply on HN