[annabellish]

I don't know if it's fair to call that "the Haskell approach", per-se. That destructors are not guaranteed to run, or run predictably, is generally a property of all fast garbage collectors. If you want a GC that can run quickly, which in a language like haskell where you're going to get lots of small allocations in contexts it would be difficult-to-impossible to efficiently determine the exact moment scopes die, or get the programmer to, you absolutely do, then one of the costs of that is you can't afford to run code for every destroyed object.

The linked post is interesting, because I didn't realise "RAII is a much better way of managing resources than destructors" was controversial. It absolutely is, RAII is fast, predictable, and flexible. It's also one of the tradeoffs some languages make to achieve more flexibility in their design by enabling performant automatic garbage collection that doesn't require perfect escape analysis.

[pjmlp]

You can have both, GC, static allocation and RAII, like in Modula-3 for example.

Which .NET is finally arriving to, thanks to Midori outcomes. And Java might eventually get there as well, depending on how Project Valhalla ends up.

As for languages like Haskell, a mix of bracket and linear types might be the way to go.

[naasking]

I googled "Midori outcomes", but I only found your posts mentioning it. Have a better keyword to search or a link?

[kccqzy]

I think you misunderstood me, but nevertheless I still agree with your first paragraph.

The linked article was comparing RAII with the bracket approach, not the destructor approach.