5 ms·

Pet theory, as someone who falls into the "Loves Rust; avoids Async and generics" alluded to in the beginning of this article, the one it's replying to, and com

Pet theory, as someone who falls into the "Loves Rust; avoids Async and generics" alluded to in the beginning of this article, the one it's replying to, and comments on the latter's thread here: Is the Async crew mostly writing web servers and other things that operate using TCP and HTTP? Lower level (eg IP, Eth, network hardware drivers) isn't well supported by rust libs. Nor is higher - we have Flask analogs, but no Django analogs. As Async ingresses in Embedded Rust, I seek answers to "is this worth the viral qualities, and API rift?". For the adjacent question re generics by default, I ask "Is the flexibility and type checking worth the API complexity, and documentation dead-ends?" Does anyone here use Async Rust in domains outside those sections of network and web programming? I've found rust to be a great fit as a cleaner, more explicit C alternative.

bool3max 4y ago
How do you manage to avoid generics while writing Rust?
- whatshisface 4y ago
  You can't avoid using generics, but you can avoid writing generic data structures if the standard library is sufficient and your application won't benefit from de-duplicating code shared between similar structs.
- the__alchemist 4y ago
  It depends on the use case. The short and simple answer is avoid libs that rely heavily on them, and use structs and enums. This gets into the area of application code vs libraries. A simple example, for say, a struct used to interact with a bus on a MCU is to use a `I2c` struct, instead of `I2c<Output<OpenDrain<PA5<Af5>>>, Output<OpenDrain<PA6<AF5>>>>` etc. God help you if the library that uses the latter doesn't document it using examples, because the auto-generated Rust docs won't help.
- nyanpasu64 4y ago
  You can't avoid traits and generics entirely, but you can get by with far less than the norm (which is simpler, has some powerful code-reading advantages, and some expressiveness drawbacks). Personally I keep using Vec<T> and other hashmaps, I generally prefer match over .value_or().map(...) functional-style Option/Iterator chaining (though my opinion is unwelcome in some "oh-so-accepting" Rust spaces), prefer type methods over trait methods (which you can't even call unless you `use` the trait into scope), etc. Unfortunately when building generic data structures, you sometimes need complex lifetime and trait Send/Sync/Sized bounds (but I try to switch approaches and sometimes write duplicated code, whenever a particular abstraction approach starts requiring complex HRTBs and such).
tester756 4y ago
"Is the flexibility and type checking worth the API complexity, and documentation dead-ends?" What do you mean?
- the__alchemist 4y ago
  I was implicitly referring to [Typestates](http://cliffle.com/blog/rust-typestate/ http://cliffle.com/blog/rust-typestate/) as an example; the details will depend on which generic patterns are used. I like the advantage they provide by catching incorrectly-configured hardware, but in practice, I don't think they're worth the application-side code complexity and learning curve vice using simpler APIs.
xavxav 4y ago
> Is the Async crew mostly writing web servers and other things that operate using TCP and HTTP? Lower level (eg IP, Eth, network hardware drivers) isn't well supported by rust libs. Nor is higher - we have Flask analogs, but no Django analogs. Something I have never understood is why people want to write web-apps in Rust. I love the language, but honestly, a managed language (like js/ruby/go) is always going to be better suited to the world of web-apps. I feel like this imposes an undue burden on Rust to do everything for everyone which has to break down somewhere
- steveklabnik 4y ago
  The answer to this question is often one of a few different things: reliability (“we didn’t touch our service for 18 months after deployment and it never ran into issues”), low resource usage (“we decommissioned X servers which saves us $Y/year”), and high performance are common responses.
  - otterley 4y ago
    Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like Python, Ruby, or JavaScript, further optimization seems like it's gilding the lily.
    - Cyph0n 4y ago
      For most use cases, I agree. But Rust is a better option when you also need one or more of the following: a) tight control over allocations b) deterministic performance c) strong data race protection d) zero overhead C interop (e.g., processing audio using ffmpeg)
    - steveklabnik 4y ago
      It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.
cmrdporcupine 4y ago
The problem is that async in Rust is, as other people have put it, viral. Example: I have some stuff in my hobby application that is executing in a WASM virtual machine. That's not async, simple and synchronous. But I have two other parts: one that talks to FoundationDB, and another that receives websocket connections. Both use Tokio & Async. Now I'm in a pickle every time I want to hold or pass around some state in my WASM pieces, because the async stuff ends up pushing its constraints all the way down. Want some piece of mutability? Some piece that doesn't Send or Copy? Good luck. There's ways around it all, but it complicates the design. The 'async' pieces at the front end up propagating all the way down. It's hard to explain fully without you being in my code, but suffice it to say, I agree with others: async in Rust is half-baked. That should be evident enough simply from the fact that you can't even yet put async functions in traits.
- zamalek 4y ago
  > you can't even yet put async functions in traits. I find the compiler reminding me constantly that I can't. I don't worry much about the viral nature of async, but this annoys me so much.
blub 4y ago
The big question is if one can still get a job by doing the above. If the wider Rust ecosystem will be infiltrated by async and heavy generic code one would be condemned to use Rust for personal projects.

bool3max 4y ago

How do you manage to avoid generics while writing Rust?

whatshisface 4y ago
You can't avoid using generics, but you can avoid writing generic data structures if the standard library is sufficient and your application won't benefit from de-duplicating code shared between similar structs.
the__alchemist 4y ago
It depends on the use case. The short and simple answer is avoid libs that rely heavily on them, and use structs and enums. This gets into the area of application code vs libraries. A simple example, for say, a struct used to interact with a bus on a MCU is to use a `I2c` struct, instead of `I2c<Output<OpenDrain<PA5<Af5>>>, Output<OpenDrain<PA6<AF5>>>>` etc. God help you if the library that uses the latter doesn't document it using examples, because the auto-generated Rust docs won't help.
nyanpasu64 4y ago
You can't avoid traits and generics entirely, but you can get by with far less than the norm (which is simpler, has some powerful code-reading advantages, and some expressiveness drawbacks). Personally I keep using Vec<T> and other hashmaps, I generally prefer match over .value_or().map(...) functional-style Option/Iterator chaining (though my opinion is unwelcome in some "oh-so-accepting" Rust spaces), prefer type methods over trait methods (which you can't even call unless you `use` the trait into scope), etc. Unfortunately when building generic data structures, you sometimes need complex lifetime and trait Send/Sync/Sized bounds (but I try to switch approaches and sometimes write duplicated code, whenever a particular abstraction approach starts requiring complex HRTBs and such).

tester756 4y ago

"Is the flexibility and type checking worth the API complexity, and documentation dead-ends?" What do you mean?

the__alchemist 4y ago
I was implicitly referring to [Typestates](http://cliffle.com/blog/rust-typestate/ http://cliffle.com/blog/rust-typestate/) as an example; the details will depend on which generic patterns are used. I like the advantage they provide by catching incorrectly-configured hardware, but in practice, I don't think they're worth the application-side code complexity and learning curve vice using simpler APIs.

xavxav 4y ago

> Is the Async crew mostly writing web servers and other things that operate using TCP and HTTP? Lower level (eg IP, Eth, network hardware drivers) isn't well supported by rust libs. Nor is higher - we have Flask analogs, but no Django analogs. Something I have never understood is why people want to write web-apps in Rust. I love the language, but honestly, a managed language (like js/ruby/go) is always going to be better suited to the world of web-apps. I feel like this imposes an undue burden on Rust to do everything for everyone which has to break down somewhere

steveklabnik 4y ago
The answer to this question is often one of a few different things: reliability (“we didn’t touch our service for 18 months after deployment and it never ran into issues”), low resource usage (“we decommissioned X servers which saves us $Y/year”), and high performance are common responses.
- otterley 4y ago
  Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like Python, Ruby, or JavaScript, further optimization seems like it's gilding the lily.
  - Cyph0n 4y ago
    For most use cases, I agree. But Rust is a better option when you also need one or more of the following: a) tight control over allocations b) deterministic performance c) strong data race protection d) zero overhead C interop (e.g., processing audio using ffmpeg)
  - steveklabnik 4y ago
    It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.

cmrdporcupine 4y ago

The problem is that async in Rust is, as other people have put it, viral. Example: I have some stuff in my hobby application that is executing in a WASM virtual machine. That's not async, simple and synchronous. But I have two other parts: one that talks to FoundationDB, and another that receives websocket connections. Both use Tokio & Async. Now I'm in a pickle every time I want to hold or pass around some state in my WASM pieces, because the async stuff ends up pushing its constraints all the way down. Want some piece of mutability? Some piece that doesn't Send or Copy? Good luck. There's ways around it all, but it complicates the design. The 'async' pieces at the front end up propagating all the way down. It's hard to explain fully without you being in my code, but suffice it to say, I agree with others: async in Rust is half-baked. That should be evident enough simply from the fact that you can't even yet put async functions in traits.

zamalek 4y ago
> you can't even yet put async functions in traits. I find the compiler reminding me constantly that I can't. I don't worry much about the viral nature of async, but this annoys me so much.

blub 4y ago

The big question is if one can still get a job by doing the above. If the wider Rust ecosystem will be infiltrated by async and heavy generic code one would be condemned to use Rust for personal projects.