_Vi

joined 1 year ago
[–] [email protected] 3 points 3 months ago

Always asking for an additional restriction on the base trait.

Some of these restrictions are reasonable, some you need to avoid. Without dyn the compiler just figures out whether those properties are congruent, with dyn you need to choose those properties explicitly.

must be Copy, must be Send, must be Sized, must be 'static

  • Send is typically reasonable and typically can be just added to the list.
  • Sized - not sure. Idea of dyn things typically relies on unsized things (and Box and friends to get back to the Sized world).
  • 'static - if you are OK at allocating here and there (i.e. not optimising for performance hard), limiting to 'static world (i.e. without other lifetimes and inner references) can be reasonable.
  • Sync is needed rarely, usually Send is enough.
  • Copy bound is typically too much, unless the data is very simple. Probably you need a .clone() and/or Arc somewhere.
  • Unpin can also be just added as needed, unless you are dealing with async and optimising allocations.

On and on.

The list of things that can be added in ... part of dyn Trait + ... is finite, so this "on and on" won't go forever. So after some time the trait definition and main consumers are expected to stabilise.

I’m off the Golden Path

dyn road is indeed a thinner and somewhat winding road compared to main, easy way of 'static + Sized things. But when it is really necessary (i.e. you need dynamically construct the strategies from parts, or you need to attach more strategies from plugins, or you want to avoid big bloated executables), there is little way around it.

So I just embraced the verbosity of using generics and its easy. Yes its more code but its better code.

If it works without dyn then probably it's OK to leave it that way.

Each of those dyn, async, impl<'a>, Pin, unsafe, macro_rules! things bump Rust experience a step right on Easy-Normal-Hard-Nightmare scale.

[–] [email protected] 1 points 11 months ago* (last edited 11 months ago)

Maybe optional actions (fn action_var(&amp;mut self, var: &amp; Var) -> Option<var>) can be take argument by value if you roundtrip it back?

fn action_var(&amp;mut self, var: Var) -> Var</var>
[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

hyper-util

It is not released to crates.io as of now, even as alpha version.

Update: now it is released. docs.rs does not show anything yet. There is a pull request about it already though.

 

This is a #[no_std]-friendly library for encoding and decoding WebSocket frames.

It does not offer full WebSocket experience like Tungstenite, only the part where you need to deal with bits and bytes.

It works completely without using memory allocator. You meed to assemble WebSocket messages chunk by chunk yourself though.

45
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
 

Low-level HTTP 1 and 2 processing library "hyper" gets released.

It contains fewer features than 0.14, (relatively) "high-level" client and server are gone. Only hyper::{client,server}::conn remain.

Also there is some IO abstraction: though it still depends on Tokio (only the sync feature), it should be easier to connect other runtimes. Just using it with Tokio like before is though less straightforward.


Do not hurry to upgrade your project from 0.14 to 1, better wait for better support in the ecosystem.