async-std VS rust

But maybe check out the discussion here https://github.com/async-rs/async-std/pull/631 or something (the blog post was linked on the end of it)

Have a look at these: https://github.com/async-rs/async-std/tree/main/examples

In fact, there are a lot of crates in Rust where in other programming languages, it would be included in the standard library. Examples are regex, random number generators, additional iterator methods, macros for other collections, num traits, loggers, HTTP libraries, error handling, async runtimes, serialization and deserialization, date and time, and many more.

Two major projects (non std lib but extremely commonly used) stand out in the area of async programming: Async std and Tokio - no doubt familiar to anyone that has turned an eye towards Rust for a second too long. Async architecture in general is likely very familiar to JavaScript programmers but in Rust there are some extra considerations (like ownership of the data that is thrown into an async function). Tokio is fast becoming a heavily supported and road tested async framework, with a thread scheduling runtime "baked in" that has learned from the history of Go, Erlang, and Java thread schedulers.

Ah... https://github.com/tokio-rs/tokio and https://github.com/async-rs/async-std ?

async-std: Basically a Tokio alternative with a few different design decisions.

Go's solution is for the scheduler to notice after a while when a goroutine has blocked execution and to shift goroutines waiting their turn to another thread. async-std pondered a similar approach with tasks, but it proved controversial and was never merged.

This indicates curl, zlib, openssl, and libnghttp2 as well as a bunch of WASM-related things are being dynamically linked into my executable. To resolve this, I looked at the build features exposed by surf and found that it selects the "curl_client" feature by default, which can be turned off and replaced with "h1-client-rustls" which uses an HTTP client backed by rustls and async-std and no dynamically linked libraries. Enabling this build feature removed all -sys dependencies from androidx-release-watcher, allowing me to build static executables of it.

And also, the actual PR never got merged.

Async in rust needs a runtime (aka executor) to run. You can maybe get a better description from the rust docs. As an example, Tokio attempts to provide an interface for a developer that is minimal change to the more common blocking code. So you'd end up putting #[tokio::main] above your main function to spin up the executor and most of the rest of the code is similar to a non-async version with a few sprinkles of .await, which you can see in the hello world for tokio. In contrast, async-std provides a more hands-on/low-level approach. If you are unlucky enough to have libraries that choose different stacks to work on, you'll possibly (probably?) have to handle both.

> There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust

You are responding to one of the key developers of Rust early on[1], who's been working with the language for 14 years at that point.

[1] https://github.com/rust-lang/rust/graphs/contributors?from=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.

If you haven't dipped your touch-typing fingers into Rust yet, you really owe it to yourself. Rust is a modern programming language with features that make it suitable not only for systems programming -- its original purpose, but just about any other environment, too; there are frameworks that let your build web services, web applications including user interfaces, software for embedded devices, machine learning solutions, and of course, command-line tools. Since a custom GitHub Action is essentially a command-line tool that interacts with the system through files and environment variables, Rust is perfectly suited for that as well.

Here's an example of someone citing a disagreement between CRT and shell32:

https://github.com/rust-lang/rust/issues/44650

This in addition to the Rust CVE mentioned elsewhere in the thread which was rooted in this issue:

https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

Here are some quick programs to test contrasting approaches. I don't have examples of inputs where they parse differently on hand right now, but I know they exist. This was also a problem that was frequently discussed internally when I worked at MSFT.

    #include 

> instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.

Yeah, they didn't follow the instructions and got burned. I still think that multiple things went wrong simultaneously for that experience. I wonder if more prevalent uses of `#[doc(alias = "name")]` being leveraged by https://github.com/rust-lang/rust/pull/120730 (which now that I check only accounts for methods and not functions, I should get on that!) so that when changing APIs around people at least get a slightly better experience.

Almost fixed the compiler: https://github.com/rust-lang/rust/pull/123325

Rust: A secure, efficient, and modern programming language (omitting ten thousand words). You can simply follow the installation instructions provided on the official website.

Recently did something similar in Rust but for generating SVGs. We've adopted it for snapshot testing of cargo and rustc's output. Don't have a good PR handy for showing Github's rendering of changes in the SVG (text, side-by-side, swiping) but https://github.com/rust-lang/rust/pull/121877/files has newly added SVGs.

To see what is supported, see the screenshot in the docs: https://docs.rs/anstyle-svg/latest/anstyle_svg/

We strongly believe in Rust as a powerful language for building production-grade software, especially for systems like ours that run alongside Kubernetes.