I probably should have said this in my previous comment (the GP), but I mainly work in embedded systems. I need to be able to reason about the low-level behavior of the system more than I need better high-level abstractions.
And getting to write large amounts of my system inside monads (because of lots of mutable state)... that doesn't look like a solution to me. It looks more like a problem.
Are there high-level abstractions that would simplify my view of this? Probably. Would getting those abstractions to behave as needed on the low level be a net win, or a net loss? My money is on the "net loss" side.
That's a bet I would take any day and I think you probably don't need the low level access you think you do. It's largely due to historical architectural decisions that people think so.
Atom is a Haskell DSL for designing hard real-time embedded software. At Eaton, we use it for automotive control systems. Based on guarded atomic actions, and similar to software transactional memory, Atom enables highly concurrent programming without the need for mutex locking. In addition, Atom performs compile-time task scheduling and generates code with deterministic execution time and constant memory use, simplifying the process of timing verification and memory consumption in hard realtime applications. Without mutex locking and run-time task scheduling, Atom can eliminate the need and overhead of RTOSs for many embedded applications.
"""
And getting to write large amounts of my system inside monads (because of lots of mutable state)... that doesn't look like a solution to me. It looks more like a problem.
Are there high-level abstractions that would simplify my view of this? Probably. Would getting those abstractions to behave as needed on the low level be a net win, or a net loss? My money is on the "net loss" side.