That's like saying that buffer overflows are not due to how strings are represented in C. Yes a bug is the programmer's fault, but languages can make it harder to have bugs in the first place (for instance you can't have buffer overflows in any other higher level language than C).
In the case of the hardware industry, we see a language with a weak type system (Verilog). So the "solution" is to use lint tools to check that your design is properly typed. Similarly, nothing in VHDL/Verilog prevents you from accidentally creating latches, or crossing domains badly, or many other small bugs. So again, the "solution" is to do extensive verification. That's the Haskell VS Python debate: you can either make it impossible to have a certain class of bugs (and detect them very early), or you can just write a lot of tests (which, in the case of hardware, take forever to run).
The same logic extends at a higher level. You can have a language that models common patterns (like a synchronous loop, a "ready before valid" port) so you can reduce the amount of verification needed because you don't need to always re-verify everything. One could even argue that having such higher-level mechanisms would also make static verification easier, since you might reason in terms of transactions rather than updates to registers.
Latches are caught by the synthesis tools generally. Designers usually run a unconstrained synthesis as a matter of course to determine whether they have written junk.
As for the other bugs, I look forward to this new paradigm of spotting them early without verification effort.
Reasoning about transactions is already how verification works. It is transaction based. UVM is a library of SystemVerilog classes aimed at abstracting the verification to higher levels.
That's like saying that buffer overflows are not due to how strings are represented in C. Yes a bug is the programmer's fault, but languages can make it harder to have bugs in the first place (for instance you can't have buffer overflows in any other higher level language than C).
In the case of the hardware industry, we see a language with a weak type system (Verilog). So the "solution" is to use lint tools to check that your design is properly typed. Similarly, nothing in VHDL/Verilog prevents you from accidentally creating latches, or crossing domains badly, or many other small bugs. So again, the "solution" is to do extensive verification. That's the Haskell VS Python debate: you can either make it impossible to have a certain class of bugs (and detect them very early), or you can just write a lot of tests (which, in the case of hardware, take forever to run).
The same logic extends at a higher level. You can have a language that models common patterns (like a synchronous loop, a "ready before valid" port) so you can reduce the amount of verification needed because you don't need to always re-verify everything. One could even argue that having such higher-level mechanisms would also make static verification easier, since you might reason in terms of transactions rather than updates to registers.