Hacker News Reader

Comment by throwaway189262 | Hacker News Reader

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

View on HN

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

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

>It's still not really concurrency

Well, it also has Workers, which is.

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.

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.

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

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.

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

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.

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.

Reply on news.ycombinator.com