zlacker

>>jmakov+(OP)
I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not. There are quite a few situations where it makes the code easier compared to alternatives you could come up with.

I don't think for a second that async Rust should be picked for performance reasons.

You get a feeling for what is a good use of async and bad use of async relatively easily these days as the ecosystem is maturing.

>>the_mi+87
> I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not.

How do you know if what is best doesn't change as the project you're working on progresses and your manager tosses in new requirements?

I'd say better pick a technique (or even language) that works all the time.

>>ameliu+R8
There isn’t one technique that works all the time. Life is unfortunately about tradeoffs whenever you do something complex.

>>seanhu+pa
So choose a technique and language that least limits your design freedom.

Choosing performance as your #1 priority is often a bad idea as it gets you into a straight-jacket from the start, making everything else much more difficult and slows down development to a crawl. Unless you're developing an OS kernel perhaps. Computers are fast enough these days, let them do part of the work for you! And you can always write a faster version of your software when there is a demand for it.

>>ameliu+rc
> Choosing performance as your #1 priority is often a bad idea

You can write inefficient code and optimize it later.

> it gets you into a straight-jacket from the start, making everything else much more difficult and slows down development time to a crawl. Unless you're developing an OS kernel perhaps

The argument seems to break down: Surely you don't want to be in a strait-jacket if you're developing an OS kernel. Somehow Rust is equated with always being in a strait jacket.

The cost of writing highly concurrent programs is pretty much the same in every language except ones that have concurrency at the core (Erlang). I don't see much difference between starting with Java or Rust in terms of avoiding complexity caused by having to build things that a concurrent runtime could give to you for free.