The melting pot of JavaScript (2017)

Re:The melting pot of JavaScript (2017) by hombre_fatal on Monday January 07, 2019 @06:18PM (#18851322)

You don't get to just add an event loop and start writing async code in Python or Java. It opens up its own can of worms now that you're straddling the sync and async worlds. Compare working with Netty (async) to Jetty (sync). It's certainly not trivial.

That Javascript is async-everything is one of its best and often overlooked features in these comparisons.

I think this snippet encapsulates a lot of why Javascript is actually very pleasant on the server:

    const results = await Promise.map(urls, (url) => process(url), { concurrency: 8 })
        .then((results) => postprocess(results))

[ Parent | on HN ]

Re:The melting pot of JavaScript (2017) by beatgammit on Tuesday January 08, 2019 @08:56PM (#18861658)

I don't think it is overlooked. JavaScript doesn't scale, both in terms of code complexity (callback hell) and across cores, and the "gold standard" these days is microservices, which has a ton of issues.

If you want to look at bolt-on async working, check out C# or Rust. They've basically taken JavaScript's new async/await and added threading (at least Rust has, not sure about C#). You can write an async app and have it run in a thread pool without much fuss.

I don't know what the story is for Java, but seeing as C# is effectively the same thing, it's not hard to imagine adding async being easier than adding threads or performance to JavaScript.

[ Parent | on HN ]

Re:The melting pot of JavaScript (2017) by joelfolksy on Wednesday January 09, 2019 @04:23PM (#18869039)

FYI, async/await (a promise type + async function decoration + await expressions) was actually invented by C#. It was designed to operate seamlessly with .NET's concurrency framework, the TPL, which uses a thread pool. So it was actually the case that Javascript took async/await and removed threading.

[ Parent | on HN ]