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

Asynchronous Everything (2015)

joeduffyblog.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Asynchronous Everything (2015)

#21

Post by kaba0 »

amelius wrote: post #6
cube2222 wrote: post #4

Earlier quoted context omitted.

Agreed. That's basically what Go does. All functions are async, calling functions does an implicit await, and the go keyword let's you spawn a task without await. (At least that's what semantically happens) This way you can write seemingly imperative blocking code, and have it work fully asynchronously. It's great, freeing, and avoids the function coloring problem. It's really the feature I miss most when writing oth…

> Though I do understand why performance oriented languages like Rust might want to approach it differently. The thing Rust gets wrong however, is that there should be a smooth path from ergonomics to performance.

It’s not about performance, but about not having/mandating a runtime.

Re: Asynchronous Everything (2015)

#22

Post by slver »

xh-dude wrote: post #12
slver wrote: post #5

Earlier quoted context omitted.

Performance-oriented languages tend to have a strong type system which lets them know well ahead of time what function is being called, so I see no reason why what you describe can't be done there without performance overhead.

There is a presumption of some runtime behaviors in the Go language spec that makes me wonder here … details can be lifted into the type system but if we’re trying to eliminate overhead, can we do this without revisiting a lot of the issues we were trying to solve with interesting concurrency primitives?

I keep hearing this term "requires a runtime" when async execution is thrown around. And on first glance it makes sense. On deeper look, technically all languages have SOME runtime behavior. And I don't know why we're so objected to it.

Presumably it can get weird when you call into a library and just blocks you. Thus informing us of the need of a common event loop. OS level. Which GUIs had from the get go, but apparently it's not just about GUI.

Re: Asynchronous Everything (2015)

#23

Post by slver »

kaba0 wrote: post #20
slver wrote: post #2

Async will continue to look awkward until we drop explicit "await" on function calls. Awaiting should be the default. If I call "async foo()" then I get back a promise I can explicitly await, but there should be no semantic difference between calling a synchronous function or asynchronous without modifiers. Not only it makes it more consistent, but you can implement running a synchronous function into a separate thre…

Why color functions at all? I think Project Loom is/will be the best way forward where blocking calls will be automagically turned to non-blocking.

Eventually all languages will go this way but for some reason some are stuck on the wrong abstraction.

Re: Asynchronous Everything (2015)

#24

Post by xh-dude »

slver wrote: post #22
xh-dude wrote: post #12

Earlier quoted context omitted.

There is a presumption of some runtime behaviors in the Go language spec that makes me wonder here … details can be lifted into the type system but if we’re trying to eliminate overhead, can we do this without revisiting a lot of the issues we were trying to solve with interesting concurrency primitives?

I keep hearing this term "requires a runtime" when async execution is thrown around. And on first glance it makes sense. On deeper look, technically all languages have SOME runtime behavior. And I don't know why we're so objected to it. Presumably it can get weird when you call into a library and just blocks you. Thus informing us of the need of a common event loop. OS level. Which GUIs had from the get go, but appar…

Like, I see ‘common event loop’ here and don’t OSs (and hardware) past a certain size generally provide interrupt handling, threading, memory management and so forth? These are all highly general mechanisms that have evolved to meet concurrent execution models… because of the generality, a lot of relevant things remain at a lower level of abstraction than languages often expose.

What I wonder about is what happens when we lift runtime policy decisions into the type system, in a way that allows something more performant - I think I have a sense of what this pans out like and I just am skeptical than for every case (for many, many cases, it seems like a great idea!) that this approach leads to the best implementation. It reframes a lot of the inherent difficulties, I’m not sure it helps abstract over them.

Re: Asynchronous Everything (2015)

#25

Post by slver »

xh-dude wrote: post #24
slver wrote: post #22

Earlier quoted context omitted.

I keep hearing this term "requires a runtime" when async execution is thrown around. And on first glance it makes sense. On deeper look, technically all languages have SOME runtime behavior. And I don't know why we're so objected to it. Presumably it can get weird when you call into a library and just blocks you. Thus informing us of the need of a common event loop. OS level. Which GUIs had from the get go, but appar…

Like, I see ‘common event loop’ here and don’t OSs (and hardware) past a certain size generally provide interrupt handling, threading, memory management and so forth? These are all highly general mechanisms that have evolved to meet concurrent execution models… because of the generality, a lot of relevant things remain at a lower level of abstraction than languages often expose. What I wonder about is what happens wh…

Basically we need hardware that works a lot more closely with the OS, and an OS that works a lot more closely with modern language semantics. The problem with the general abstractions you call out (correctly) as inefficient, is that they're stuck in the 80s, and they gotta work with code that looks pretty much like compiled C binaries from the 80s.

Green threads at the language level and so on is a stop-gap in the long-term. Everything has to align together, and then native thread switching will be just as (or almost as) light as green threads.

To be a tad more specific, basically we need hardware+OS to provide us with a model that's pretty close to what the Erlang VM emulates.

Re: Asynchronous Everything (2015)

#26

Post by mpweiher »

abecedarius wrote: post #9
slver wrote: post #2

Async will continue to look awkward until we drop explicit "await" on function calls. Awaiting should be the default. If I call "async foo()" then I get back a promise I can explicitly await, but there should be no semantic difference between calling a synchronous function or asynchronous without modifiers. Not only it makes it more consistent, but you can implement running a synchronous function into a separate thre…

Isn’t this like saying Haskell’s monads are awkward and should be implicit?

"do" notation?
Post reply on HN