A more relevant point that would disqualify Haskell is the fact that its runtime (or rather, the GHC's runtime) is nowhere near predictable enough for the realtime guarantees that time synchronisation software would require.
A Haskell DSL that outputs some safer low-level code would be a more likely choice (for example http://hackage.haskell.org/package/atom), but Rust is both more popular and has more commercial support.
When opting for a DSL that compiles to low-level the "Haskell" part is less important.
I've heard the idea of DSLs over and over again, but who actually does that? I know of course of sed, awk, regex, etc but what part of NTPsec is narrow enough in scope and large enough in volume to justify creating a DSL? (just asking -- I'm not familiar with NTPsec).
Re:Getting Past C
by nickpsecurity on Tuesday January 03, 2017 @09:25PM
(#13315183)
Companies that like consistently getting results. Example:
(And I have made terrible experiences with JVM's GC, but never tried tuning).
Some people don't believe that extremist functional languages are needed (depending on the domain).
Validation. Oh, well.
I think you propose Haskell, and it might disqualify for an NTP daemon, for example in terms of debuggability (stack traces?).