That sounds like a fun project! Alexandria is the way to go for now but hopefully they will get proper support for it sooner rather than later.

Until 0.13 it wasn't quite as good as latex in my experience, it mainly inserted more hyphens than LaTeX.

As of this version, it would be very hard to tell a difference in my experience

That is for sure my biggest concern with typst. I wrote a tool that can convert from typst to latex for final submissions, but it is a bit sketchy and at the moment won't handle math very well. https://gitlab.com/theZoq2/ttt

That is a real concern, but I wouldn't say there are any critical features in the closed source portion. I wrote the whole thesis locally with only open source tools. One of the included papers was written in the cloud platform for collaboration.

It is a concern that there is a single company doing most of the development, but there is quite a bit of community involvement so I don't think it is an immediate concern

Hehe thanks for the kind words! I think once Verilog and VHDL are de-throned there will be plenty of room for more than one new HDL :) Especially if we can figure out interoperability between languages

Spade author here :) Coming from a functional programming adjacent background, the VHDL type system leaves a lot to be desired. Not supporting types with generics means you can't encode things like a genral purpose ready/valid stream. When you have those, you can start using methods to compose those streams which becomes even more powerful when you add higher order functions which allow you to transform the content of the stream without worrying about the stream details.

Spade author here!

That's a good reminder that I need to update the example on the website, I must have written that example almost 3 years ago at this point :)

For more up to date motivation, my talk from LatchUp last year is probably the best one I have https://www.youtube.com/watch?v=_EdOHbY2dlg&t=277s

> So my fear is that this new hardware description language hasn't been created by a veteran who has many years of experience in using HDLs

That's annoyingly quite close to the truth :D But I think I have enough experience now to not be completely stumbling around in the dark

Thanks for the kind words!

> The challenge of a HDL over a regular sequential programming (software) language is that a software language is programmed in time, whereas a HDL is programmed in both space and time. As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time."

That's an excellent quote, I might steal it :D In general, I think good abstractions are the ones that make important details explicit rather than ones that hide "uninteresting" details.

Spade author here! The biggest difference is that BlueSpec uses a different abstraction than standard "RTL". That has significant advantages of course, but also means some overhead and a shift in mental model.

With Spade my goal is to build new abstractions on top of RTL. That should allow you to operate at a higher abstraction level with minimal overhead most of the time, and dive down to regular RTL when necessary

Chisel, BlueSpec Spinal and Migen are already used quite a bit though of course much less so than Verilog. But we do need new languages, https://drops.dagstuhl.de/storage/00lipics/lipics-vol136-sna... does a pretty good job at articulating why