Joachim Breitner, a Haskell developer, writes about GHC, formal proofs, and small programming and hardware experiments.
HN commenters link it for background on bootstrapping GHC and for his practical posts on vector screenshots and tools like arbtt.
Lots of people complain about performance reasoning in Haskell being hard, which is partially true. But mostly, IMO it is simply different from doing so in C, so you need to unlearn/relearn all your performance tweaking skills.
I don't agree. First, of all, the naive solution in C is often pretty fast, while the naive solution in Haskell often has obnoxious runtime properties.
Then, most C optimization performance reasoning applies to Haskell as well: keep your data small, in contiguous memory, etc. The first thing that complicates optimization in Haskell is that defacto Haskell data structures are the opposite: pointer/thunk-rich. So, you usually end up with libraries such as 'vector', doing the heavy lifting in the ST monad.
Then, laziness adds even more complications, both in that it adds a new class of bugs (of course, Haskell removes buffer overflows et al.) which tend to be relatively hard to debug (the heap explodes in less expected places).
When you write production code, you usually accumulate some monads. Unfortunately, the relatively obvious way to use multiple monads (monad transformers) is slow. So, you have to roll your own monad stacks:
https://wiki.haskell.org/Performance/Monads
---
In the end, even something as simple as reading a list integers in the IO monad can be an exercise in frustration:
http://www.joachim-breitner.de/blog/620-Constructing_a_list_in_a_Monad
The same can't be claimed for C. Even a newcomer could do it.
An even more extreme case of this is trying to bootstrap a compiler from the first version, e.g.:
http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC
"""So it seems that besides GHC, only ever HBC was used to compiler GHC.
HBC is a Haskell compiler where we find the sources of one random version only thanks to archive.org.
Parts of it are written in C, so I looked into this:
Compile HBC, use it to compile GHC-0.29,
and then step for step build every (major) version of GHC until today.
....
[M]ost of [HBC] is written in LML, and the LML compiler is written in LML."""
Oh yes! At least Kobo readers are Linux and you can SSH in. You could even install another distro I believe. Some ugly hack could be rendering the display content on your machine and just sent the image over.
https://github.com/koreader/koreader uses Lua so maybe one could add some bidirectional or at least PC->Reader flow of data.
edit: VNC! https://www.joachim-breitner.de/blog/660-Using_my_Kobo_eBook_reader_as_an_external_eInk_monitor
For Haskell, the libgmp stuff is being solved in GHC 9.0
https://iohk.io/en/blog/posts/2020/07/28/improving-haskells-big-numbers-support/
It is true that getting static Linux builds is nontrivial - but definitely doable [1]! But the demand is there so I'm guessing the elbow grease will follow in the coming few years :)
[1] https://www.joachim-breitner.de/blog/776-Distributing_Haskell_programs_in_a_multi-platform_zip_file
Here is some background on the Haskell situation: https://www.joachim-breitner.de/blog/802-More_thoughts_on_a_bootstrappable_GHC
Ada has had even less progress and I am not aware of any writeups.
TL;DR: Ada and Haskell need to have compilers implemented a language that has a full source bootstrap path such as C, Go, or Rust that implement just enough features to compile the official compilers.
I believe there was a post about this earlier that the game is solved[1]. Interesting game for those who don't know that, or who want to go through the exercise to figure out the correct strategy.
[1] https://www.joachim-breitner.de/blog/archives/604-Ultimate-Tic-Tac-Toe-is-always-won-by-X.html