Functional Reactive Programming

Elm is not dead. It just prefers a slow release schedule but is still actively worked on in the background.

That said, you might want to check out OCaml for general purpose programming. Super fast compiler, great performance, can target both native and JS.

It is easier to use than Haskell due to defaulting to eager evaluation (like most languages) strategy instead of laziness and being generally more pragmatic, offering more escape hatches into the imperative world if need be. Plus great upward trajectory with lot's of cool stuff like an effects system and multi-core support coming.

Real World Ocaml is a decent resource: https://dev.realworldocaml.org/

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience.

Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module.

Refactoring data-flows that go through multiple modules is a huge hassle. Sometimes, we would spend hours just refactoring data-passing, wrapping and unwrapping and tests surrounding modules, because we needed to pass some additional values.

It doesn't help that you have to set up all behaviours at setup time, which means the code is mixed with one-time setup code which regularly confused people working on the projects as to what is run at startup time and what is run per-event.

Debugging itself was mostly hampered by the libraries that we used not providing adequate tools for the job but even if they did, it was a lot more difficult to reason about compared to something like async/await based code or callback chains.

I can imagine FRP works better in purely functional languages but implementing FRP paradigms in general purpose languages - especially when interfacing with non-functional code, which is often necessary - has led to nothing but trouble for me.

I have high hopes for the young Gren fork of Elm https://gren-lang.org/.

Yeah totally the opposite. I really like RxJs and used it along side my senior dev for good effect at my last perm for several years. Our junior did find it a bit tricky sometimes though (edit: I don’t mean to imply you weren’t “senior” enough, just an observation that it was a new set of concepts to learn).

We would literally never use promises because we’d become so comfortable with how we (and angular) managed the lifecycle of observables. And we never ever used a async/await after some nasty bugs in previous projects. We never started making our own operators. And I think we never really got too complex with it. RxJs marbles and learnrxjs were often consulted. But the code seemed nice and clean and reliable. Testing was more difficult and harder to understand but we got there.

We switched to using NgRx for our state quite early in the project after a brief flirtation with observable services, so that probably pushed us further down the observable route. We kept NgRx up to date and found the helper functions really nice so there wasn’t too much boilerplate. Making new selectors and integrating them into components with the async pipe is just so damn easy with NgRx and RxJs. Effects would get mildly stupid in terms of complexity and I did have a habit of hilariously writing “these were your father’s parentheses” at the end of any particularly long set of closing parens... but yeah it seemed to just work and give us relatively few bugs and none that I recall were hard to track down. It was all very smooth.

The only thing I’d ever really complain about on that project other than our build times was MSAL, which I hated with a passion.

OCaml fits the bill for me. It is an amazing language, very practical, fast, and easy to code with. It is a shame that I didn't discover OCaml sooner.

FWIW, I tried Elm, Haskell, PureScript, Elixir.