Live data from Hacker News

Why Continuations Are Coming to Java

infoq.com

121–130 of 185 posts

Re: Why Continuations Are Coming to Java

#121
post #27

> I serve as a technical lead for Project Loon. That is the project that's intended to add continuations and fibers to the JDK. > However, actually, Project Loom, the goal of the project is to add continuations, fibers, and tail call elimination. I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of wh…

There is a Project Loon somewhere, it's a google attempt to deliver internet through balloons.

Re: Why Continuations Are Coming to Java

#122
post #119

One thing I get learning about implementing continuations is that at the end them have huge runtime cost and complicate implementation and debugging greatly. Even do a simple interpreter with them quickly get out of control. Exist update info in how tame it?

One approach, which Java is taking, is to implement a more structured form of continuation, rather than say the Scheme-style call/cc ones. A quote from the article: "To be more precise, if you're interested in the theory of continuations in the academic literature, the kind of continuation of this class implements are called one-shot multi prompt delimited continuations..."

Re: Why Continuations Are Coming to Java

#125
What ever happened with continuations in Scala? A lot of people were excited about them back in 2009, but if I google them now I still only get pages from 10 years ago. I haven't used Scala in a very long time, so I stopped paying attention to any changes in the language.

Re: Why Continuations Are Coming to Java

#126
post #69
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?

The OS thread model is lightweight processes - each OS thread is essentially a separate process sharing a common section of the process control block. Context switches are still relatively heavyweight involving a kernel mode switch, CPU state save and restore. Application threads are a part of the application runtime environment. Thread scheduling is little more than a function call and doesn't involve a syscall invo…

Seems like your saying application threads are “green threads”, when the jvm has used system threads one to one for a long time now. So for the jvm at least there’s no difference between a jvm thread an an OS thread. Some jvm impls may still use green threads, but the major ones haven’t for many years. Apologies if I’ve misunderstood.

Re: Why Continuations Are Coming to Java

#127
post #27

> I serve as a technical lead for Project Loon. That is the project that's intended to add continuations and fibers to the JDK. > However, actually, Project Loom, the goal of the project is to add continuations, fibers, and tail call elimination. I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of wh…

It is indeed Project Loom - https://openjdk.java.net/projects/loom/

Re: Why Continuations Are Coming to Java

#128

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?

You almost never want full continuation. They are less efficient, harder to reason about (because they capture things outside the call/cc) and are a generally fantastic way to accidentally leak memory.

Oleg Kiselyov has written about it extensively: http://okmij.org/ftp/continuations/

Re: Why Continuations Are Coming to Java

#129
post #125

What ever happened with continuations in Scala? A lot of people were excited about them back in 2009, but if I google them now I still only get pages from 10 years ago. I haven't used Scala in a very long time, so I stopped paying attention to any changes in the language.

as far as I can tell scala concurrency basically boils down to a few different subclasses that have some overlap: 1. streaming/observable focused like Monix 2. IO effect type like Cats Effect and ZIO 3. Twitter futures/Stdlib futures which are different from each other in some crucial ways
Post reply on HN