I think concurrency support is underestimated today. It is so sad to see so many people say "concurrent programming is hard" when it is often trivial if you use an Executor -- meanwhile many languages push snake oil solutions such as Actors that usually don't work, that is, either you get a different answer every time you run them, or you only wind up with a 2x speedup when you have 16 cores.
The idea that you can build systems with a limited number of types and operations is workable for many kinds of programming but it is absolute death for concurrent and distributed program. If you have 100 threads and you want them all to stop for synchronization and get woken up simultaneously, Java has a primitive for that. If you take that out of the toolbox then concurrent programming is easy, if you think for moral reasons it is better to write your own, you're screwed.
When I started coding in Java I expected pthreads to 'just not work', just as I could never trust locks in POSIX. Instead of chasing CS research fads, Java has always been pragmatic. It also helps that Java has a xenophobia that distrusts native code, so Java started on day one with the concurrency features you need and a standard library you could trust 100% and led people to create a huge mass of concurrency friendly open source software in Java.
cratermoon · 15h ago
The original Java primitives for concurrency were at a level too low for easy correctness. Threads and Runnables were tedious to use and subject to errors. When Doug Lea's work was incorporated as the java.util.concurrent package in JSR166 the language gained well-defined atomic operations and a medium-level API for developers.
PaulHoule · 15h ago
Granted. I think synchronized was not such a great idea, in fact it's a lot like the bad ideas you see in other languages. I was coding Java back when you had to go to NASA's website to get a clear explanation of the module system and we went through all the stages of: "make every method synchronized", "discover a synchronized method call is 6x slower than a plain method call", "have a global discipline for threads and use synchronized concurrently"
But that's how Java is different from other languages. When a difficult to fix problem turns up in Java (like the original busted memory model), Java has a solution a decade before C++. Strange and obscure problems in Java are taken seriously whereas PHP, Pyhthon and the like may have the same problem and say "come in, the water's fine"."
The idea that you can build systems with a limited number of types and operations is workable for many kinds of programming but it is absolute death for concurrent and distributed program. If you have 100 threads and you want them all to stop for synchronization and get woken up simultaneously, Java has a primitive for that. If you take that out of the toolbox then concurrent programming is easy, if you think for moral reasons it is better to write your own, you're screwed.
When I started coding in Java I expected pthreads to 'just not work', just as I could never trust locks in POSIX. Instead of chasing CS research fads, Java has always been pragmatic. It also helps that Java has a xenophobia that distrusts native code, so Java started on day one with the concurrency features you need and a standard library you could trust 100% and led people to create a huge mass of concurrency friendly open source software in Java.
But that's how Java is different from other languages. When a difficult to fix problem turns up in Java (like the original busted memory model), Java has a solution a decade before C++. Strange and obscure problems in Java are taken seriously whereas PHP, Pyhthon and the like may have the same problem and say "come in, the water's fine"."