Earlier quoted context omitted.
Have you looked into Lisp-Flavored Erlang? https://lfe.io/
There is an actual Clojerl project (Clojure on BEAM) which is probably not relevant in this case.
(I meant to write *more relevant)
Java Virtual Threads Preview
201–210 of 270 posts
Re: Java Virtual Threads Preview
#202Earlier quoted context omitted.
They make one Java IDE, zero contributions to the JVM, and are all cozy with "screw you Java devs" Google godfather. IBM does Java and the IDE (Eclipse). Red-Hat and Microsoft do Java and the IDE (VSCode).
They contribute to the JDK, mostly via the Swing project. For instance they're a major contributor to Project Lanai.
I missed that. Most likely because they are a long way to reboot InteliJ on Compose for Desktop.
Re: Java Virtual Threads Preview
#203Is Virtual Threads part of Project Loom? i.e We expect Project Loom to land a little bit after this or are they completely separate issues and Project Loom is still far from landing?
JEPs are the mechanism by which projects deliver changes. This, and two other JEPs form the bulk of the work done as part of Loom, along with a number of other connected JEPs mentioned in this one.
As part of project Loom, these green threads were called Fibers, not VirtualTheads. Did they change the name?
Re: Java Virtual Threads Preview
#204Earlier quoted context omitted.
JEPs are the mechanism by which projects deliver changes. This, and two other JEPs form the bulk of the work done as part of Loom, along with a number of other connected JEPs mentioned in this one.
As part of project Loom, these green threads were called Fibers, not VirtualTheads. Did they change the name?
Yes. As ideas were prototyped it became clear that Fibers needed to be Threads or there would be too many rough edges regarding compatibility and concepts that developers would need to keep in their heads.
Re: Java Virtual Threads Preview
#205YT talk from Ron Pressler: "Why user-mode threads are (often) the right answer" [1] and slides [2]. 1: https://www.youtube.com/watch?v=KmMU5Y_r0Uk 2: https://assets.ctfassets.net/oxjq45e8ilak/5QM86VAnN9XJ9HUIs2...
Someone would disagree (though in context of C++):
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136...
Perhaps it's easier to address the problems in a managed environment and I really do hope they pull it off. Also it's unclear whether virtual threads will support async file I/O out of the box, or ever. (C# does have Async methods on files.)
Re: Java Virtual Threads Preview
#206I am lost here. the non-goal mentioned here are actually worth taking as goals to be fulfilled so that every other language and library ecosystem which runs on JVM will get benefited. Non-Goals:- It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. It is not a goal to automatically convert existing thread construction to virtual threads. It is not a…
Its impossible say anything unfamiliar thing on HN, all kinds of morons are active all the time on HN to donwvote. ;)
keep it up.
Re: Java Virtual Threads Preview
#207There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two en…
> Any solution towards the thread side of the spectrum will yield significantly larger memory footprints than solutions towards the CPS side of the spectrum. The community-at-large decided that hand-tuning garbage collection was too finicky and not worth it, even though it obviously 'costs' memory. I'm frankly at a loss as to why so, so, so many blogposts and tech experts are all-in on the CPS-side of this argument;…
Very thought provoking. A few of my thoughts:
A GC does not obviously cost memory. It might, or it might not. Both a GC and a traditional memory allocator have hidden costs. A GC with movable objects can sometimes do better, because it can manage fragmentation.
I prefer a message-passing style; on which side of the spectrum would this fall?
My experience with green threads is libraries that make I/O operations look like a regular function call. This is similar to RPC where a remote call and a local can look the same, even though the remote call is much slower. This can result in surprising performance characteristics. Even worse, a remote call can time out or take indefinitely long to complete; the same is not true of local calls. Message passing is more onerous but makes surprises more obvious.
I've often fancied writing for an architecture where main memory is treated as fast remote storage, accessible with message passing. I know such architectures exist but I've never had the opportunity to write for one. I wonder if the change in style would have a positive or negative effect on performance.
Re: Java Virtual Threads Preview
#208Earlier quoted context omitted.
What if the company that makes Kotlin is the one that makes the Java IDE?
Eclipse and NetBeans do exist, and... ehhhhh. I used NetBeans for a long time; couldn't stand Eclipse; and these days I only use IntelliJ. But the others absolutely exist, and it'd be hard to say that Apache and the Eclipse Foundation aren't deeply embedded in the Java ecosystem.
Eclipse is fine. Especially from VsCode where it uses the Eclipse language server. It boots fast, and when you run it with a modern JVM and GC the memory usage is leagues lower than IntelliJ.
Re: Java Virtual Threads Preview
#209Earlier quoted context omitted.
Well that's the Spring's great feature: To convert as many compile time errors in to runtime errors as possible.
To be fair there is the new Kotlin based wiring API which avoids that with the caveat you need to instantiate everything manually etc. Which is probably a decent tradeoff for some folks.
There’s other alternatives like Avaje Inject and Quarkus which uses the same annotations but does the injection generation at compile time.
Re: Java Virtual Threads Preview
#210Earlier quoted context omitted.
It does no function coloring. Just block :). Virtual threads are preemptive not cooperative.
It doesn’t block, that’s the whole point. The runtime knows if a given method is blocking or not and under the hood even blocking IO calls are implemented with non-blocking IOs. So those can be preempted.
Yes I know. “Just block” refers to just waiting on virtual threads/futures via get or join. No fancy observables or callbacks etc.