4 ms·
> distinguish between things that aren't meaningfully distinguishable. Are these semantically the same? Runnable action1 = () -> System.out.println("foo");
by mrkeen 6y ago
> distinguish between things that aren't meaningfully distinguishable.
Are these semantically the same?
Runnable action1 = () -> System.out.println("foo");
Runnable action2 = () -> System.out.println("bar");
action1.run();
action2.run();
var action3 = runAsync(() -> System.out.println("foo"));
var action4 = runAsync(() -> System.out.println("bar"));
action3.join();
action4.join();
> You only need to submit if you want to do stuff in parallel and then join (also, there are no extra steps).
I'm not comparing parallel to sequential. My point was that we're already doing parallel programming:
CompletableFuture<Result> fx = CompletableFuture.supplyAsync(() -> result);
CompletableFuture<Result> fy = CompletableFuture.supplyAsync(() -> result);
Result x = fx.join();
Result y = fy.join();
Parent doesn't like the existing parallel model. New model looks like:
// > plus no need for thread pools anymore.
ThreadFactory tf = Thread.builder().virtual().factory();
ExecutorService e = Executors.newUnboundedExecutor(tf);
// > No more [...] Completable<Future>, promises et al.
Future<Result> fx = e.submit(() -> { ... return result; });
Future<Result> fy = e.submit(() -> { ... return result; });
Result x = fx.get();
Result y = fy.get();
If going from the first to the second is an improvement, I don't understand the excitement. Especially when other languages look like:
fx <- async (return 3)
fy <- async (return 3)
x <- wait fx
y <- wait fy
- pron 6y ago> Are these semantically the same? No, but that's not what I meant. These are semantically the same: action1sync(); action2sync(); await action1async(); await action2async(); > If going from the first to the second is an improvement, I don't understand the excitement. The excitement is about going from my second example to the first. > Especially when other languages look like: It doesn't matter what they look like in the code. They suffer from all the problems I mention in the article: exceptions lose context, debuggers and profilers lose their effectiveness, APIs are split into two disjoint worlds. Virtual threads gives you code that doesn't just look synchronous, but behaves like that in every observable way. What the code looks like on the screen is a very small portion of the problem we're trying to solve.