3 ms·
99% of which problem, though? IMO the whole point of Loom, and what I'm looking forward to, is code that looks like this: fooer.onCompletion(() -> System.out.p
by ye-olde-sysrq 3y ago
99% of which problem, though? IMO the whole point of Loom, and what I'm looking forward to, is code that looks like this:
fooer.onCompletion(() -> System.out.println("yay"));
fooer.onError(e -> System.out.println("o no"));
fooer.foo(); // foo is some long operation
can once again simply be:
try {
foo()
S.o.p("yay");
} catch(Exception e) {
S.o.p("o no");
}
just like any college kid would've written 20 years ago in their CS 101 class in the chapter on exceptions.
Many multi-threaded programs today don't even have a "communication among threads" problem. - they avoid it by simply not communicating between threads. They precompute work splits and then farm it out, and then gather up all the results. Consider HTTP servers or RPC handlers. A request is farmed out to them, they do a bunch of IO stuff to answer it, and then release their thread back to a pool. That's a huge use-case that gets materially improved right there. Look at what goroutines did for go programming.