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

Why Continuations Are Coming to Java

infoq.com

Post reply on HN
Print view View original

101–110 of 185 posts

Re: Why Continuations Are Coming to Java

#101

Post by swsieber »

provolone wrote: post #9
y4mi wrote: post #8

I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians... This is especially widespread with spring boot. I've even read sentences like "It's hard to say what it does, you can only see it's effects!"

Just avoid bloated frameworks and your problem is solved.

Considered removing spring where I work to speed up startup times. Found the biggest bang for the buck was rewriting a bean factory to parallelize singleton preinstantion.

That's what I thought the optimal route was. That's how much we benefit from the strong spring ecosystem.

(It was a little less of a pain than you might think because I didn't have to support all spring features, just the ones we use, which happen to mostly not be features used during singletons preinstantion)

Re: Why Continuations Are Coming to Java

#102

Post by exabrial »

trias wrote: post #65

Honest question, maybe obvious: Why is the java-scheduler/ thread model so much better than the OS-level one? What does the java one do, or better what does it not do? And why can't the principles which make java-scheduling fast be applied to OS-threads?

Simply: less stuff to do. Saving a few stack frames vs a transition into kernel space and subsequent hardware calls.

I imagine Java can do some party tricks with lock sharing too with fibers backed by the same OS thread.

Re: Why Continuations Are Coming to Java

#105

Post by maxiepoo »

aardvark179 wrote: post #74
SeanLuke wrote: post #28

How does this differ from scheme-style continuations? IIRC, full continuations in the scheme sense of the term are currently impossible in Java as they require forbidden stack manipulation. Or is what's being proposed here something entirely else?

We're adding delimited one-shot continuations to the JVM. The common public interface to these is likely to be fibers rather than raw continuations, as they are much easier to work with and allow the standard library and lots of existing code to take advantage of the new features with little to no change.

By one-shot you mean dynamically enforced, right? I.e. if you invoke it a second time it will raise an exception?

Re: Why Continuations Are Coming to Java

#106

Post by oddthink »

Does anyone have a good link to the state of the modern thinking on continuations?

I remember from back in the Scheme R5RS era there was a conflict between call/cc and dynamic-wind.

If you have a dynamic extent (like for example a try {} finally {} block that does resource allocation/deallocation), and you exit, but then jump back into the block, how far do you try to re-wind the state? You probably don't re-open files, but you would probably want to re-set any dynamic-scoped variables.

I don't remember seeing this raised as an issue recently, so it must have been solved somehow, and I'm just wondering how.

Re: Why Continuations Are Coming to Java

#107

Post by ghusbands »

oddthink wrote: post #106

Does anyone have a good link to the state of the modern thinking on continuations? I remember from back in the Scheme R5RS era there was a conflict between call/cc and dynamic-wind. If you have a dynamic extent (like for example a try {} finally {} block that does resource allocation/deallocation), and you exit, but then jump back into the block, how far do you try to re-wind the state? You probably don't re-open fil…

Dynamic-wind was created to tame call/cc and exceptions, rather than being in conflict with it. It directly provides the facilities for re-re-setting things when you re-enter a left scope.

However, you might want to look up delimited continuations as a different approach to similar kinds of control flow.

Re: Why Continuations Are Coming to Java

#108

Post by jerf »

dfgdghdf wrote: post #98

In the talk he says that continuations compose much better than monads. Can someone elaborate on this?

In a Java context, I'd say it's undeniably true. Haskell-style composition of monadic values depends on type system features that Java doesn't have and on no account should even be thinking about adding at this point in time. And that's ignoring the syntax mess it would be in Java today, too.

In a Haskell context, since continuations are typically implemented as a monadic value, the statement would be more or less nonsensical. But I don't think that would be the context in question.

Edit: noelwelsh speaks of another level of composition than I was, where one is trying to take, say, State and STM and create a new monadic value that does both those things. The analysis given there is correct as well. My point here is more syntactic and basic functioning, in that even if you pick a single monadic value type to stick with, it's not going to play well in Java anyhow. So, in conclusion, generalized monad-type code in Java is just comprehensively not really possible. Continuations, or what are being called that in modern times, however, fit into Java-type languages, as proved by several very similar languages that have had them for many years, and they work fine.

Re: Why Continuations Are Coming to Java

#109

Post by noelwelsh »

dfgdghdf wrote: post #98

In the talk he says that continuations compose much better than monads. Can someone elaborate on this?

Monads don't compose, in the sense that if you two monads of different types you can't always mash them together to create a single monad that encompasses both of the effect the two monads represent. This is not surprising as (side-)effects don't in general compose so there is no reason that monads should.

Now I disagree with Ron's assertion that continuations compose better than monads. Here's why:

All monads can be expressed in terms of the continuation monad. As the name suggests this is just a monadic encoding of continuations. (See https://www.schoolofhaskell.com/school/to-infinity-and-beyon...).

If your language has continuations built-in then all programs are effectively running in some "ambient" monad that can express all other monads. Just like if you have exceptions you're effectively running within an error-handling monad.

So essentially rather than writing `F A` (or `F[A]` or `F` or whatever syntax your language supports) to represent effectful programs all programs are implicitly running within such an effect type.

Re: Why Continuations Are Coming to Java

#110

Post by pron »

avodonosov wrote: post #82
pron wrote: post #70

Earlier quoted context omitted.

There are a couple of issues here: scheduling, and managing the stack. The reason a runtime can do better than the kernel is that its constraints are (hopefully) less constraining than those of the kernel. In the case of managing the stack, the kernel must be able to support languages like C/C++ and Rust, that can have internal pointers pointing into the stack itself. This makes it hard to reallocate stacks dynamical…

pron, isn't it simpler to just allocate everything on heap, than reallocating coroutine stacks? Or is allocating on heap significantly less performant than managing coroutine stacks (stack need to be copied, while heap allocated object can stay the same). Also, is there any timeline or estimate when Loom will be released with official JDK?

In the current Loom implementation, continuation stacks are allocated on the heap; they can grow and shrink as ArrayLists do -- the object stays the same, but the backing array needs to be reallocated.
Post reply on HN