3 ms·

No. That's nonsense. Everything is async in node because node is based on the V8 Javascript engine which is not thread safe. V8 is not thread safe because it wa

No. That's nonsense. Everything is async in node because node is based on the V8 Javascript engine which is not thread safe. V8 is not thread safe because it was designed for web browsers, and browser rendering engines are also not thread safe. People have tried to retcon node's choices as being based on some sort of deep technical justification, but that's not the case: its limits are the limits of the material it's made of, not a specific design choice. If you look at more advanced VMs like the CLR or JVM then they support all modes of operation: synchronous/blocking (which is often what you want), synchronous/blocking with many threads, async with callbacks, async with continuations ... node only supports one. How is that better?

edwinjm 10y ago
JavaScript was explicitly designed to use one thread and prevent all kinds of concurrency problems. It requires getting used to, but it's very powerful. Look at this page and tell me the JVM is better: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html https://docs.oracle.com/javase/7/docs/api/java/util/concurre...
- zigzigzag 10y ago
  Javascript was never explicitly designed to use one thread: it used one thread because Netscape used one thread. This is back in the 1990s when multicore on the desktop didn't exist and JS execution speed was a non issue. The page you linked to shows a full and complete library of concurrency tools, which you don't have to use if you don't want to. How is this evidence of being worse?
- dahauns 10y ago
  Sure, powerful. As long as you're mainly I/O-bound and shared-nothing. Oh, and your link actually DOES show that the JVM is better. It can give you everything node.js has and then some. If you want to see something like node.js for grown-ups, take a look at Vert.x or Akka (& Frameworks based on it), for example. (Sorry for the snark, it's been a long day...)
- Deinumite 10y ago
  That library is probably one of (if not the most) powerful concurrency libraries in existence.

edwinjm 10y ago

JavaScript was explicitly designed to use one thread and prevent all kinds of concurrency problems. It requires getting used to, but it's very powerful. Look at this page and tell me the JVM is better: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html https://docs.oracle.com/javase/7/docs/api/java/util/concurre...

zigzigzag 10y ago
Javascript was never explicitly designed to use one thread: it used one thread because Netscape used one thread. This is back in the 1990s when multicore on the desktop didn't exist and JS execution speed was a non issue. The page you linked to shows a full and complete library of concurrency tools, which you don't have to use if you don't want to. How is this evidence of being worse?
dahauns 10y ago
Sure, powerful. As long as you're mainly I/O-bound and shared-nothing. Oh, and your link actually DOES show that the JVM is better. It can give you everything node.js has and then some. If you want to see something like node.js for grown-ups, take a look at Vert.x or Akka (& Frameworks based on it), for example. (Sorry for the snark, it's been a long day...)
Deinumite 10y ago
That library is probably one of (if not the most) powerful concurrency libraries in existence.