Live data from Hacker News

Why Continuations Are Coming to Java

infoq.com

91–100 of 185 posts

Re: Why Continuations Are Coming to Java

#91
post #11
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!"

I wonder if it's because there is such a sharp line between what a Java programmer can do in Java, and what the JVM does to make that possible. Much of what the JVM does is impossible to even describe in normal Java. That line doesn't exist in, say, C++, where the compiler is just another C++ program. With the caveat that there are JVMs written in Java, so that line can be crossed: https://www.jikesrvm.org/ The same…

I guess you haven't seen too much C++ magic.

You just need to master SFINAE, ADL, template metaprogrmming including tag dispatch, constexpr and eventually you will reach C++ Gandalf status.

Re: Why Continuations Are Coming to Java

#93

Earlier quoted context omitted.

Assembly and C have plenty of magic to go around, don't worry.

C yes, assembly--where? Its mapping to machine code is relatively straightforward, and as is the mapping from machine code to ELF. Or do you mean all the magic the CPU does to make it go fast?

Well, it’s turtles all the way down. [1]

Even the assembly language programmer is running on top of the OS. The OS is deep magic: runtime interrupts happening to make the floating point hardware handle certain edge cases correctly. Fork system calls that semantically provide a copy of the parent’s address space in almost no time by using virtual memory tricks (copy on write pages). Virtual memory itself.

The OS lets the user space assembly language programmer touch some of the hardware directly, but not all of it.

[1] https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down

Re: Why Continuations Are Coming to Java

#94
30min in and I think:

Are they now trying to make Java to work like PL/SQL, Cobol, SAP (ABAP = SQL+COBOL)..?

I think it is a good idea, and is a way to bridge the gaps between the old and “new” way of writing programs. The real reason is not just scalability but traceability, that you can change code at runtime, closer connected to the database..

Re: Why Continuations Are Coming to Java

#95
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?

> Also, is there any timeline or estimate when Loom will be released with official JDK?

From another place in this thread:

As OpenJDK has switched to time-based releases, we no longer plan releases based on features. When a feature is ready, it is merged into the mainline and released in the following release. We never commit to a timeline, but I would say that the probability for fibers to land in one of the two releases next year as quite high. Of course, we release projects gradually, and it's possible that some planned fiber features will not land in the first release, or that the performance in the first release will later be improved etc. However, early access Loom binaries (with API still very much in flux) are expected in a month or so, with the intention of gathering feedback on the API. The decision on when fibers are ready to be merged will greatly depend on that feedback.

Re: Why Continuations Are Coming to Java

#96
post #75
post #66

Earlier quoted context omitted.

The lightweight threads(fibers) are actually not threads on the OS level, they just behave similarly. As such there are no context switches etc., which are slow.

i know, but why doesn't the OS do this too? Most programmers don't care if their "thread" is an actual thread on the machine or just a "fiber". If the benefits are this large, it should be provided by the OS in my opinion.

Windows provides fibers in addition to threads. Apparently it’s a quite good API although not widely used:

https://nullprogram.com/blog/2019/03/28/

Re: Why Continuations Are Coming to Java

#99

Earlier quoted context omitted.

Maybe with kotlin coroutines you can rewrite the application partially. Is there a difference between that and fibers?

Kotlin coroutines, as well as js and c# async/await, require us to change declaration of calling function. We can call a "suspend" function only from a "suspend" function, which in turn can only be called by another "suspend" function. So if I change some of my functions to "suspend" everyone upper in the call stack should be changed to "suspend", which is not always possible because that may be a 3rd party code. Tha…

[deleted]

Re: Why Continuations Are Coming to Java

#100
Wow, continuations are pretty awesome, because with them you can build any control structure you like. Now if Java only had macros, so that homegrown control structures could be concise & succinct, like built-ins …

It's kinda of funny how languages are slowly becoming more and more Lisp-like — even Lisp is available, still offering what it offers.

As an aside: argh, in Firefox it stole the spacebar, so there's no way to scroll down the page, even if I click outside of the video.

Why do web pages do that?

Post reply on HN