Comment by wyager
4 months ago
I write a lot of Rust, but as you say, it's basically a vastly improved version of C++. C++ is not always the right move!
For all my personal projects, I use a mix of Haskell and Rust, which I find covers 99% of the product domains I work in.
Ultra-low level (FPGA gateware): Haskell. The Clash compiler backend lets you compile (non-recursive) Haskell code directly to FPGA. I use this for audio codecs, IO expanders, and other gateware stuff.
Very low-level (MMUless microcontroller hard-realtime) to medium-level (graphics code, audio code): Rust dominates here
High-level (have an MMU, OS, and desktop levels of RAM, not sensitive to ~0.1ms GC pauses): Haskell becomes a lot easier to productively crank out "business logic" without worrying about memory management. If you need to specify high-level logic, implement a web server, etc. it's more productive than Rust for that type of thing.
Both languages have a lot of conceptual overlap (ADTs, constrained parametric types, etc.), so being familiar with one provides some degree of cross-training for the other.
What do you mean by 'a mix of Haskell and Rust'? Is that a per-project choice or do you use both in a single project? I'm interested in the latter. If so, could you point me to an example?
Another question is about Clash. Your description sounds like the HLS (high level synthesis) approach. But I thought that Clash used a Haskell -based DSL, making it a true HDL. Could you clarify this? Thanks!
Yeah, sometimes I'll do e.g. a backend state management server in Haskell and then a lightweight (embedded) client in Rust. I haven't ever tried linking rust from haskell yet, if that's what you mean.
I would actually flip your HDL definition a bit. Clash is a true HDL, but specifically because it's not just a shallowly embedded DSL.
Clash is actually a GHC plugin that compiles haskell code to a synchronous circuit representation and then can spit that out as whatever HDL you like. It's emphatically not just a library for constructing circuit descriptions, like most new gateware development tools. This is possible because the semantics of Haskell are (by a mixture of good first-principles design and luck) an almost exact match for the standard four-state logic semantics of synchronous digital circuits.
This is also different from the standard HLS approach where the semantics of the source language do not at all match the semantics of the target. With Haskell, they are (surprisingly) very close! Only in a few edge cases (mostly having to do with zero-bit wires and so on) does the evaluation semantics of haskell differ from the evaluation semantics of e.g. verilog.