Hacker News Reader

Comment by gf000 | Hacker News Reader

> And thousands of manual get/set functions don't?

By definition, they don't.

They are verbose and hard to maintain, but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you.

> But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and...

No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds

View on HN

> but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you.

So do properties in C# which object initialization relies on. With significantly less manual code, or the need for tedious builder chains and withers.

`{ prop = x }` is no more encapsulation breaking than ` .setProp(x) `, but actually makes developer experience better.

> No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds

What's Java's equivalent of

   x = await someFunction()
   await waitForSomeOtherFunction()

If the two calls are sequential then simply:

  var x = someFunction()
  someOtherFunction()

If you would have written

  var xTask = SomeFunctionAsync();
  await WaitForSomeOtherFunctionAsync();
  string x = await xTask;

then it would be:

  try (var scope = StructuredTaskScope.open()) {   // JDK 24+ preview feature 
      var x = scope.fork(() -> someFunction());
      scope.fork(() -> waitForSomeOtherFunction());
      scope.join();
      String result = x.get(); // already completed 
  }

await implies async functions.

Looks like Java's "there is no simpler syntax than plain old synchronous code" is just a lot of extra manual wrangling of stuff

And the first two lines are an async function as they are, without any special handling.

They won't block the thread, and you can have millions of them.

Like it's no accident that c# with their goldfish attention span wanted to ship virtual threads as well next to all their millions of features.

Strangely enough virtually no materials on the internet show that. Everything is Executors, and Futures, and joins etc.

Concurrency != parallelism

I hope you know and understand the difference. Then strangely enough all my examples will make sense.

Reply on news.ycombinator.com