Something to keep in mind - linear types are on their way[1], with exactly this usecase in mind. Simon Peyton Jones gave an excellent presentation on the topic[2], briefly discussing exceptions, as well as giving a mention to ResourceT and the phantom type solution in the article (described as channel-passing).<p>[1] <a href="https://arxiv.org/abs/1710.09756" rel="nofollow">https://arxiv.org/abs/1710.09756</a>
[2] <a href="https://www.youtube.com/watch?v=t0mhvd3-60Y" rel="nofollow">https://www.youtube.com/watch?v=t0mhvd3-60Y</a>
The thing is that, in Haskell, even when you attach a function to run during destruction, the runtime doesn't guarantee that the function will be called promptly, or even at all. Rust drops (runs destructor and deallocates) values as soon as they go out of scope; C++ too. In Haskell you depend on the whims of the GC, which makes RAII unusable. (The Haskell approach of not guaranteeing destructors being called does have its merits; when many C++ and Rust programs are about to end, they spend the last few cycles uselessly deallocating memory that would've immediately been freed via _exit(2)).<p>Therefore the RAII style wouldn't really work in Haskell. The current bracket approach is still better than RAII in Haskell.<p>That said, the ST-style trick of a phantom type variable is pretty well-known. Unfortunately not many people knew the same trick can be used for non-ST as well. I feel like as a community we should be encouraging this style more often.<p>UPDATE: I wrote the original comment with the incorrect assumption that drop functions will always be called in Rust. This is wrong. Please see child comments.
You can also have the exact opposite problem with RAII, where a resource survives the end of a transaction, because there is still a live reference to it hidden away somewhere (say, due to some debugging code holding on to it).<p>This is a classical liveness vs. safety dualism. "Something good will eventually happen" and "nothing bad will ever happen" are promises whose solutions are often in conflict with one another.<p>The general problem — to make transactional state changes and transactional control flow (i.e. expectations about these state changes) match up precisely — is not easy to solve in the general case, especially once you move on to things that are less trivial than simple resource acquisition/release matching.
How do you handle errors at resource release? When you close a file, the final writes take place, and they can fail. What's the idiom in Rust for getting them out?<p>Python's "with" clause, and the way it interacts with exceptions, is the only system I've seen that gets this right for the nested case.
Interesting! Michael is one of the more prolific writings and practitioners in the Haskell space (I read just about everything he writes) so it is interesting to also read his take on Rust.
tl;dr - Try rust.<p>The mechanic point of this article is pretty clear:<p>- it's possible to be unsafe in both Haskell and Rust when dealing with resource cleanup<p>- Rust does a bit of a better job in the general case though it has it's own warts (see the other comments, it's hard to deal with issues during `drop`-triggered cleanup)<p>I want to make a muddier meta point -- Rust is the best systems language to date (does anyone know a better one I can look at?).<p>- The person who wrote this article Michael Snoyman[0] is mainly a haskell developer, he's the lead developer behind arguably the most popular web framework, yesod[1].<p>- Haskell developers generally have a higher standard for type systems, and spend a lot of time (whether they should or not) thinking about correctness due to the pro-activity of the compiler.<p>- These are the kind of people you <i>want</i> trying to use/enjoy your language, if only because they will create/disseminate patterns/insight that make programming safer and easier for everyone down the line -- research languages (Haskell is actually probably tied for the least "researchy" these days in the ML camp) are the Mercedes Benz's of the programming world -- the safety features trickle down from there.<p>- Rust is <i>not</i> a ML family language -- it's a systems language<p>- People who write Haskell on a daily basis are finding their way to rust, because it has a pretty great type system<p>When was the last time you saw a systems language with a type system so good that people who are into type systems were working with it? When was the last time you saw a systems language that scaled comfortably and gracefully from embedded systems to web services? When have you last seen a systems language with such a helpful, vibrant, excited community (TBH I don't think this <i>can</i> last), backed by an organization with values Mozilla's?<p>You owe it to yourself to check it out. As far as I see it rust has two main problems:<p>- Learning curve for one of it's main features (ownership/borrowing)<p>- Readability/Ergonomics (sigils, etc can make rust hard to read)<p>Admittedly, I never gave D[2] a proper shake, and I've heard it's good, but the safety and the emphasis on zero-cost abstractions Rust offers me makes it a non-starter. Rust is smart so I can be dumb. C++ had it's chance and it just has too much cruft for not enough upside -- there's so much struggle required to modernize, to make decisions that rust has had from the beginning (because it's so new). It might be the more stable choice for a x hundred people big corporate project today or next month, but I can't imagine a future where Rust isn't the premier backend/systems language for performance critical (and even those that are not critical) programs in the next ~5 years.<p>I'll go even one step further and say that I think that how much rust forces you to think about ownership/borrowing and how memory is shared around your application is <i>important</i>. Just as Haskell might force you to think about types more closely/methodically (and you're often better for it), Rust's brand of pain seems instructive.<p>[0]: <a href="https://www.snoyman.com/" rel="nofollow">https://www.snoyman.com/</a><p>[1]: <a href="https://www.yesodweb.com/" rel="nofollow">https://www.yesodweb.com/</a><p>[2]: <a href="https://dlang.org/" rel="nofollow">https://dlang.org/</a>