Ada on FPGAs with PicoRV32

I looked for pretty much the same, and it seems that if you don't use problematic features, you should get closer to C than many other ways. Especially once you activate e.g. LTO compilation or so. Types that can represent bounds can allow further optimization, even possibly reducing the size of struct fields due to the internal-only way of LTO compilation.

I would not expect dev time to be longer, except for the initial learning as such/onboarding.

My reasons are apparently quite a bit more ambitious than yours though, so it's hard to compare.

The cases where I'd go for the hassle that non-standard tooling is, allow large gains from deep static analysis/formal proving of limits due to foregoing conservative, non-adaptive hardware limits. A C-version would look like seL4, including the proofs. I'd try Ada/SPARK for it automating a lot of it away and having specific features to support this "lock elision" use of software verification.

I have used Ada a lot on big projects. It takes slightly longer to develop programs, but this time lost is regained by spending less time hunting bugs. Finding good developpers in Ada is a real problem. You need at least one good developper in a team. I have never encountered performance issues (nor significant performance gain). I would choose Ada in a new project only if I am sure of the developpers competences and the problem requires complex multitasking.

Ada usually has very little overhead since it was developed with real time systems in mind.

I've worked with Ada but not deployed it in a real product, so take what I say with a grain of salt, but:

> that development time would be considerably longer

It really depends on how good the support for the platform you're working on. If it is well-supported / documented, then you'll be at least as fast as with C.

> that finding other people able to maintain the codebase would be hard

Eh, it's a pretty straightforward language, and anybody reasonably talented (which most embedded programmers certainly are) should be able to maintian it without difficulty.

> and that the resulting code would be considerably less performant than equivalent C.

Definitely not the case. Ada is basically a bare metal language (notably, no garbage collector), so it is very performant, and just as easy to reason about performance and underlying assembly code as C. There are some runtime checks that are enabled by default (e.g. bounds checking) which contribute to slightly slower performance, but these can be easily disabled if needed.

> How does it compare to "microcontroller C" with no strings and statically declared memory?

It's basically the same, but with far fewer "gotchas" to trip you up, but stricter typing and nicer semantics, together with a pascalesque syntax (more english like, without curly brackets, which you may or may not like). I've only ever used it with statically declared memory (although it does have features like memory pools which reportedly make managing heap-allocated objects easier).