Comment by hackit2 | Hacker News Reader

Comment by hackit2 | Hacker News Reader

Parent Full thread

In defense of Java blocking calls, in the 1990s to the 2010's the industry mostly considered Asynchronous programming as coordinating multiple threads over know yield points - such as using atomic locks, or mutexs. The main push by the industry was all about abstractions and OOP, and moving away from static C/C++ programming languages to dynamic programming languages such as Java/Python/Visual Basic or C#.

It is only until recently with the popularity of Node.js, Python and the explosion of the web that the developer have to deal with single threaded languages that blocking calls are a significant impact to the users experience. This push for Async in the web has had a cascade effect to system programming languages where old time developers are only first learning about it.

Could you clarify the "static C/C++" vs "dynamic Java" distinction? I'm used to thinking of "static" and "dynamic" in the context of type systems, but do the terms have overloaded meanings in concurrency/parallelism?

The push for async as we know it started in .NET, initially with F# and then popularized by C#, with the pattern then adopted by JS, Swift, Python, Rust and other languages. The implementations, however, are wildly different.

I thought F# was a derivative of OCamel that focused exclusively on immutable data structure and functional programming, instead of mutable/imperative languages.

https://www.microsoft.com/en-us/research/publication/the-f-a...

It was also pushed by the C10K movement.

True, one great thing that did come out from it is that the language needs to natively support asynchronous programming with syntactical sugar otherwise you get an explosion of libraries/frameworks that solve the problem with their own problems. How-ever this is a chicken/egg problem, did everyone really need async or did it come about because the proliferation of frameworks to solve this common pattern?

Reply on news.ycombinator.com