sinu.eth
sinu.eth
For parsing and assertions, I had in mind to use this [semver](https://docs.rs/semver/latest/semver/) crate. We would store the cargo package version as a static at build time: ```rust const VERSION: &'static...
@xiangxiecrypto thanks will definitely borrow from there. I quickly hacked together something locally for x86 and found only an 8% improvement for garbling AES. So I suspect my napkin math/profiling...
I don't see the value in querying `httpbin` instead of running a service locally. We need something that is configurable and reproducible. This bench will vary a lot without providing...
I really like this/`spaad` and would like to start using it. Hiding the message passing as an implementation detail seems like it would boost productivity quite a bit. Is help...
> If you are using an actor framework, interacting with an Address is essential and shouldn't be hidden. Not sure I agree, at least not in general. In my view...
I generally agree with your stance which seems to be one preferring explicitness. For me it depends what I'm feeling for the boilerplate vs obscurity trade-off for the task at...
> I 100% agree for the definition of handlers (and perhaps message structs) :handshake: > In fact, that is what this issue is about :) My most recent thoughts are...
Any thoughts on using an approach like [`enum_dispatch`](https://crates.io/crates/enum_dispatch) to eliminate the dynamic dispatch overhead? Would be able to use off the shelf `mpsc` channels instead, while keeping the same ergonomics....
My thinking something along these lines: ```rust trait Actor { type Envelope: MessageEnvelope; .. } struct PingActor; impl Actor for PingActor { type Envelope = PingMessage; } impl Handler for...
> The reason we have custom channels is actually nothing to do with the message enveloping Firstly, sorry, I was tired yesterday and just realized I did stray off topic...