4 ms·

I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to a

by ausjke 8y ago

I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to add event-loop and/or restful framework than making javascript looks like python/java one day as far as backend goes. In 2019 I still have 0 interest in javascript/TS for backend, the thousands of modules under node_modules alone is enough for me, and not all real world product need async/promise/callback/SPA, javascript is over-heated too much, not fun at all.

undersheet 8y ago
JS is not your daddy's JS anymore.
hombre_fatal 8y ago
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))
- beatgammit 8y ago
  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.
  - joelfolksy 8y ago
    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.

by ausjke 8y ago

undersheet 8y ago

JS is not your daddy's JS anymore.

hombre_fatal 8y ago

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))

beatgammit 8y ago
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.
- joelfolksy 8y ago
  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.