I've said as much before but I find the issue with alternative HDLs Vs SystemVerilog is they concentrate on fixing annoying and frustrating things but don't add

I've said as much before but I find the issue with alternative HDLs Vs SystemVerilog is they concentrate on fixing annoying and frustrating things but don't address the really hard issues in hardware design and can actually make them harder. For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use of verilog style guides and decent linting tools solves most of the problem. You do still get bugs caused by missed typing issues but they're usually quickly caught by simple tests. It's certainly annoying to have to deal with all of this but fundamentally if it's all made easier it's not significantly improving your development time or final design quality. Another typical improvement you'll find in an alternative HDL is vastly improved parameterization and generics. Again this is great to have but mostly makes tedious and annoying tasks simpler but doesn't produce major impact. The reason for this is writing good HDL that works across a huge parameterisation space is very hard. You have to verify every part of the parameter space you're using and you need to ensure you get good power/performance/area results out of it too. To do this can require very different micro architectural decisions (e.g. single, dual and triple issue CPUs will all need to be built differently improved parameterization doesn't save you from this). Ultimately you often only want to use a small portion of the parameter space anyway so just doing it in system verilog possibly with some auto generated code using python works well enough even if it's tedious. So if the practical benefits turn out to be minor why not take all the nice quality of life improvements anyway? There's a large impact on the hard things. From a strictly design perspective these are things like clock domain crossing, power, area and frequency optimization. Here you generally need a good understanding of what the actual circuit is doing and to be able to connect tool output (e.g. the gates your synthesis tool has produced) and your HDL. Here the typical flow of HDL -> SystemVerilog -> tool output can become a big problem. The HDL to SystemVerilog step can produce very hard to read code that's hard to connect to your input HDL. This adds a new and tricky mental step when you're working with the design, first understand the circuit issue then map that to the hard to read SystemVerilog then map that to your HDL and work out what you need to change. Outside of design alone a major cost of building silicon is verification. Alternative HDLs generally don't address this at all and again can make it harder. Either you entirely simulate the HDL itself which can be fine but then you're banking on minimal bugs in that simulator and there's no bugs in the HDL -> SystemVerilog step. Alternatively you simulate the SystemVerilog directly with an existing simulator but then you've got the HDL to SystemVerilog mapping problem all over again. I think my ideal HDL at this point is a stripped down SystemVerilog with a good type system, better generative capability that crucially produces plain system verilog that's human readable (maintaining comments, signal and module names and module hierarchy as much as possible).