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-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/hard...
https://github.com/janestreet/hardcaml/blob/master/docs/enum...
https://github.com/janestreet/hardcaml/blob/master/docs/stat...