That's not a contradiction. He's saying that later when you need multithreading you can add it. You generally don't start with it. Of course for some projects you know up front you'll need multithreading but the point is that that isn't the default position.
Yes it is. Spinning up another process is not multithreading, like, literally. It’s multiprocess. I never cease to be amazed with the complete lack of basic CS literacy from JS script kiddies.
I was using "multithreading" as a shorthand for "making use of multiple CPU hardware threads".
Async is and probably will always be less usable than blocking Rust. It is a very, very useful mode of operating when you really need two of its biggest benefits: lightweight cooperative concurrency and task cancellation, but it comes at a big usability cost. Rust software should use async tactically - in places where it is needed. Unfortunately handling http, which is a large part of many applications is actually a…
Your CRUD web application server almost certainly doesn't need async Rust. Using a blocking HTTP server is not "might be a good idea", it simply is a good idea. I recommend Rouille for this: https://github.com/tomaka/rouille . In case you are worried about performance, check the benchmark. Blocking Rouille is faster than builtin async server in Node.js.
Yes, but since Rust ecosystem went all in on async http, you'll have to use some niche http framework, and dumb CRUD code is not going to suffer too bad from async's limitations.
I really wish there was a popular and community embraced blocking http framework in Rust, to tip the scales here a bit.
You have it backward. The compiler should implicitly add the awaits for waitable objects, unless an operation is explicitly async. So you would write (in pseudocode): Task PlaceOrder(Order order) { SaveOrder(order); DeductItems(order); SendConfirmationEmail(order); } And the compiler will implicitly await all three operations (and ideally infer that your function is async). If you want to overlap computation, you avo…
I appreciate the original comment by ikekkdcjkfke, and your elaboration, gpderetta. However, I perceive a distinction between compiler optimization and proposing a fundamentally different model for handling asynchronicity. It seems to me that what you're suggesting deviates significantly from the existing C# model. Transitioning to this model wouldn't be a simple matter of compiler optimization—it would be a major br…
To clarify what I was trying to argue for, if one is using the .net async Task system only for the purpose to help the thread pool (always immediately awaiting an async method) then the responsibility should bear more on the .net framework, instead of spilling async/await Task into code bases. I don't know what a solution looks like, but maybe just threads are too expensive in .net