Software engineers can sometimes find it difficult as with a HDL you (should) describe hardware that exhibits the intended behaviour, rather than just directly describing the behaviour.

HDLs have familiar syntax that makes it seem like you can just program algorithms imperatively (for loops, if statements, functions etc) but it's all just a mean trick to catch software people out, and generally won't give the results you expect.

On top there's then the fact everything happens at the same time, the faff of making everything synchronised and making sure it meets timing and fighting the frankly awful tooling every step of the way.

Once you get it, it's fine, but you have to unlearn a lot of software muscle memory and keep the actual design work (boxes and lines) almost entirely separate from the implementation (typing your boxes and lines into a text editor).

FPGA programming is like another level below assembly programming.

In high-level languages you got functions, variables and scopes while in assembly you need to build them yourself using more primitive units, i.e. instructions and registers.

In assembly you got many helpful instructions and easy memory access while in FPGAs and ASICs you have... nothing. Only wires and boolean logic.

It allows you to build some things extremely efficiently, e.g.: Press button 1 and 2 to activate LED 1. No clocks, no memory accesses, no I/O polling or interrupts, just a direct connection from some inputs to others with some logic in between.

Although there are many modern tools, libraries and IP blocks to make FPGA programming easier or even possible with languages like Scala or C++, it usually takes way more time to build anything compared to doing it with the help of a CPU.

The hard part is not the "programming" part; it's boolean logic, if you understand how your machine works at the gate level, it makes sense as a kind of pseudo-declarative model of the bits of the machine. I found Verilog / SystemVerilog very intuitive and fun to work in. Not that I ever did it for a living, but it was entirely comprehensible to me after some practice. I went from newbie to wiring up my own simple video chip & character generator to a RISC-V core in a month or two.

The hard parts are...

a) the "fuzzy" bits -- timing, propagation delays, etc. the tool will warn you about it but it's not always easy to understand. It's easy to end up with a mess that makes perfect sense "logically" and works in your sim, etc. but actually only sorta works in meatspace.

b) the tools. They all want to ram you into their shitty 1000lb IDEs which are forks of Eclipse from 15 years ago with a heaping dose of Tcl on the side and only work in some specific version of RedHat or whatever. Forget about using your preferred editor or IDE or build tool, they want to ram you through their GUI. You can sometimes route around it, by reverse engineering their Tcl and figuring out what command line invocations rae actually happening behind the heap of wizards they want to herd you through... but you'll always end up back in Quartus or whatever at some point. HW Engineers seem to be suckers for this kind of punishment.

FPGAs are actually not that hard to program, in theory. If you understand basic logic gates (and/not/nor/etc) and other logic concepts (flip-flops, latches, clocks) you can understand vhdl or verilog. And then you can write your own vhdl/verilog code (really, is it code though?). The actual difficult part is using the tooling. Intel's and AMD's development environments are designed for professionals, so they're hard to work with if you're just starting out. Add to that a liberal sprinkling of annoying bugs and workarounds, and it's actually quite frustrating to do if you aren't getting paid for the effort.

It's not necessarily harder, it's very different from writing code for CPUs and it's used to accomplish different things. Though it's different, a usually what what you're writing is smaller in scope than something written for a CPU.

It's great for stuff like driving LED matrixes, offloading crypto operations, or signal processing. Anywhere you want low latency, but simple processing.

Yes, it’s a very different paradigm than typical programming. By default, everything in hardware happens at all at once, unless you add what’a called sequential logic, which is clocked and holds state.

FPGAs are "programmed", or perhaps more accurately, "Synthesized" with hardware description languages like Verilog or VHDL.

With typical programming, you're describing software. With VHDL / Verilog, you're describing hardware. When Verilog/VHDL "runs", its just the hardware existing, ready to react to whatever happens later. There's no code that "steps" through if-statements or loops... there's instead state-machines that get stored into memory... with their outputs being directed upon physical wires you name.

As far as a "language" goes, I'd say its close to C++ Template Metaprogramming, though the syntax is very different. But the concepts are surprisingly close. C++ Templates do not compile into code, they compile into concepts and layouts... so to speak.

Well, of course C++ Templates eventually turn into C++ code. But imagine if the end result were flipflops, wires, and 1-bit memory instead. Maybe I'm describing it wrong... or maybe the only way to really know is to try it yourself.