Rusoto VS crates.io

A small note on the Rust AWS SDK. It is currently in Developer Preview. However, the project's latest README indicates that it's production-ready, but not production-supported. More of a use-at-your-own-risk type of thing. At this point, I personally would be comfortable shipping with it, but I know that some might prefer something that is marked production-ready. If you want to explore another AWS SDK, rusoto might be for you. However, I imagine the SDK will go GA soon. That's a hunch and NOTHING official. I am not speaking for AWS here.

rusoto

For AWS, there is both the new official SDK preview (https://github.com/awslabs/aws-sdk-rust), and the older unofficial one (https://github.com/rusoto/rusoto). I've not used the new one, but rusoto was excellent when I used it a few years ago.

There's an draft PR to fix this, but it seems to have stalled.

And if the "preview" bit turns you off, Rusoto still works perfectly well and is mature (but in maintenance mode)

And i created an issue on GitHub https://github.com/rusoto/rusoto/issues/1955

Maybe start by having an AWS SDK for Rust that isn't community supported by one or two employees on their off time?

https://github.com/rusoto/rusoto

While not official, there is at least one or two Amazonians working on https://github.com/rusoto/rusoto which is a pretty great Rust AWS SDK.

Dependencies are other Rust packages (called crates) that your project uses. Most of these crates live on crates.io, Rust's central package registry.

Explore Crates: Use crates.io to find libraries for your projects.

Rust? It's built clean from the ground up. The crates.io registry is full of modern, safe, composable libraries. You've got Axum, Rocket and Actix for backends, Leptos, Dioxus, and Yew for frontend, and more. Every library you use follows the same philosophy: safety, performance, and zero tolerance for ambiguity.

I've been ramping up on the embedded Rust ecosystem over the last few weeks. I'm pretty excited about it partly because it makes this aspect of embedded development much more approachable. On https://crates.io I can usually find a driver for whatever peripheral I want to use in my project. And the driver usually implements the embedded-hal [1] interface, so the more I get familiar with that interface, the easier it becomes to implement any arbitrary peripheral into my project. In the event that there does not already exist a crate for my peripheral, I have an extensive ecosystem [2] of open source driver code that I can refer to in order to figure out how to implement the driver.

I think this could help with the "dark art of reading datasheets" problem. E.g. last night I was curious about how the driver for a 28BYJ-48 stepper motor would work, so I looked at the code [3] for its driver and got a pretty good sense of what's going on. If I were to now attempt to read the datasheet, a lot of it would now make sense. In other words I think it's too daunting to read a datasheet and then try to implement code. The way to get comfortable with datasheets is to first look at code and then find the relevant parts of the datasheet.

[1] https://github.com/rust-embedded/embedded-hal

[2] https://crates.io/keywords/embedded-hal-driver

[3] https://github.com/MnlPhlp/uln2003

I often hear this and am confused; not only are things like ['object soup'](https://jacko.io/object_soup.html) possible and straightforward (putting things in collections and referring to them by indices), I never concretely hear why a graph or doubly-linked list becomes uniquely difficult to implement in Rust (and would genuinely be curious to learn why you feel this way). If you needed such data structures anyway, they're either in the standard library or in the many libraries ('crates' in Rust-lingo) available on [Rust's package registry](https://crates.io/)---using dependencies in Rust is very straightforward & easy.

Rust Package Registry (crates.io)

crates.io is the central repository/registry for Rust crates. It's a crucial part of the Rust ecosystem.

Oh dear.

I see Redis Inc. have decided to go full Nagios.

Never go full Nagios.

Though admittedly Nagios' attempt to pull similar assholery wrt CPAN did end up being a source of some amusement to me: http://p3rl.org/Nagios::Plugin

I hope the http://crates.io team react similarly.

Spin 3.0 introduces a workflow for this type of development in the hopes of making it seamless to do things like write a library for some compute intensive task in Rust and use that as a dependency in a JavaScript application. Or perhaps you’re not a Rust developer and don’t feel like learning it overnight? No problem. Fetch a component someone else already built from an OCI registry. Component dependencies can be stored, discovered, and fetched from OCI registries giving you the npm/NuGet/crates.io style experience but for Wasm. Now, I think this particular feature is wild and could go on about it for at least a thesis, but there are even more Spin 3.0 topics to discuss so feel free to dig deeper in the component dependencies documentation here and in the demo later on.