Just want to add on, although Node.js is very good for some of these, because of its single threaded nature, CPU intensive tasks can make it take a hit. Number crunching is one of the weak points of Node.js. This is because since Node.js is a single threaded application, if it is stuck resizing an image, then the server will be unable to respond to other requests. The way to get around this, is to rework the algorithm so that it is more event-based. There are various ways to do this, one of which will return a bunch of Promises with each having a small bit of the calculation to be done. This will allow Node.js to shallow the calculation a bit better. Another solution is to move the CPU intensive operation into another application/service, in which Node.js will call that. Node.js works best for small requests.
Now, allow me to talk to you about our Lord and Savior, Google. Google, in its infinite wisdom, has created a language called Go. Go is very much like C, except it has more modern concepts, such as concurrency and requests. Go handles concurrency by making it simple to create a goroutine, which can be created on a separate thread, or on the same thread, managed by the go scheduler. With that, you then use a channel to pass the calculated data back into the main routine. Also, it compiles down to machine language, instead of being interpreted, and also comes with its own garbage collector.
Node.js is very much a web server type of language, meaning it is good with quick requests. Go is a server language, as it is designed to handle concurrency a bit better, so it can handle longstanding requests.
Honestly, you should not tie yourself to one language, as they all have weak points. Do you just want to work on servers? What do you want to do on that server? I haven't even gone into application type languages, which you already have Java. There is also system languages such as C and Rust, if you need that memory control.
For me, I am currently happy with Go. JavaScript is interesting, but can be a bother, because you have to split your logic into chunks that it can shallow.