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

Local async executors and why they should be the default

maciej.codes

Post reply on HN
Print view View original

291–300 of 327 posts

Re: Local async executors and why they should be the default

#291

Post by pjmlp »

pdimitar wrote: post #203
pjmlp wrote: post #167

Earlier quoted context omitted.

And yet it didn't learn that it took almost 10 years for .NET community to sort out async/await support across all layers of the stack. .NET archictects have spent last year researching Go and Java Loom approaches, and have acknowledge if it had been today, most likely that would have been the approach taken instead of async/await, as many .NET devs still get it wrong. During the "ASP.NET Core and Blazor futures, Q&A…

Everyone rediscovers Erlang at one point in this space, it seems.

Yeah, it would be great if it had wider industry adoption.

Re: Local async executors and why they should be the default

#292

Post by pjmlp »

jerf wrote: post #151
kibwen wrote: post #125

Earlier quoted context omitted.

> Where did it come from in its current incarnation? Node. Rust's async/await is inspired by C# (which was inspired by F#, which was inspired by Haskell). > right now threaded code is straight-up a better option on almost every metric, Agreed that people are generally too eager to reach for async when they could easily get away with threads, and fortunately Rust makes threads extremely pleasant to work with. The whol…

See other post about why I blame node. As for Rust supporting threads... yes! Yes it does! And it effectively solves all of the problems with them that can be solved at the programming language level. There's an irreducible increase in complexity with concurrent code, but there's only so much to be done about that. I think a lot of developers have a tendency to massively overprivilege performance and always reach for…

It is the mindset that makes one buy a SLR, when they can't even make up all the options on the smartphone camera.

Re: Local async executors and why they should be the default

#293

Post by pjmlp »

jerf wrote: post #142
seanhunter wrote: post #115

Earlier quoted context omitted.

Async in its current incarnation did not come from node. Eg Haskell had async/await in 1999. https://softwareengineering.stackexchange.com/questions/3774... Node wasn't released until 10 years later.

And I have code still in production written in the "Perl Object Environment", one of several async frameworks for Perl, written before Node even existed. Also before Node existed, I had written code in the Twisted framework for Python. Node did not invent async by any means and I know it in the strongest possible sense, having used it before Node existed. But those libraries, in use for over a decade, did not make ev…

Add Tcl events to it as well, with famous rants like this one, "Why Threads Are A Bad Idea"

https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...

Re: Local async executors and why they should be the default

#294

Post by pjmlp »

cmrdporcupine wrote: post #133
jerf wrote: post #113

Earlier quoted context omitted.

I really think in the end, in another decade or two, the community consensus is going to be that async as it is conceived of today is simply a mistake, full stop. Think about it. Where did it come from in its current incarnation? Node. Why did Node choose it? Did it have a multiplicity of options and carefully choose the best one based on years of experience with each choice? No. Async was "chosen" because it was the…

We wrote asynchronous driven network code for decades without syntactic sugar for it, and it was fine. That 5% performance gain can be had without it. Async syntax is a mistake. Not just because of the mess it makes across the program tree, but also because it brings with it a specific notion of how to do asynchronous I/O. io_uring for example gives an entirely different model, one with some lovely performance benefi…

On Windows side, IO Completion ports, BeginAsync()/EndAsync(), TPL and Dataflow.

Re: Local async executors and why they should be the default

#295

Post by pjmlp »

pdimitar wrote: post #253
jacquesm wrote: post #251

Earlier quoted context omitted.

In a way it really gets me: we have a very good solution and yet everybody is pushing their own novel footguns with gusto. Baffling, really when you think about it. I'm trying to imagine civil engineering with entirely new ways to design bridges every 4 months, different materials that are entirely untested but this time we'll get it right and so on. That's roughly the state of the software world.

Oh don't even get me started on this, I start fuming just by reading your comments because they often align very closely with my thinking (in other threads as well). I really think we should all pull up our sleeves and e.g. make transpilers from TLA+ to every mainstream language. (Provided we first made sure TLA+'s parallel logic is exhaustive and flawless, of course.) I too get super ticked off these days. The progr…

It isn't a well received opinion, but this kind of stuff, like in other engineering domains, can only be fixed by liability and regulation.

Most people (and companies), don't care for quality unless ignoring at it comes with a fine.

Re: Local async executors and why they should be the default

#296

Post by jacquesm »

pjmlp wrote: post #295
pdimitar wrote: post #253

Earlier quoted context omitted.

Oh don't even get me started on this, I start fuming just by reading your comments because they often align very closely with my thinking (in other threads as well). I really think we should all pull up our sleeves and e.g. make transpilers from TLA+ to every mainstream language. (Provided we first made sure TLA+'s parallel logic is exhaustive and flawless, of course.) I too get super ticked off these days. The progr…

It isn't a well received opinion, but this kind of stuff, like in other engineering domains, can only be fixed by liability and regulation. Most people (and companies), don't care for quality unless ignoring at it comes with a fine.

Liability is the big one. As soon as that kicks in a lot of this absolutely irresponsible stuff will stop.

Regulation would still be playing catch up but being liable, preferably all the way to the people involved including directors, could be done pretty fast and would set us on the path to licensed software engineer in short order.

Re: Local async executors and why they should be the default

#297

Post by pjmlp »

jacquesm wrote: post #296
pjmlp wrote: post #295

Earlier quoted context omitted.

It isn't a well received opinion, but this kind of stuff, like in other engineering domains, can only be fixed by liability and regulation. Most people (and companies), don't care for quality unless ignoring at it comes with a fine.

Liability is the big one. As soon as that kicks in a lot of this absolutely irresponsible stuff will stop. Regulation would still be playing catch up but being liable, preferably all the way to the people involved including directors, could be done pretty fast and would set us on the path to licensed software engineer in short order.

Indeed, and the "what about the poor FOSS developer" isn't something I buy in.

The small little street bazaar salesperson, the little corner shop, big shopping mall, whatever, all of them are liable and manage to make their business just as well.

Re: Local async executors and why they should be the default

#298

Post by [deleted] »

masklinn wrote: post #163
menaerus wrote: post #50

Earlier quoted context omitted.

> So e.g. you have to use Arc > In terms of C++ code that would equate to std::shared_ptr > which ... sounds quite wasteful in terms of scalability/performance. Why is it not possible to simply return a Rust promise? That's the way I do it in my C++ async (executor) library backed by work-stealing queues under the hood.

> Why is it not possible to simply return a Rust promise? It… is? An Arc is what you need to share mutable data between “promises”.

[deleted]

Re: Local async executors and why they should be the default

#299

Post by iopq »

twic wrote: post #258
insanitybit wrote: post #161

Earlier quoted context omitted.

Rust didn't choose async because it was popular. You can go ahead and read the massive, multi-year discussions on the topic if you'd like. They've been going on since before 1.0.

I read them at the time. The gist was basically "it has been empirically established that async is the right way to do concurrency" - ie, it was because of Node.

They specifically referred to C# and its efficient implementation

Re: Local async executors and why they should be the default

#300

Post by gpderetta »

pjmlp wrote: post #288
gpderetta wrote: post #254

Earlier quoted context omitted.

Joe Duffy on Midori and async/await in a C# dialect: http://joeduffyblog.com/2015/11/19/asynchronous-everything/

Where he notes that the .NET implementation wasn't without issues on Midori. Which is again another point of how the whole Rust's async/await process failed to learn from previous experiences. Even worse, because in what concerns .NET, the runtime is part of the story, while in Rust that is yet another piece of the puzzle that is in motion, not yet decided, although it can be anything as long it is tokio.

> Where he notes that the .NET implementation wasn't without issues on Midori.

Indeed. In my opinion and experience async/await is a very leaky abstraction. I think it is definitely not worth it in most languages. Whether it is appropriate for rust I'm unconvinced. I think it is DOA in C++ with its required allocation, but I have yet to use it in anger.

Post reply on HN