bitvec VS watt

I was also under the false impression that bitwise encoding was slow. When I first implemented bitcode with bitvec I got performance 20x worse than bincode. After writing my own implementation I was able to get much better performance.

interesting; i'll have to compare this to my rust counterpart. your numbers indicate some clever implementations i'd love to read

Not to mention having a lackluster std which causes you to use nonstardard not so well documented crates and a 40K LoC library to do "bit-twiddling" (the lib, https://github.com/bitvecto-rs/bitvec the blog that says "twiddle bits" https://blog.adamchalmers.com/making-a-dns-client/ and for crying out loud the blogger also used the language the author mentioned and I quote "ergonomics AND speed AND correctness")

https://github.com/bitvecto-rs/bitvec/issues/135 is a very funny read about how to perform inttoptr with provenance retention

Technically #135 gives me license to yank affected crates, but since the only exploit is "Miri crashes exactly one test out of the suite" it's not really worth it to be a stickler. Call it a truce

My friend Nika wrote a macro that packs a sequence of 1, 0, … tokens into a correctly structured bit-buffer, adaptable over any register type or bit-ordering, at compile time. It's now basically this whole file

if you are interested in a user manual, you can use mdbook as well. for an example, my bitvec project uses mdbook (book.toml) and a github action (.github/workflows/gh-pages.yml) to compile the guide and host it as a github pages website. it's slightly more complicated, and i'd like docs.rs to follow hexdoc.pm's example of hosting both api docs and prose, but until then this is a pretty reasonable solution.

the first one

i would browse the standard library, tower, nom, or my own bitvec to see layout and trait/record separation. in particular, std::io and std::net may be of use: io::Read and io::Write are pervasive examples of implementing unixy file-descriptor-like behavior in the type system

The precompiled binary is not a sandboxed WASM binary. Despite the name "watt" it has nothing to do with https://github.com/dtolnay/watt . You can look at the actual code to see for yourself.

* Related: watt is one approach to pre-compile proc-macro crates using WASM.

In addition to thiserror and anyhow, our resident superhuman Rust-improving Robot, dtolnay, also developed an experiment in distributing precompiled proc macros as WebAssembly named Watt and, though I never bothered to create a Zulip account so I don't know what was said, I'm told there has been discussion around the idea of implementing something in that vein.

I think when we have Cranelift, Mold, and maybe Watt all working together then compile times will basically be a non-issue. It'll be a few years though.

Check out https://github.com/dtolnay/watt - it's a really interesting solution to the problem!

I really like the idea of Watt: https://github.com/dtolnay/watt Run macros in a wasm sandbox so they can't touch anything you don't explicitly allow.

I really wish there was more interest in getting something like Watt upstreamed.