# One Billion Row challenge in Hs

**URL:** <https://discourse.haskell.org/t/one-billion-row-challenge-in-hs/8946>\
**Category:** Links\
**Created:** [March 3, 2024, 8:24am UTC](https://discourse.haskell.org/t/one-billion-row-challenge-in-hs/8946 "2024-03-03T08:24:38Z")\
**Posts on this page:** 1\
**Showing post:** 189

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [March 21, 2024, 5:52am UTC](https://discourse.haskell.org/t/one-billion-row-challenge-in-hs/8946/189 "2024-03-21T05:52:01Z")

</div>

(_ahem_) …speaking for myself here: I wasn’t so much _“sneering”_ at (the use of) entities like `deepseq`, but a prevailing impression that they (unfortunately) seem to accentuate:

- that laziness/non-strict semantics are now more of an impediment than being of ongoing benefit to Haskell,

- and little if anything would be lost if Haskell were strict by default.

(Again, this is merely how **I’m** perceiving the current situation).

So it is to that impression that I say:

- did someone solve the halting problem?

- or is Haskell going to eventually be total as well as dependent?

Because without either of those, being strict by default generally means more programs won’t produce a useful result **at all.** Therefore definitions like `deepseq` (or `compel`, as I mentioned [here](http://discourse.haskell.org/t/th-deepstrict-enforcing-deep-strictness-of-datatypes-using-th/8789)) along with other _“strictness modifiers”_ should ideally be considered _“features of last resort”_ because of their potential for non-termination.

So how can we get to that ideal? This looks promising:

> [@](#):
>
> (page 10 of 12)
> 
> Our goal is to allow a programmer to write programs in a  
> lazy language without having to use strictness annotations  
> in order to obtain good performance.
> 
> [Optimistic evaluation: an adaptive evaluation strategy for non-strict programs.](https://web.archive.org/web/20130610122750/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.9901&rep=rep1&type=pdf) (2003).

…if the multi-threaded RTS does have to be overhauled to solve the “_N_ \> 4” problem observed by @chreekat and others, can any of Robert Ennal’s research be reused as well, so that _comments_ like:

> [@Mysterious performance difference](http://discourse.haskell.org/t/mysterious-performance-difference/8962/3):
>
> “If in doubt, bang it out” slight_smile Shebangs all over the place seem to help. Reminds me a little bit of the cut operator in Prolog.

…_ **don’t** _ end up being treated as basic advice when using Haskell?

---

_[View the full topic](https://discourse.haskell.org/t/one-billion-row-challenge-in-hs/8946)._