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

Building a shared vision for Async Rust

blog.rust-lang.org

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Building a shared vision for Async Rust

#131

Post by lmm »

Const-me wrote: post #130
lmm wrote: post #128

Earlier quoted context omitted.

> Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. Disagree, because even if you can't handle errors in your code you have to do things like make sure resources are closed correctly. So you end up having to reason about exception safety, which i…

> you have to do things like make sure resources are closed correctly. Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. > a graph with cycles and you don't have a clear owner It's hard in Rust even for acyclic graphs with a clear owner, due to updates. Code that mutates the graph often needs t…

> Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason.

Code doesn't deal with resources until it does. Similarly with everything else that forces you to reason about control flow - you don't care about thread management until you do, you don't care about action logs until you do, you don't care about performance until you do... and from the other side, code doesn't need to be exception-safe until it does. The trouble with this kind of "magic" language feature is that correctness becomes non-compositional: you can take two working pieces of code and put them together and get something that doesn't work.

Re: Building a shared vision for Async Rust

#132

Post by BuckRogers »

Ar-Curunir wrote: post #107
BuckRogers wrote: post #70

Earlier quoted context omitted.

Downplaying Rust isn’t going to go over well in this thread. I happen to completely agree with you, but I would add or say that Rust is the first new programming language in a very long time that qualifies as technical innovation and not technical churn. Maybe the only one since Java. And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. But standing back and looking at the big list[0], only C…

> Downplaying Rust isn’t going to go over well in this thread. People were downvoting the OP not because they were criticizing Rust, but they were off-topic. The article is about Rust async; OPs comment is about Rust.

Some have suggested that, but I never minded general takes on a given language when the thread is about a specific feature. I think the majority would be with me on this, maybe not, but he did receive upvotes again. There are few enough language version release threads that there's nowhere else for people to share their opinions, for me it's appropriate.

Re: Building a shared vision for Async Rust

#133

Post by BuckRogers »

shock wrote: post #77
BuckRogers wrote: post #70

Earlier quoted context omitted.

Downplaying Rust isn’t going to go over well in this thread. I happen to completely agree with you, but I would add or say that Rust is the first new programming language in a very long time that qualifies as technical innovation and not technical churn. Maybe the only one since Java. And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. But standing back and looking at the big list[0], only C…

> And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. It has colored functions. Every async function is turned by the compiler into a class with an embedded FSM. Async is viral in C#, so much so that even main() had to be made async. So, no, it's not Java done right.

Java done wrong? I've always been a Java/C# person, that's the general programming abstraction layer I've spent most of my education and career in and prefer it. I greatly prefer C# (and all that comes with it) over Java. But if C# didn't exist, I would probably prefer Java over all other alternatives. The only reason I'd fall onto Javascript upon C#'s disappearance would be because most of my experience is in web, but definitely not due to the ecosystem or language. So from a language/ecosystem perspective, Java is my 2nd choice, I never hated Java, it's popular for good reasons.

Re: Building a shared vision for Async Rust

#134

Post by h0l0gr4ph1c »

songqin wrote: post #109
h0l0gr4ph1c wrote: post #54

Earlier quoted context omitted.

Complexity kills code. Being able to reason about what your code is doing, is FAR more valuable to me than async. Having tokio act as my runtime and switch tasks as it sees fit will be debug hell. The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in. As in, the code works regardless of an async runtime, async is added magic if you want it, but it wi…

> The problem I see is the current async story is opt-out. Surely this is only the case if you have picked asynchronous libraries to use?

I actively choose libraries that are non-async. I don't want to use the programming model.

If aysnc could work like regular blocking code , if we want, and async code when you want, I think rust would be in a better place.

Just because you can do something doesn't mean you should.

Re: Building a shared vision for Async Rust

#135

Post by shock »

BuckRogers wrote: post #133
shock wrote: post #77

Earlier quoted context omitted.

> And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. It has colored functions. Every async function is turned by the compiler into a class with an embedded FSM. Async is viral in C#, so much so that even main() had to be made async. So, no, it's not Java done right.

Java done wrong? I've always been a Java/C# person, that's the general programming abstraction layer I've spent most of my education and career in and prefer it. I greatly prefer C# (and all that comes with it) over Java. But if C# didn't exist, I would probably prefer Java over all other alternatives. The only reason I'd fall onto Javascript upon C#'s disappearance would be because most of my experience is in web, b…

I like C# a lot (internal classes, yield, etc.) except for their async implementation. I believe Java's Project Loom will prove to be the superior solution.

Re: Building a shared vision for Async Rust

#136

Post by h0l0gr4ph1c »

steveklabnik wrote: post #110
songqin wrote: post #109

Earlier quoted context omitted.

> The problem I see is the current async story is opt-out. Surely this is only the case if you have picked asynchronous libraries to use?

Yes, in fact, you cannot even use async Rust without writing your own executor or bringing one in via a library. It is very, very much opt in. That was a hard constraint on the design. However, I think what the parent is getting at is the feeling of the total package, not the technical details. If every library you want to use is async, you can't really "opt out" exactly, even if technically the feature is opt out.

By opt in I mean I can opt in to using an executor if I want async. If I don't code still works and is might not be as performant.

Couldn't you have made another hard constraint to make async code work as normal if the programmer wanted?

Re: Building a shared vision for Async Rust

#137

Post by steveklabnik »

h0l0gr4ph1c wrote: post #136
steveklabnik wrote: post #110

Earlier quoted context omitted.

Yes, in fact, you cannot even use async Rust without writing your own executor or bringing one in via a library. It is very, very much opt in. That was a hard constraint on the design. However, I think what the parent is getting at is the feeling of the total package, not the technical details. If every library you want to use is async, you can't really "opt out" exactly, even if technically the feature is opt out.

By opt in I mean I can opt in to using an executor if I want async. If I don't code still works and is might not be as performant. Couldn't you have made another hard constraint to make async code work as normal if the programmer wanted?

An executor is required, in name or in spirit. Every async system has software that does this. Most language runtimes that do simply give you no choice in the matter.

Re: Building a shared vision for Async Rust

#138

Post by h0l0gr4ph1c »

steveklabnik wrote: post #137
h0l0gr4ph1c wrote: post #136

Earlier quoted context omitted.

By opt in I mean I can opt in to using an executor if I want async. If I don't code still works and is might not be as performant. Couldn't you have made another hard constraint to make async code work as normal if the programmer wanted?

An executor is required, in name or in spirit. Every async system has software that does this. Most language runtimes that do simply give you no choice in the matter.

Rust is a language that does things different to other languages because it is a better way. I challenge you to do the same with Async. There is a different better way.

Re: Building a shared vision for Async Rust

#139

Post by BuckRogers »

shock wrote: post #135
BuckRogers wrote: post #133

Earlier quoted context omitted.

Java done wrong? I've always been a Java/C# person, that's the general programming abstraction layer I've spent most of my education and career in and prefer it. I greatly prefer C# (and all that comes with it) over Java. But if C# didn't exist, I would probably prefer Java over all other alternatives. The only reason I'd fall onto Javascript upon C#'s disappearance would be because most of my experience is in web, b…

I like C# a lot (internal classes, yield, etc.) except for their async implementation. I believe Java's Project Loom will prove to be the superior solution.

I'd likely agree with you, mostly on the grounds that by default being late and learning from earlier implementations always helps.
Post reply on HN