Go is the prime example.

For example, in your typical web application a Goroutine is spawned for every incoming connection. This basically gives you a dedicated runtime for each simultaneous connection. In Node or Python, this would be the equivalent of starting a whole new process for every request. But in Go, there's very little cost to doing it this way.

The advantage is that each connection basically never blocks waiting for another user.

In Node and Python, we talk about handling tens to hundreds of requests per second per server.

In Go, we talk about handling thousands to tens of thousands per second. It's just orders of magnitude more throughput.

Can't comment on Python, but I once worked on a Node.js codebase that could only handle tens of requests per second, it was highly unusual and doing some incredibly dumb things like pinging out to Redis to check for DDOS protection counters before starting to serve any request.

See: https://www.fastify.io/benchmarks/

Node is more susceptible to poor code and out of band IO slowing it down, but the V8 runtime itself is cpp and simple services are close to just writing decorators over a cpp webserver. It's obscenely fast and good enough for most purposes.

Scala. With the functional effect systems, like Cats Effect or ZIO, you get superpowers.

Not only can write programs that are "async", but you also get easy retries (and other tricks), safe refactorability (because of its Pure FP nature), reliable and painless resource management and some other goodies like STM (Software transactional memory).

It's really that good.

https://www.youtube.com/watch?v=qgfCmQ-2tW0

https://zio.dev/

https://typelevel.org/cats-effect/

Haskell has always been the best. Go's did the same as Haskell. In either case IO is automatically async. If you want concurrency you create very light weight threads. This approach works very well for most use cases, but when you want the best performance possible the light weight threads can still be too much. Zig is going for a lowest possible overhead approach like Rust but has an interesting take: https://kristoff.it/blog/zig-colorblind-async-await/

Are you sure you are talking about Haskell and not Erlang? I'm not aware of how Haskell IO would be "automatically async".

That's definitely a description of GHC Haskell. All network IO in Haskell goes through a subsystem called the IO manager, which makes use of platform appropriate high-performance non-blocking APIs. (Actually, I think windows isn't getting an IOCP implementation until the next major release, but Windows has always been a bit undersupported by GHC.)

The nice thing about this is... You don't have to care. Haskell is a good enough programming language to just put the platform-specific non-blocking hell APIs in a library and let you write code that looks linear and blocking. If you want more control you can get down to the low level non-blocking APIs, but that's usually not going to be worth the trouble.

Yeah, many people don't even see a reference about Haskell IO being async. That's what the "automatic" part is doing.

Haskell IO is basically as async as Javascript, as in every operation is fully asynchronous, you need to call some foreign function if you want otherwise. Except that you have parallelism and can have concurrency too added if you want.

Interestingly, I've become a big fan of node's single-threaded "one big loop" model, which means multitasking is cooperative instead of preemptive. This strikes me as more honest, somehow. It doesn't distract you with abstractions (like threads) that don't make sense in this context. Most production workloads these days will be a docker process assigned to (at best) a single sticky core/thread on a blade somewhere - so in terms of resources, node is quite honest about what you actually have to work with. (This as opposed to, say, a Java process, which wants to believe it has control over an entire physical server CPU, and when you run it in a docker process, you're just exercising virtualization overhead if you use Thread, etc.)

That said, if you have a physical server, Java is quite good, especially with the upcoming Project Loom improvements. The langspec and vmspec have gotten fat the last 20 years, but at least those documents exist. Plus there is OpenJDK which is a great enabler and calmer of nerves; there's a reason so many alt langs target the JVM, and they are good. Groovy, Clojure, Kotlin, Scala are all first-rate languages, IMHO. And with projects like Quarkus you can more easily build native executables that bundle the JRE and make distribution very Rust-like.

Another environment I like specifically for async operation, but mostly by reputation, is Erlang and it's BEAM VM. Erlang itself is such an interesting language, being dynamic, functional, immutable, without traditional control structures (!) but relying heavily on recursion and pattern matching, and of course the "actor model" and extremely lightweight "processes" was invented here (and promptly ported to elsewhere, as with Akka). It was also created by one of the nicest human beings I've ever experienced, Joe Armstrong, may he rest in peace.

IANALL so YMMV.

> Plus there is OpenJDK

I'm not sure what you mean here, but if you refer to OracleJDK here then there is basically only OpenJDK for quite some time now -- OracleJDK is just an (optionally) paid support version of the same codebase. Also, most other vendors are pretty much just tiny patched OpenJDKs also, with some niche exceptions.

You must be young. Java was not always distributed like this, and although it was "open source" few people compiled it, and the JRE and JDK was distributed by Sun (then Oracle) primarily through a user interactive web UI. The OpenJDK existed alongside this for some time, but then supplanted the proprietary binaries. That was a relief because it meant Java was actually (not just theoretically) open source now, which meant it was safe from deprecation, disablement, and all the other negative aspects of control that come with de facto proprietary software.

I cannot, for the life of me, recommend Elixir enough! You write your code without every thinking of words like "async" or "await" and the VM handles it for you!

So this. You have to learn to think differently about your problem. But then when you do, so many of these other issues just go away. A small amount of our product offering is implemented in Elixir. I wish more of it was. It’s my favorite part of the whole thing.

Credit where it's due, this is all thanks to the BEAM and OTP being awesome.

Any language which is dataflow based will be great in an async context. Async is hard in most languages because they are imperative, which stands in stark contrast to the whole idea of asynchrony. This whole exercise of adding async features to various imperative languages is coming at the problem from the wrong way around in my opinion. It's a recognition that async programming is hard in imperative languages, and the thought is that maybe this could be made better with more language features. But the sad truth is that async features clash hard with the imperative nature of most mainstream languages.

Server workloads are different from client workloads here, and network/IO heavy workloads are different from CPU heavy workloads. You'll get tend to get misleading advice from people only familiar with one of them. Especially if the client is an asymmetric architecture like ARM has and Intel is moving to.

Swift's design is made to be good for IO workloads on smaller clients, though it hasn't got as many tools for the other end.

Go, Erlang, Scala, Pony.