Hacker News Reader

Comment by royjacobs | Hacker News Reader

It's consistently been impressive to me how thoughtful the Java language is being steered. Especially the explicit choice to NOT have an async keyword where other languages were all falling over themselves to add it, with all the complexity it entails (and in Rust it's a pretty awkward fit).

Once projects Valhalla and Panama land Java will be transformed again. Exciting times.

View on HN

I think async worked out pretty well with JavaScript. But that was added to an already async language, it was just verbose and awkward before the await keyword.

In what way was the language async? It has no threads outside workers, which have strict limits regarding data sharing. You would see a lot of code that registers callbacks as event handlers, but I don't think that makes the language async. That's just the nature of event handlers. They are invoked later, when the event happens.

In a way, the lack of threading allowed `async` to be implemented without gotchas. In languages with first-class thread support, `async` implementations can run into thread issues. (Will the continuation run on the same thread? Does the code care?)

I think you have async mixed up with concurrency / parallelism. Async is all about events as opposed to blocking wait. As an example, Java had predominantly sync programming model, because the thread would be block-waiting for stuff, no matter the fact there can many such threads block-waiting.

I don't think so. Any language that had event handlers would be just as "async" as the OG javascript. First class thread support matters because sometimes it matters which thread the event/continuation runs on.

Async and multithreading are not the same thing. Async is about non-blocking execution between functions.

JavaScript is inherently async because the concept of the event loop is baked into the very language runtime itself.

In Java you can achieve a single threaded async runtime by instantiating a SingleThreadExecutor and having all your application code running as jobs posted to this executor. But because you can opt out of this model or use something like a ThreadPoolExecutor it's harder to bake in an `async` keyword into the language that is as simple as you have in JavaScript.

I know they're not the same thing. But first class thread support can make asynchrony harder to implement since it sometimes matters which thread the continuation runs on.

> JavaScript is inherently async because the concept of the event loop is baked into the very language runtime itself.

Ok, I hadn't thought about it this way. Early UI frameworks for java had this property as well. I don't know about the implementation. But there was some kind of message loop running, and you'd register event handlers, and events would get dispatched to your handlers.

You could argue that was the framework, not the language. Maybe I'm wrong, but I think of the message loop as being a property of the execution environment (DOM/node) rather than the language. Maybe that's not a real distinction though.

Sounds like parent was using async to mean that JS has single-threaded concurrent functions by default.

Disclaimer: I'm just the messenger here so you might hate what follows, the community is choosing the words.

Concurrency as a keyword is increasingly being used to differentiate single-threaded event handling from parallel processing (threads). As long as event handling is quick enough, it can give the illusion of parallel processing. And in some cases it can outperform parallel processing because the cost of context switching between events can be lower than context switching between threads. See https://medium.com/@caophuc799/nginx-architecture-and-why-ca...

The async keyword, in practice, simplifies the callback boilerplate required to handle the event model. When used in communication, async is increasingly being used as a word to describe "Single-threaded Concurrent Functions Built On Hidden Event Handling", because there is no succinct way of saying STCFBOHEH in English.

So: JS has async/STCFBOHEH/context-switching on its functions by default whereas Java's functions are (by default) executed in order without async/STCFBOHEH/context-switching.

I'm not an expert or anything, but I've never seen an implementation of event handling that was anything other than STCFBOHEH. (hadn't heard the term)

My understanding of "async" as a language feature is basically support for an `await` keyword. Having a message loop and event dispatcher seems like a less useful definition, but good to know, I guess.

Reply on news.ycombinator.com