This is pretty great, I love the concept of modeling circuits with code. I wish it wasn't Rust, but only because circuits are based on functional programming, so there's no need for the added complexity of mutability or the other imperative concepts that Rust goes to great lengths to support. But it's good to get a reference implementation done before exploring doing this in Lisp or something.<p>I'd also like to see if this attempts to address the drawbacks of VHDL and Verilog. When I used VHDL in college in the 90s, I remember that it had a lot of trouble with basic stuff like describing a collection of bits as a variable and expecting math on that variable to "just work". Like maybe I could connect a circuit directly to one of the variable's bits, but it acted flakier than if I connected it to a verbose circuit described manually. I think it had something to do with timing, maybe rising/falling edge stuff, or maybe something needed to be latched before it could be used, etc. And maybe some of that has since been "fixed", although the problem was probably user error on my part.<p>Anyway, I'd like to see a thin layer above hardware description languages that takes care of that stuff so that they don't have surprising side effects. It's kind of like how XML is more powerful than JSON because it can have its own types, but the industry discovered that custom types encourage anti-patterns, so now everybody just uses JSON. I need a circuit to be built as described, even if it has additional training wheels inside for my protection, and then an optimization pass would remove anything superfluous or maximize stability by converting to stuff like gray code (which is probably already widely supported). I feel rather strongly that this issue has set FPGAs back by at least 2 decades, maybe longer.