Hi, blog post author here. Thank you so much for your insights and responses to my Verilog critiques! I should note that my impressions of Verilog come from one

Hi, blog post author here. Thank you so much for your insights and responses to my Verilog critiques! I should note that my impressions of Verilog come from one semester of an intro course taught using the Vivado toolchain, so there's a fair bit I don't know. My post is not an expert analysis of Verilog as much as a summary of beginner impressions from basic coursework and online research. I'm sure that enterprise setups probably have better tooling and systems in place to ease development. A few things in response to specific comments: >> Oh, and there's no syntax error highlighting in VSCode's Verilog extensions either. > This is not true. From what I recall, the ones I tried didn't catch all errors, and the errors they displayed were limited to basic syntax stuff, not any implementation issues / warnings. > Synthesis is notorious for barfing out thousands of warnings even on simple designs. That's a very good point. Our development process was mostly a code-simulate loop, with synthesis only run when submitting each phase of the project. > Did they misspell it such that it looked like another declared signal? That would be less embarrassing. This one was just a minor typo, but because we didn't see any warnings during simulation, it took a while to track down the root cause. > You might expect that to be an error, but it's called a "wired-OR." That makes sense, but it feels like something that should be done by the synthesis process as an optimization, or annotated with a special operator if the engineer needs direct control over it. > But the semantics get clunky. I would think that is where OCaml or Chisel or others would be interesting. > You can put all the functions/tasks you want in that module. Coming from a software background, the testing strategies available in Verilog seem very clunky and overly verbose. In comparison, Hardcaml's ASCII waveform expect-test solution feels extremely elegant and simple: https://blog.janestreet.com/using-ascii-waveforms-to-test-hardware-designs/ https://blog.janestreet.com/using-ascii-waveforms-to-test-ha.... > And all of my development and that of my team happens through gitlab-CI. That's probably more of a gap in my education than a fault of the ecosystem then. --- Among other qualities, I prefer languages that let fewer mistakes slip through, and allow the developer to focus on the system they intend to build rather than avoiding bugs/misunderstandings that would be easy to catch otherwise. You bring up a lot of really good points, and I suspect that if we were doing Verilog "the right way", we would have probably run into fewer issues. But at the end of the day, developing in Hardcaml was a much more ergonomic experience: testing was straightforward, most "stupid mistakes" were impossible, setup was pretty easy, and the library provided a lot of really useful abstractions. For example, Hardcaml interfaces make it easy to represent practically any data structure that can be serialized to/from a bit vector, and the Always API allows for some pretty interesting non-trivial functional logic. https://github.com/janestreet/hardcaml/blob/master/docs/hardcaml_interfaces.mdx https://github.com/janestreet/hardcaml/blob/master/docs/hard... https://github.com/janestreet/hardcaml/blob/master/docs/enums.mdx https://github.com/janestreet/hardcaml/blob/master/docs/enum... https://github.com/janestreet/hardcaml/blob/master/docs/state_machine_always_api.mdx#advanced-metaprogramming-with-the-always-dsl https://github.com/janestreet/hardcaml/blob/master/docs/stat...