The vast majority of systems people build do not have hard real-time requirements. People have built video games, real-time audio, and all sorts of other soft-real-time systems with Haskell
No they aren’t soft real time systems either, most applications in general a don’t satisfy soft real time requirements.
Most people hack it but hacking it with Haskell requires rewriting your pure functional code into a form that strongly resembles procedural languages like C. This defeats the purpose of a lazy pure functional programming language.
There's only one industrial Haskell codebase I've worked on, and although parts of it were very procedural, that was probably less than half the codebase, even including the IO-bound code. Sure it's one way to use the language, but it's certainly not the only one.
Most applications are buggy and crappy. Sure, if you’re churning out minimally passable garbage for a paycheck, then don’t worry about correctness or timing requirements and pray for the best. Cf. Slack desktop client. If you are producing something that necessarily has a higher quality bar then these things matter, e.g. an aircraft control interface. Haskell isn’t up to the challenge (imagine indefinitely waiting without feedback for a long-lived heavily nested thunk to evaluate when you press “land” ouch).
And for the record Java and other garbage collected languages are not generally suitable for interactive applications either. Anyone who has ever waited on a GC pause can attest to that. This is the exact reason Rust exists and why people continue to use C/C++ despite being inconvenient languages to use.
Looking through that repository, I believe we have extremely different definitions of "vast majority."
> The vast majority of the code in that repository is in the IO monad and uses carefully placed “!” eager evaluation annotations.
Do you have anything to back that up?
First of all rendering is not by definition I/O except in the trivial sense that all functions take input and produce output. A pure 3D rendering function takes game state as input and produces a list of triangles + attributes to draw as output.
Even if that were true it would only further validate my point.
> Do you have anything to back that up?
Yes, I already showed that Render.hs validates my point.
This is the claim we're talking about. Since you're into facts, not subjective opinions, show some evidence that the vast majority of the code in the repository is in the IO monad and uses carefully placed "!" eager evaluation annotations. Just to be clear, you haven't done that yet. That's a fact, not a subjective opinion.
https://github.com/rainbyte/frag/blob/master/src/BSP.hs
On every source file:
{-# LANGUAGE BangPatterns #-}https://github.com/rainbyte/frag/blob/master/src/BitSet.hs
https://github.com/rainbyte/frag/blob/master/src/Command.hs
https://github.com/rainbyte/frag/blob/master/src/Curves.hs
BangPatterns is a normal language extension to have enabled, was this used heavily? (hint: it's not enabled on "every source file.") You listed two of 28 files there, I'm assuming to try to show that the vast majority of the code in that repository is in the IO monad? You went from "vast majority" from one file to now two files. I'm looking for objectivity here, as you seem to be into. Let's see some numbers. I think anyone that glances at that repo would need some convincing of your claims.
Render.hs is 211 of 5580 lines of Haskell in the repository, by the way.
People attempt to program interactive systems with Haskell but then they spend most of their time adapting their program to GHC’s particular evaluation strategy. Usually the optimized program ends up convoluted and nothing like how Haskell code should look, additionally still with no guarantees on the run time.