Hacker News Reader

Comment by jeremiep | Hacker News Reader

I don't think its a superior paradigm, just a different one.

I only see his nursery as being useful when you really want your async tasks to complete before the function in which they were dispatched returns. That's far from covering every use case of concurrency!

A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread. Doing so will literally kill any advantages of concurrency in the first place, might as well just block directly. (This is especially true of apps modelled as an update loop, you definitely don't want to block that loop.)

I can think of very few places where I'd actually want a nursery, and even in those cases I'd rather use the promises or fork&join already available.

View on HN

> I only see his nursery as being useful when you really want your async tasks to complete before the function in which they were dispatched returns. That's far from covering every use case of concurrency!

His section "There is an escape" answers this criticism: "The nursery object also gives us an escape hatch. What if you really do need to write a function that spawns a background task, where the background task outlives the function itself? Easy: pass the function a nursery object."

He goes on to explain a bit more, but one of his points is what really ties this abstraction back into the goto discussion: "Since nursery objects have to be passed around explicitly, you can immediately identify which functions violate normal flow control by looking at their call sites, so local reasoning is still possible."

> A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread.

I think they can: applications with background threads would have an outer-level nursery at whatever "main" is for them, and that nursery would be passed into whatever function needs to spawn a background thread.

Then what is the difference between the nursery escape and joining a thread or extracting the value of a promise? Both of these will bubble any error back into the dispatch thread.

Seems like we're just layering indirections (I wouldn't call that an abstraction) for little added value over the existing constructs.

The difference is that you can look at function, see it takes no nurseries as parameters, and know it does not spawn any background tasks. And if it does take nurseries, then you know it's likely that it does.

Whats the difference between taking a nursery and returning a promise? Both put the context in the signature, but the later is actually composable.

When I call a function, I have no way of knowing if there are any unhandled promises within it. The difference is the restriction: with nurseries, background tasks can only outlive function calls if the calling function allows them to.

I get compile-time warnings or runtime errors when I create unhandled promises. What more is needed?

Needed is a strong word, but what this provides are guarantees when reading the code. Much like you know that control flow will come back to the function you're reading after calling another function. We didn't need to know that control flow will resume in the calling function, but it turned out to be very useful.

What guarantees? Nothing prevents a function receiving a nursery from not using it. Unless the language can enforce it you don't really gain anything valuable over returning a Promise, except more complex code that doesn't compose.

> Much like you know that control flow will come back to the function you're reading after calling another function.

What about continuations? Exceptions? Aborts? setjmp()? I can think of many cases where control doesn't return to the caller that are perfectly valid.

Basically, either the code is so simple theres obviously no bugs, or the code is so complex theres no obvious bugs. I feel a nursery is closer to the later than the former.

Can you force explicit nursery passing though? One might make a global nursery object and then just rely on that.

In some existing languages, yes. But it’s easy to imagine future languages (including future versions of current languages) that disallow creating nurseries outside of a function scope.

At this point you're pretty much reinventing Monads.

You might want to consider that this exact thread of questioning does not deviate at all from the similar line that was used to defend `goto` against structured programming. I’m not saying that you’re wrong or that this is necessarily the same thing, but the author addresses these kinds of questions through analogy to the `goto` debate in the article. It’s worth thinking about their similarity.

TL;DR, this doesn’t add expressive power (in fact, it removes it). The author argues that the power removed is power that is unnecessary, dangerous, and inhibits the ability to infer higher-level invariants about your programs that can improve understandability while potentially enabling even better abstractions. Even more briefly: restrictions make your code better.

I agree, but I still wouldn't call a nursery an abstraction; its an indirection, and a mutable one at that. I also disagree with the goto analogy; concurrency and control flow are two distinct things, they have much more differences than similarities.

Implementing a promise as a monad will yield all the same benefits while also keeping the ability to compose and be immutable; and then you have an abstraction and the result is simple.

I agree restrictions make the code better, this just isn't one of these cases to me.

> A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread.

If your background operation has those characteristics, maybe it is better to spawn a new process for it. Why a thread?

I use concurrency in the form of an error group combined with an injected context and a way of propagating the cancel via that context to an exec if I we're going that route. It's a best of both worlds solution IMO.

A process has much higher overhead (both in time and space), more complex communications and is not always possible in the first place. It also adds complexity to the build pipeline. These quickly adds up to being not worth it over a task or thread.

You wouldn't spawn a process for the rendering/input/physics/network/job/loader threads of a game engine for one. You can't spawn processes from a web app either.

Threads are actually pretty darn simple when you have either immutable data or uniqueness constraints. Deterministic parallelism is also very powerful while preventing all sorts of nasty bugs.

> A process has much higher overhead (both in time and space), more complex communications and is not always possible in the first place.

This can change if OSes start optimizing for the proposed convention.

> It also adds complexity to the build pipeline.

At least in C/C++ it doesn't. But again, this is also easily solvable if we want to.

> You wouldn't spawn a process for the rendering/input/physics/network/job/loader threads of a game engine for one.

Why not? In my mind, if you need 2-way communication between 2 threads, they should be siblings. If they need one way communication, there should be a parent-child structure. If they need no/minimal communication, they are better off as processes. I don't know which categories each of the threads you named fall into. I realize that this approach will require extensive redesign of existing software, very much like the elimination of goto required.

> You can't spawn processes from a web app either.

No reason for it to stay that way.

> Threads are actually pretty darn simple when you have either immutable data or uniqueness constraints. Deterministic parallelism is also very powerful while preventing all sorts of nasty bugs.

I won't pretend to know all those words :P I just think the article's proposal has some merit and we should consider it. >

> This can change if OSes start optimizing for the proposed convention.

What conventions? Its not realistic to assume the world will change to fit your views of software :p

> At least in C/C++ it doesn't.

Sure does; it adds more build targets, gets you to maintain shared code across executables, and plan deployment for multiple executables instead of one. Thats all before even coding the support for that.

> Why not?

Because these depend on shared memory and ownership transfer for performance; you'll drastically drop performance just for the sake of isolation.

> No reason for it to stay that way.

I will literally stop using the web if pages can spawn processes :)

> I won't pretend to know all those words :P

Hehe, basically immutability makes it so nobody can mutate data, thus making it safe to be shared across threads. Uniqueness will transfer ownership such that only one thread has references to a mutable piece of memory at any time. Deterministic parallelism means its impossible to have race conditions or deadlocks.

> I just think the article's proposal has some merit and we should consider it.

Agreed, I'm still having a hard time seeing it however :p

threads were actually invented for these sorts of use cases, as "lightweight processes".

If OSs change again, sure, the way we program will change again.

At the moment, using processes is too resource intensive, that's exactly why we have threads in the first place. And I don't understand what benefit you are suggesting using processes over threads would have.

>I only see his nursery as being useful when you really want your async tasks to complete before the function in which they were dispatched returns. That's far from covering every use case of concurrency!

Perhaps, but only having a complex solution that handles 100% of use cases is less desirable than having a simple one that handles 80% of the most common use cases PLUS the ability to go deeper and use the complex method (if, and only if, it's necessary...)

Agreed, I'd rather have a few simple constructs, especially if they compose.

Still, there's value in unification and generality, at least when the result is simple, even if that covers only 80% of cases.

For example you generally run a lot more composable tasks than actual threads and syncs. You get a general, and powerful abstraction for the general case yet threads are still there for more exotic needs.

Reply on news.ycombinator.com