[rand_r]

Race conditions are generally solved with algorithms, not the language. For example, defining a total ordering on locks and only acquiring locks in that order to prevent deadlock.

I guess there there are language features like co-routines/co-operative multi-tasking that make certain algorithms possible, but nothing about Java prevents implementing sound concurrency algorithms in general.

[mrkeen]

> Race conditions are generally solved with algorithms, not the language. For example, defining a total ordering on locks

You wouldn't make that claim if your language didn't have locks.

[brabel]

Exactly, this thread is full of ignorant comments. I was talking about a certain class of race conditions that can be completely prevented in some languages, like Rust (through its aliasing rules that just make it impossible to mutate things from different threads simultaneously, among other things) and languages like Pony, for example, as the language uses the Actor model for concurrency, which means it has no locks at all (it doesn't need them), though I mentioned Dart because Dart Isolates look a lot like Actors (they are single-threaded but can send messages and receive messages from other "actors", similarly to JS workers).

[rand_r]

Not sure what you mean!? Locks, at their core, are not implemented by languages. They’re feature of a task runtime e.g. Postgres advisory locks or kernel locks in a Posix OS.