[jeroenhd]

Virtual threading is fun and all until you find out SimpleDateFormat and a bunch of other classes built tight into your standard library aren't thread safe and now you need to go through your program and find out what else you missed. Go too has these fancy green threads at the cost of manually locking resources and finding out about race conditions when you forget about them.

Futures aren't a fundamental CS mistake, they're a design decision. You may disagree with that decision, but the advantage Rust brings is that you don't need to worry about thread safety once your program actually compiles, at the cost of different code styles.

Neither asynchronous processing design is fundamentally wrong, they both have their strengths and weaknesses.

[SpaghettiCthulu]

> Virtual threading is fun and all until you find out SimpleDateFormat and a bunch of other classes built tight into your standard library aren't thread safe and now you need to go through your program and find out what else you missed. Go too has these fancy green threads at the cost of manually locking resources and finding out about race conditions when you forget about them.

Why would that ever be an issue? Instances of those classes shouldn't be shared between virtual threads just the same as when using regular threads.

[peoplefromibiza]

> until you find out SimpleDateFormat and a bunch of other classes built tight into your standard library aren't thread safe

true, but DateTimeFormatter has been available since Java 8, released almost 10 years ago.

VirtualThreads will be available in Java tomorrow

Also: https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDa...