5 ms·

Java's concurrency support is quite good. One of the best language level implementations I've used. It supports OS level threads and async. And they're adding s

Java's concurrency support is quite good. One of the best language level implementations I've used. It supports OS level threads and async. And they're adding support for fibers. At that point it will be the only mainstream language that supports all three popular models JS has an equally bad concurrency story as Ruby. Maybe even worse. There are no threads, you can only use a single core per instance. In practice the problem is ram. JS already uses a lot of ram compared to Java and running an instance for each core makes it way worse.IMO only crazy people run JS backends when there's so many other similar options

jiofih 6y ago
> JS has an equally bad concurrency story as Ruby. Maybe even worse. This is absolutely false. Yes, JS is single threaded, but all IO is async and happens via a worker pool. On top of that it is 3-10x faster than Ruby for most tasks due to the insane amount of development effort that went into the browser runtimes, it’s often within 50% of C speeds. And then the entire ecosystem is async. This is why you’ll see JS frameworks near the top of TechEmpower benchmarks achieving massive concurrency numbers, and also why nobody recommends any kind of CPU-heavy workload in node. Imagine Ruby came with Puma built-in, and all libraries only exported async interfaces.
- throwaway189262 6y ago
  Makes sense. Better than Ruby I guess. It's still not really concurrency, it just handles being single threaded better. JS is strange because of all the optimization. It's technically multi threaded with IO but in a way that you only control the "main thread". Reminds me of old UI work
  - coldtea 6y ago
    >It's still not really concurrency Well, it also has Workers, which is.
  - jiofih 6y ago
    Concurrency != parallelism. You can of course run a multi-process cluster, but that’s besides the point (and these days it’s best to run a single process inside orchestration like k8s). Basically almost every high performing server atm is running on some form of event loop / cooperative multi-tasking. Ruby Puma, Gunicorn, rust’s tokio and async/await, goroutines... Java is probably the big exception here (if you’re not using VertX et al) and we all know the pain of thread safety.
    - throwaway189262 6y ago
      Very true. Go is an exception, and some day Java will be as well. They're both going route of userspace threads instead of reactive API's, thankfully.
- zurn 6y ago
  By JS do you mean Node here? Node has both blocking and async versions of a lot of IO operations. But async IO is more commonly used certainly. The real question might be whether a thread pool backed async IO implementation makes your program do concurrent IO better than a GIL + blocking IO calls that release the GIL, it's not obvious to me. (Doesn't Node have threads too nowadays?)
  - jiofih 6y ago
    Almost no code uses node’s sync APIs unless explicitly asked to, its ingrained in developer practices to the same level as not polluting global scope. Node’s threads are for cases you really want to do heavy computation without resorting to another language. All the I/O is still backed by LibUV and an event loop, threads don’t really offer any improvement there.
kungito 6y ago
C# has them all already. Java has been lagging behind C# for a long while
- kaba0 6y ago
  Project Loom’s virtual threads will be superior to the random function coloring with async in C#. With it, you can write sync code and it will automatically change to another “fiber” when it hits IO or other blocking operation.
- throwaway189262 6y ago
  Java is very methodical about what features they add. Some of the sluggishness is intentional. As far as threading, Java is adding userspace M:N threads which will be far superior in most use cases to C#'s async. And unlike async it gives an automatic performance boost to most existing code C# has a long history of breaking changes. One of the reasons Java is more popular is 90% of decades old code runs fine on the newest version. Java's backwards compatibility is absolutely unmatched.

jiofih 6y ago

> JS has an equally bad concurrency story as Ruby. Maybe even worse. This is absolutely false. Yes, JS is single threaded, but all IO is async and happens via a worker pool. On top of that it is 3-10x faster than Ruby for most tasks due to the insane amount of development effort that went into the browser runtimes, it’s often within 50% of C speeds. And then the entire ecosystem is async. This is why you’ll see JS frameworks near the top of TechEmpower benchmarks achieving massive concurrency numbers, and also why nobody recommends any kind of CPU-heavy workload in node. Imagine Ruby came with Puma built-in, and all libraries only exported async interfaces.

throwaway189262 6y ago
Makes sense. Better than Ruby I guess. It's still not really concurrency, it just handles being single threaded better. JS is strange because of all the optimization. It's technically multi threaded with IO but in a way that you only control the "main thread". Reminds me of old UI work
- coldtea 6y ago
  >It's still not really concurrency Well, it also has Workers, which is.
- jiofih 6y ago
  Concurrency != parallelism. You can of course run a multi-process cluster, but that’s besides the point (and these days it’s best to run a single process inside orchestration like k8s). Basically almost every high performing server atm is running on some form of event loop / cooperative multi-tasking. Ruby Puma, Gunicorn, rust’s tokio and async/await, goroutines... Java is probably the big exception here (if you’re not using VertX et al) and we all know the pain of thread safety.
  - throwaway189262 6y ago
    Very true. Go is an exception, and some day Java will be as well. They're both going route of userspace threads instead of reactive API's, thankfully.
zurn 6y ago
By JS do you mean Node here? Node has both blocking and async versions of a lot of IO operations. But async IO is more commonly used certainly. The real question might be whether a thread pool backed async IO implementation makes your program do concurrent IO better than a GIL + blocking IO calls that release the GIL, it's not obvious to me. (Doesn't Node have threads too nowadays?)
- jiofih 6y ago
  Almost no code uses node’s sync APIs unless explicitly asked to, its ingrained in developer practices to the same level as not polluting global scope. Node’s threads are for cases you really want to do heavy computation without resorting to another language. All the I/O is still backed by LibUV and an event loop, threads don’t really offer any improvement there.

kungito 6y ago

C# has them all already. Java has been lagging behind C# for a long while

kaba0 6y ago
Project Loom’s virtual threads will be superior to the random function coloring with async in C#. With it, you can write sync code and it will automatically change to another “fiber” when it hits IO or other blocking operation.
throwaway189262 6y ago
Java is very methodical about what features they add. Some of the sluggishness is intentional. As far as threading, Java is adding userspace M:N threads which will be far superior in most use cases to C#'s async. And unlike async it gives an automatic performance boost to most existing code C# has a long history of breaking changes. One of the reasons Java is more popular is 90% of decades old code runs fine on the newest version. Java's backwards compatibility is absolutely unmatched.