5 ms·
As an almost two decade Haskeller who really wants to try Rust in a performance and security sensitive production context, I really appreciated this article. Ho
by SomeHacker44 8y ago
As an almost two decade Haskeller who really wants to try Rust in a performance and security sensitive production context, I really appreciated this article. However, it might have actually pushed me more toward Haskell. I have decades of experience in C-derived languages and the syntax is just not my favorite, compared to Haskell and LISPs.
Of course, given the 3,619,661 compiler extensions in GHC, whats another that would enable this sort of lifetime/reference tracking (and endless chasing of type errors that all Haskellers are used to anyway) functionality to be pushed into the type system? I almost cannot imagine it has not been done.
Great article!
- pdpi 8y agoFiguring out lifetimes in the face of Haskell's laziness sounds like a daunting prospect to me. Ultimately, there doesn't have to be a language to rule them all. Rust does things well that Haskell doesn't, and vice versa, and that's just fine.
- SomeHacker44 8y agoOh, for sure. Very focused languages are great. Haskell (well, GHC) just seems to be a great resource for trying language features out. No argument that laziness could be an issue, but IO generally has to resolve thunks anyway to occur so it may not be an insurmountable one. Note that I do not know particularly much about GHC internals.
- garmaine 8y agoNot really, as the point of affine types is that this is pushed into the type system. It has the semantics “if a thing is produced, it is consumed at most once.” I don’t see how this is any more difficult than, or really any different from regular Haskell programming.
- twic 8y ago> course, given the 3,619,661 compiler extensions in GHC, whats another that would enable this sort of lifetime/reference tracking (and endless chasing of type errors that all Haskellers are used to anyway) functionality to be pushed into the type system? Rust-style ownership semantics exert strong design pressure on libraries, including the standard library. Rust's ecosystem has evolved under that pressure; Haskell's has not. I have no doubt at all that Haskell could be extended with affine types (never go in against a Haskeller when a conference paper is on the line!), but once you'd done that, you wouldn't be able to use any existing libraries. Which, given the state of the Haskell ecosystem, might be a bit of a relief.
- pcwalton 8y agoThis is also the reason why bolting lifetimes on to C++ is not really feasible while still being able to call the resulting language C++.
- pjmlp 8y agoThey are being bolted on static analysis tools. So yeah, optional tooling quite often doesn't get used and is imperfect. On the other hand, many will not move if they can get 80% there, while keeping their tooling and libraries.
- pcwalton 8y agoObviously we disagree about whether any attempts to add lifetime analysis to C++ gets anywhere near 80% of what Rust can provide.
- garmaine 8y agoActually no, Linear Haskell works in a fully backwards compatible way with existing libraries. I suggest checking it out.
- twic 8y agoWhat would you suggest i read? I have got the 'Retrofitting Linear Types', and a quick scan suggests it doesn't give concrete examples of that backwards compatibility (although it probably follows from the proofs, which i have not digested yet!). Is there something more practical?
- garmaine 8y agoThere's a bit more said about it here: https://arxiv.org/pdf/1710.09756.pdf https://arxiv.org/pdf/1710.09756.pdf
- nimish 8y agoNothing. Linear types are being added to GHC and could be used to implement this feature. But libraries would need to be upgraded to offer them.