6 ms·
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 o
by annabellish 8y ago
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 8y agoYou 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 8y agoI googled "Midori outcomes", but I only found your posts mentioning it. Have a better keyword to search or a link?
- tveita 8y agohttp://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/ is a good set of articles about the Midori project.
- pjmlp 8y agoIt is a path to enlightenment with multiple stops. :) Start with Joe Duffy blog posts about Midori architecture. http://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/ Then hop on to his talks. "Safe Systems Programming in C# and .NET" https://www.infoq.com/presentations/csharp-systems-programming https://www.infoq.com/presentations/csharp-systems-programmi... "RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy" https://www.youtube.com/watch?v=EVm938gMWl0 https://www.youtube.com/watch?v=EVm938gMWl0 Then you can watch "Inside .NET Native" from Channel 9 https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native Finally there are the specs and related discussions that lead up to C# 7.3 design. https://github.com/dotnet/corefxlab/tree/master/docs/specs https://github.com/dotnet/corefxlab/tree/master/docs/specs The TL;DR; version, basically async/await, the UWP AOT compiler, improved handling of value types, spans (aka slices), improved GC (TryStartNoGCRegion()) have their roots in System C# used in Midori. Also there are some influences of Singularity, namely Bartok and MDIL, on the WP 8.x AOT compiler, but that is not longer relevant.
- kccqzy 8y agoI 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.