Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"I think what you're actually talking about is really the desire for Referential Transparency[0] vs. the mutable/immutable distinction."

I don't think so... in the arrangement I'm talking about nothing stops you from getting input from an arbitrary source. I suppose this implies there should only be one witness to the change at a time, but that's not all that hard of a restriction.

"Of course mutability can prevent algebraic reasoning and trivial reuse via simple algebraic extraction of code/functions, but so can strictness, so..."

Indeed... if we're going to write off a class of useful things, let us make sure we get as much benefit from it as possible. And I can't imagine Rust dropping default-strict anytime soon... in the domain it seeks to conquer it is arguably the correct choice even from a Haskell perspective. Haskell lacks that truly low-level systems orientation.



Input from an arbitrary source (i.e. without referential transparency) implies that there can be no equational reasoning, almost by definition. This is kind of the case for IO in Haskell[0], but for subprograms/procedures/functions I tend to find it an absolutely essential property, both in terms of reasoning and in terms of testability. For example, it's the whole reason that QuickCheck works.

[0] Modeling IO as a World->World function doesn't quite work.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: