Yep, I agree. I tend to be a type system maximalist: I'd rather have everything that is possible to encode statically be encoded statically, even if it leads to less flexibility later.

If you're starting a new Java codebase from scratch, you can create the structure where the language doesn't using classes, but it'd be nice to have syntactic support for it.

This property is not really part of the type system though.

Also, as mentioned by another commenter below - is a file exists operation async? Sync? Why, why not?

What if file exists operation MUST be sync?

Then you don’t start it in a virtual thread. Your calls automatically become blocking or not blocking depending on your callsites, which is the proper place to decide that.

So it still has colors?

In TypeScript at least, async-ness is encoded in the type system, because async/await is just syntactic sugar for Promise/then/catch.

Well, JS is paired with a single-threaded execution model, so you only have concurrency to worry about. C#, Java has proper multithreading as well, that gives another dimension to the problem.

Kotlin has multithreading, and it also puts `suspend` in the type system.

Some more examples: Rust, Python (with most/all? type checkers), C# all bake this into their type systems.

This is more due to the fact that Kotlin doesn’t control its backend and is designed to work with a language that already includes this model, js.

Very simple - in Java, almost any IO operation in blocking. Exceptions are the stuff in the NIO package, thread interruption and signalling, and maybe process termination.

I wonder if we'll see Lombok markup for @OnVirtualThread or whatever the pattern shakes out to be.

Lombok is unfortunately a separate programming language, albeit insufficiently distinct from Java.

(Why? Because it uses internal compiler APIs to change the behaviour of code you write in ways that are not valid: annotation processors are supposed to generate new classes, not mutate existing classes.)

I went looking on their because for some reason I thought that an `@Async` annotation would already exist. But no such luck.

If you want to use something like this today, then you could take a look at Spring 's Async support. It also lets you supply the Executor.