4 ms·

I take the opposite tack. Who, precisely is clamoring for this? Why not "let 100 flowers grow" (present condition) and allow the various solutions to mature t

I take the opposite tack. Who, precisely is clamoring for this? Why not "let 100 flowers grow" (present condition) and allow the various solutions to mature to the point that a de facto standard emerges? The claim is made: "choosing a runtime locks you into a subset of the ecosystem," to which I answer, "So, what?" If I want to log my server events or take advantage of a protocol encoding method or compress my data -- all of these and every other "big" choice I make locks me into a similar library ecosystem niche. I despise this "everything's amazing and nobody's happy" vibe. The async library authors have plenty on their plates without some sub-committee crashing in and dictating their features and release schedules. By the way, using Go as an example is a joke since -- from the early Go bootcamp I attended in 2014, the best practice has been to use a 3rd-party http router (these days: gorilla? httprouter? chi? etc) instead of the one provided in the standard library. Instead of being _told_ what to use, let's get back to being interested enough that we read the docs, take in the reviews & benchmarks, and decide for ourselves.

pornel 5y ago
The portability is needed to let many runtimes grow without pains of fragmentation. Currently tokio dominates, and you either use tokio, or you lose access to a large portion of the ecosystem. This doesn't have to be a blessed runtime in std, but could be just a set of common interfaces (basics like AsyncRead, sleep, and spawn), so that async crates don't have to directly depend on a specific runtime.
justsomeuser 5y ago
The issue is that the async await keywords are part of the standard language but then you are forced to pick an non-standard runtime. Your Go example is not quite comparable: Go: (Lang, libs) - You can mix and match any libraries. Rust: (Lang, runtime, libs) - Now you can only choose the libraries for your runtime. This dilutes the time investment of crate developers and the utility of Cargo crates, as you want a general async thing but it is tied to a specific runtime. I think the Rust team should of included a solid zero config runtime but allow it to be replaced.
throwaway894345 5y ago
> By the way, using Go as an example is a joke since -- from the early Go bootcamp I attended in 2014, the best practice has been to use a 3rd-party http router (these days: gorilla? httprouter? chi? etc) instead of the one provided in the standard library. You're mistaken. Using a third party router doesn't lock you into a particular subset of the ecosystem. E.g., I tend to use the Gorilla router by default, but I can use it with any middleware that implements the standard http.Handler interface.

pornel 5y ago

The portability is needed to let many runtimes grow without pains of fragmentation. Currently tokio dominates, and you either use tokio, or you lose access to a large portion of the ecosystem. This doesn't have to be a blessed runtime in std, but could be just a set of common interfaces (basics like AsyncRead, sleep, and spawn), so that async crates don't have to directly depend on a specific runtime.

justsomeuser 5y ago

The issue is that the async await keywords are part of the standard language but then you are forced to pick an non-standard runtime. Your Go example is not quite comparable: Go: (Lang, libs) - You can mix and match any libraries. Rust: (Lang, runtime, libs) - Now you can only choose the libraries for your runtime. This dilutes the time investment of crate developers and the utility of Cargo crates, as you want a general async thing but it is tied to a specific runtime. I think the Rust team should of included a solid zero config runtime but allow it to be replaced.

throwaway894345 5y ago

> By the way, using Go as an example is a joke since -- from the early Go bootcamp I attended in 2014, the best practice has been to use a 3rd-party http router (these days: gorilla? httprouter? chi? etc) instead of the one provided in the standard library. You're mistaken. Using a third party router doesn't lock you into a particular subset of the ecosystem. E.g., I tend to use the Gorilla router by default, but I can use it with any middleware that implements the standard http.Handler interface.