3 ms·

Rust could never have had easy async like Go, though, and maintain the control of performance that is the whole point of Rust.

skohan 5y ago
Yeah maybe not like go, but it's not impossible to imagine that you could create a language from the ground up with a rust-like ownership model and some async model - maybe not async await precisely.
fulafel 5y ago
Rust had GC in earlier versions, see eg http://web.archive.org/web/20130607161259/http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ http://web.archive.org/web/20130607161259/http://pcwalton.gi...
- kibwen 5y ago
  Yes, and (to be clear to people who don't click your link) it was removed for exactly the reason that the parent commenter mentioned. Rust's lack of a pervasive GC is not intended to suggest that GC is not generally useful (even in a systems context), only that it's too difficult to satisfy the sort of extreme control that people demand of a low-level language if they are forced to find ways to work around the pervasive GC. Which is to say, you need a way to turn off the GC, and if you can function with the GC off, then maybe you should push that as far as you can get away with, which is what Rust did.
  - skohan 5y ago
    Yeah I have done some work trying to optimize code written in GC'd runtimes, and eventually you will hit a wall. GC is great for a lot of use-cases: for instance if I am writing a server-less application with mostly lambdas/cloud functions which pull data from a database and serve it to an HTTP response, the productivity gains you get with a nice high-level language will more than make up for a few pennies you might pay for a tracing garbage collector to run, and it's going to be plenty fast enough. But when you have a case where every cycle/byte of memory counts, the GC is going to get in the way. Of course stop-the-world collectors are a catastrophe for performance, but even with modern generational GC it's essentially a part of your program's execution you didn't write and you have at best arms-reach control over which dictates hugely performance-impacting aspects of execution like memory layout. Some GC'd languages have escape hatches to manipulate the GC process directly, but even those feel a bit like trying to drive a nail by hammering it with the butt of a screwdriver.

skohan 5y ago

Yeah maybe not like go, but it's not impossible to imagine that you could create a language from the ground up with a rust-like ownership model and some async model - maybe not async await precisely.

fulafel 5y ago

Rust had GC in earlier versions, see eg http://web.archive.org/web/20130607161259/http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ http://web.archive.org/web/20130607161259/http://pcwalton.gi...

kibwen 5y ago
Yes, and (to be clear to people who don't click your link) it was removed for exactly the reason that the parent commenter mentioned. Rust's lack of a pervasive GC is not intended to suggest that GC is not generally useful (even in a systems context), only that it's too difficult to satisfy the sort of extreme control that people demand of a low-level language if they are forced to find ways to work around the pervasive GC. Which is to say, you need a way to turn off the GC, and if you can function with the GC off, then maybe you should push that as far as you can get away with, which is what Rust did.
- skohan 5y ago
  Yeah I have done some work trying to optimize code written in GC'd runtimes, and eventually you will hit a wall. GC is great for a lot of use-cases: for instance if I am writing a server-less application with mostly lambdas/cloud functions which pull data from a database and serve it to an HTTP response, the productivity gains you get with a nice high-level language will more than make up for a few pennies you might pay for a tracing garbage collector to run, and it's going to be plenty fast enough. But when you have a case where every cycle/byte of memory counts, the GC is going to get in the way. Of course stop-the-world collectors are a catastrophe for performance, but even with modern generational GC it's essentially a part of your program's execution you didn't write and you have at best arms-reach control over which dictates hugely performance-impacting aspects of execution like memory layout. Some GC'd languages have escape hatches to manipulate the GC process directly, but even those feel a bit like trying to drive a nail by hammering it with the butt of a screwdriver.