5 ms·

This is all very impressive, especially since AFAICT Tokio is only about 5 months old and consists of tens of thousands of lines of code spread across a half do

This is all very impressive, especially since AFAICT Tokio is only about 5 months old and consists of tens of thousands of lines of code spread across a half dozen different repositories. I'm anxious for the day when I can use Rust at work. All I'm really missing to justify using it is a bit more mature ecosystem. Especially a full featured, stable AWS SDK.

steveklabnik 10y ago
Have you tried https://crates.io/crates/rusoto https://crates.io/crates/rusoto ? I haven't, interested to hear what people say. It was announced roughly in August, so yeah, five months. Though some work had to happen for that initial release, of course. There was a joke though, about this rapid development. Someone said something like "That they keep re-writing tokio is really annoying as a user, but I guess if Rust is so productive that you can throw out huge chunks and re-build it that quickly, well, that says good things about the language." Of course, as the post says, things will be more stable now.
- curun1r 10y ago
  Rusoto seemed like a good effort last time I looked, it didn't have very full coverage of the AWS API. Amazon just has so many APIs that it's a huge dev effort to implement it all and keep up with changes. This is a problem in other languages where Amazon doesn't contribute to keeping the client up-to-date. I'm hopeful that with macros 1.1, the situation will improve since it will enable compile-time code generation based on the official json files in botocore. Just add that repo as a git submodule and then: #[derive(Aws!("s3/2006-03-01/service-2.json"))] struct S3; Becomes up-to-date with the latest changes from Amazon the moment they're released (recompile required). Procedural macros are really exciting with regard to writing/consuming APIs as they enable both the client and the server interface to be implemented in an API specification language (Amazon uses custom JSON, but Swagger/RAML could work too) instead of Rust with zero performance penalty (gotta love those zero-cost abstractions :-)
  - matthewkmayer 10y ago
    Thanks for the feedback. We're tracking the missing services: https://github.com/rusoto/rusoto/issues/436 https://github.com/rusoto/rusoto/issues/436 . There's plenty of work to do and we're concentrating on getting them implemented. Sometimes progress is slow since it's a side project, but it's still moving forward. If we can make the derive statements work as your code snippet shows, I'd be really happy. We'll take a look at how we can improve codegen when new features are available. Some of our codegen is dated, using what was available when it was written.
- mastax 10y ago
  I've used rusoto a bit. A lot of it feels very "generated" in that there are a bunch of different types for everything, but you can ignore most of that and just use the Client methods. It does make browsing the docs a bit difficult though. It seems like many things are in flux. There's a new `rest_xml` codegen thing that just got implemented which will allow AWS API to be supported. They're also moving from Hyper to Reqwests. From what I saw, Async stuff is planned for after 1.0 by adding new AsyncClient impls backwards-compatibly.
  - matthewkmayer 10y ago
    Yes, there's a lot of types we generate from the botocore service definitions. Any suggestions on reducing the noise in our docs to make usage clearer? I'd love an issue on Github with thoughts. https://github.com/rusoto/rusoto https://github.com/rusoto/rusoto We also have a crate that's designed to provide higher level abstractions. Rusoto is analogous to botocore and rusoto_helpers (https://github.com/rusoto/rusoto/tree/master/helpers https://github.com/rusoto/rusoto/tree/master/helpers) will be closer to boto3. It's on the back burner as we focus on completing the core functionality. Async support is still an open question. If requested we can make that happen before 1.0. Feel free to weigh in: https://github.com/rusoto/rusoto/issues/318 https://github.com/rusoto/rusoto/issues/318 .
    - nicoburns 10y ago
      Docs wise, a big help would be to highlight 'important' structs. When I was first reading the docs, I saw a great big list of structs including ones like SpecificMethodInputAeguments, and completely missed the KinesisClient structure that all the actual methods are implemented on!
      - matthewkmayer 10y ago
        I've made https://github.com/rusoto/rusoto/issues/519 https://github.com/rusoto/rusoto/issues/519 for this particular issue, along with a sample way of calling out the important Client struct for each service. Thanks for the idea!
- stusmall 10y ago
  I used it's S3 module for a project a few months ago. I remember the API feeling a bit awkward and non-idiomatic, but I also got the impression that the API was emulated another language's AWS API. I don't know if that is true or not. Overall I was super happy. I finished the feature I was working on in maybe a day or two without any issues in the rusoto library. Can't ask for more than that.

steveklabnik 10y ago

Have you tried https://crates.io/crates/rusoto https://crates.io/crates/rusoto ? I haven't, interested to hear what people say. It was announced roughly in August, so yeah, five months. Though some work had to happen for that initial release, of course. There was a joke though, about this rapid development. Someone said something like "That they keep re-writing tokio is really annoying as a user, but I guess if Rust is so productive that you can throw out huge chunks and re-build it that quickly, well, that says good things about the language." Of course, as the post says, things will be more stable now.

curun1r 10y ago
Rusoto seemed like a good effort last time I looked, it didn't have very full coverage of the AWS API. Amazon just has so many APIs that it's a huge dev effort to implement it all and keep up with changes. This is a problem in other languages where Amazon doesn't contribute to keeping the client up-to-date. I'm hopeful that with macros 1.1, the situation will improve since it will enable compile-time code generation based on the official json files in botocore. Just add that repo as a git submodule and then: #[derive(Aws!("s3/2006-03-01/service-2.json"))] struct S3; Becomes up-to-date with the latest changes from Amazon the moment they're released (recompile required). Procedural macros are really exciting with regard to writing/consuming APIs as they enable both the client and the server interface to be implemented in an API specification language (Amazon uses custom JSON, but Swagger/RAML could work too) instead of Rust with zero performance penalty (gotta love those zero-cost abstractions :-)
- matthewkmayer 10y ago
  Thanks for the feedback. We're tracking the missing services: https://github.com/rusoto/rusoto/issues/436 https://github.com/rusoto/rusoto/issues/436 . There's plenty of work to do and we're concentrating on getting them implemented. Sometimes progress is slow since it's a side project, but it's still moving forward. If we can make the derive statements work as your code snippet shows, I'd be really happy. We'll take a look at how we can improve codegen when new features are available. Some of our codegen is dated, using what was available when it was written.
mastax 10y ago
I've used rusoto a bit. A lot of it feels very "generated" in that there are a bunch of different types for everything, but you can ignore most of that and just use the Client methods. It does make browsing the docs a bit difficult though. It seems like many things are in flux. There's a new `rest_xml` codegen thing that just got implemented which will allow AWS API to be supported. They're also moving from Hyper to Reqwests. From what I saw, Async stuff is planned for after 1.0 by adding new AsyncClient impls backwards-compatibly.
- matthewkmayer 10y ago
  Yes, there's a lot of types we generate from the botocore service definitions. Any suggestions on reducing the noise in our docs to make usage clearer? I'd love an issue on Github with thoughts. https://github.com/rusoto/rusoto https://github.com/rusoto/rusoto We also have a crate that's designed to provide higher level abstractions. Rusoto is analogous to botocore and rusoto_helpers (https://github.com/rusoto/rusoto/tree/master/helpers https://github.com/rusoto/rusoto/tree/master/helpers) will be closer to boto3. It's on the back burner as we focus on completing the core functionality. Async support is still an open question. If requested we can make that happen before 1.0. Feel free to weigh in: https://github.com/rusoto/rusoto/issues/318 https://github.com/rusoto/rusoto/issues/318 .
  - nicoburns 10y ago
    Docs wise, a big help would be to highlight 'important' structs. When I was first reading the docs, I saw a great big list of structs including ones like SpecificMethodInputAeguments, and completely missed the KinesisClient structure that all the actual methods are implemented on!
    - matthewkmayer 10y ago
      I've made https://github.com/rusoto/rusoto/issues/519 https://github.com/rusoto/rusoto/issues/519 for this particular issue, along with a sample way of calling out the important Client struct for each service. Thanks for the idea!
stusmall 10y ago
I used it's S3 module for a project a few months ago. I remember the API feeling a bit awkward and non-idiomatic, but I also got the impression that the API was emulated another language's AWS API. I don't know if that is true or not. Overall I was super happy. I finished the feature I was working on in maybe a day or two without any issues in the rusoto library. Can't ask for more than that.