The word “can” here translates to (potentially) decades of work, which was the case for Java:
Yes we “can” (and likely should), but it requires serious commitment, and off-hand “others do it too” is not helpful here.
In the context Java and threading, it’s worth noting how threads commonly need quite a lot of developer-facing infrastructure (e.g. thread pools) that’s probably very hard to make beginner-friendly / “Pythonic”, and that they’re on a similarly large multi-{year,person} effort to move from free threads to virtual threads[1] under Project “Loom” (where – arguably – the boundaries to async programming start getting blurred), and encapsulating a lot of that in simpler interfaces through “structured concurrency”, which we have already (at least through trio).
All that to say: if we argue “Java can”, then we should also look at where those choices have led them, and what they consider as “moving forward” from there. But realistically, we’re very far from an apples-to-apples comparison in any case, and it’s better to leave that rhetorical tool hanging in the shed.
latest incarnation in JDK 21 ↩︎