8 ms·

I mean Java's Loom feels like the 'ultimate' example of the latter for the _ordinary_ programmer, in that it effectively leaves you just doing what looks like c

by tekacs 6mo ago

I mean Java's Loom feels like the 'ultimate' example of the latter for the _ordinary_ programmer, in that it effectively leaves you just doing what looks like completely normal threads however you so please, and it all 'just works'.

ysleepy 6mo ago
Java has gone full circle. Java had green threads in 1997, removed them in 2000 and brought them back properly now as virtual threads. I'm kinda glad they've sat out the async mania, with virtual threads/goroutines, the async stuff just feels like lipstick on a pig. Debugging, stacktrackes etc. are just jumbled.
- gf000 6mo ago
  I don't think comparing 97's green threads to virtual threads ever made sense. Like their purpose/implementation everything is just so different, they don't share anything at all.
- delusional 6mo ago
  Java didn't really "sit it out". It launched CompletableFutures, CompletionStages, Sources and Sinks, arguably even streams. All of those are standard library forms of async programming. People tried to make it catch on, but the experience of using it, The runtime wrapping all your errors in completion exceptions, destroying your callstacks, just made it completely useless.
  - jen20 6mo ago
    Every Java codebase using something like Flux serves as a datapoint in favor of this argument - they're an abomination to read, reason about or (heaven help) debug.
- iknowstuff 6mo ago
  In Rust debugging and stacktraces are perfectly fine because async/futures compile to a perfect state machine.
  - comex 6mo ago
    They are not perfectly fine. If a task panics then you will get the right stack trace, but there is no way to get a stack trace for a task that’s currently waiting. (At least not without intrusive hacks.)
    - tcfhgj 6mo ago
      Would this be considered an intrusive hack? https://docs.rs/tokio/latest/%20tokio/runtime/struct.Handle.html#method.dump https://docs.rs/tokio/latest/%20tokio/runtime/struct.Handle....
      - f33d5173 6mo ago
        > This functionality is experimental, and comes with a number of requirements and limitations. I assume that answers your question.
        tcfhgj 6mo ago
        So once it's out of the experimental stage it won't be an intrusive hack anymore?
- rwoerz 6mo ago
  They stopped at the Promises level with CompletableFuture that lead to "colored frameworks" like WebMVC vs. WebFlux in Spring.
  - Sankozi 6mo ago
    Who is they? Java has moved past those promise based API and avoided async/await mistake.
sqquima 6mo ago
I'm curious how escape analysis works with virtual threads. With the asynchronous model, an object local to a function will be migrated to the old generation heap while the external call gets executed. With virtual threads I imagine the object remains in the virtual thread "stack", therefore reducing pressure in garbage collection.
Rapzid 6mo ago
The initial Loom didn't really provide the semantics and ergonomics of async/await which is why they immediately started working on structured concurrency. And for my money I prefer async/await to the structured concurrency stuff..

by tekacs 6mo ago

ysleepy 6mo ago

Java has gone full circle. Java had green threads in 1997, removed them in 2000 and brought them back properly now as virtual threads. I'm kinda glad they've sat out the async mania, with virtual threads/goroutines, the async stuff just feels like lipstick on a pig. Debugging, stacktrackes etc. are just jumbled.

gf000 6mo ago
I don't think comparing 97's green threads to virtual threads ever made sense. Like their purpose/implementation everything is just so different, they don't share anything at all.
delusional 6mo ago
Java didn't really "sit it out". It launched CompletableFutures, CompletionStages, Sources and Sinks, arguably even streams. All of those are standard library forms of async programming. People tried to make it catch on, but the experience of using it, The runtime wrapping all your errors in completion exceptions, destroying your callstacks, just made it completely useless.
- jen20 6mo ago
  Every Java codebase using something like Flux serves as a datapoint in favor of this argument - they're an abomination to read, reason about or (heaven help) debug.
iknowstuff 6mo ago
In Rust debugging and stacktraces are perfectly fine because async/futures compile to a perfect state machine.
- comex 6mo ago
  They are not perfectly fine. If a task panics then you will get the right stack trace, but there is no way to get a stack trace for a task that’s currently waiting. (At least not without intrusive hacks.)
  - tcfhgj 6mo ago
    Would this be considered an intrusive hack? https://docs.rs/tokio/latest/%20tokio/runtime/struct.Handle.html#method.dump https://docs.rs/tokio/latest/%20tokio/runtime/struct.Handle....
    - f33d5173 6mo ago
      > This functionality is experimental, and comes with a number of requirements and limitations. I assume that answers your question.
      - tcfhgj 6mo ago
        So once it's out of the experimental stage it won't be an intrusive hack anymore?
rwoerz 6mo ago
They stopped at the Promises level with CompletableFuture that lead to "colored frameworks" like WebMVC vs. WebFlux in Spring.
- Sankozi 6mo ago
  Who is they? Java has moved past those promise based API and avoided async/await mistake.

sqquima 6mo ago

I'm curious how escape analysis works with virtual threads. With the asynchronous model, an object local to a function will be migrated to the old generation heap while the external call gets executed. With virtual threads I imagine the object remains in the virtual thread "stack", therefore reducing pressure in garbage collection.

Rapzid 6mo ago

The initial Loom didn't really provide the semantics and ergonomics of async/await which is why they immediately started working on structured concurrency. And for my money I prefer async/await to the structured concurrency stuff..