Um, yes. I've been trying to talk the "async" crowd down from making libraries async only. Rust has real threads and real concurrency. Both work, but mixing them gets complicated, although it's still safe. Async gets in the way with highly parallel programs.
As I've said before, while I mostly write Rust at this point, I'd suggest Go for server side web stuff. GC won't kill you there, and it's a simpler language with a more user friendly concurrency model. The neat thing about goroutines is that they cover the use case for both async and threads.
On the Go side, most of the libraries needed for web stuff come from Google and were written for their internal use, so they're of reasonably high quality and well-exercised. What we don't need in the Rust crate library are a large number of crates which do roughly the same thing in different ways, with different bugs.
It takes forever to clean up stuff like that. A decade ago, I noted that Python had standard library functions for generating RFC 3339 timestamps ("2012-09-09T18:00:00-07:00") but no standard parsing function for them. There were five different packages with parsing functions for that format, each with different bugs. So I suggested standardizing this.[1] After six years of intense bikeshedding, it was finally put in standard "datetime" in 2018.
> Um, yes. I've been trying to talk the "async" crowd down from making libraries async only.
There's no such thing as "async only" in Rust. You can always run tasks synchronously using block_on. Rust uses a principled approach to resolve the "function color" issue for async.
As I've said before, while I mostly write Rust at this point, I'd suggest Go for server side web stuff. GC won't kill you there, and it's a simpler language with a more user friendly concurrency model. The neat thing about goroutines is that they cover the use case for both async and threads. On the Go side, most of the libraries needed for web stuff come from Google and were written for their internal use, so they're of reasonably high quality and well-exercised. What we don't need in the Rust crate library are a large number of crates which do roughly the same thing in different ways, with different bugs.
It takes forever to clean up stuff like that. A decade ago, I noted that Python had standard library functions for generating RFC 3339 timestamps ("2012-09-09T18:00:00-07:00") but no standard parsing function for them. There were five different packages with parsing functions for that format, each with different bugs. So I suggested standardizing this.[1] After six years of intense bikeshedding, it was finally put in standard "datetime" in 2018.
[1] https://github.com/python/cpython/issues/60077