[mjhoy]

I'm particularly excited about the prospect of linear types; not so much for helping with space/GC efficiency (which is good of course) but for modeling state transitions and ensuring that, for instance, some intermediate state must get consumed once and only once. It's one of the bugs I often run into when writing Haskell code.

[kccqzy]

The linear type hype is a bit overblown. As one skeptical GHC developer has said, there’s not a single concrete example of how linear types would help real-life code. Haskell already has great facilities to handle state transition; linear types isn’t needed to ensure “some intermediate state must get consumed once and only once.”

[drb226]

"linear types isn’t needed to ensure “some intermediate state must get consumed once and only once.”"

If you don't use linear types to ensure this, then you're probably not ensuring it, and it just comes down to "hopefully the programmer eyeballed it correctly and read the docs."

[kccqzy]

More than 20 years ago people solved the token-that-must-be-consumed-once problem with the IO monad. Just a secret token that gets threaded everywhere. The monadic bind is just great syntactic sugar.

Also more than 20 years ago people figured out a way to keep separate tokens completely independent and forbid them from interacting with each other. That’s the phantom `s` type variable in ST.

Nowadays we have so many more complicated solutions (not all of them worthwhile!) giving you choice how you want to make sure an intermediate state is consumed once. Why not implement a state machine at the type variable using DataKinds, TypeFamilies et al?

Or you know, for the case of ensuring file handles/database connections get closed correctly, use monadic regions: http://okmij.org/ftp/Computation/resource-aware-prog/region-... (disclaimer: I haven’t read this paper or used this approach myself but I heard it’s a good technique)

But more importantly, even if introducing linear types can make what’s currently barely doable in Haskell easily doable, maybe even replacing five language extensions with one, does it have a good power-to-weight ratio? I’m not convinced. Is the kind of mistakes prevented by this language extension often made by typical Haskell programmers? My answer is no.

[dllthomas]

> Is the kind of mistakes prevented by this language extension often made by typical Haskell programmers? My answer is no.

The kind of mistakes often made by Haskell programmers interacting with objects not well managed by the Haskell garbage collector? Yes, absolutely. Whether there's enough Haskell programmers in that situation, I am unsure; quite possibly not, but it includes me and my colleagues, as well as those currently doing the work.

[tome]

> Is the kind of mistakes prevented by this language extension often made by typical Haskell programmers? My answer is no.

Well no, but that's because Haskell has garbage collection ...

[mjhoy]

> there’s not a single concrete example of how linear types would help real-life code

Given what Rust has achieved in terms of memory management, that seems like a strange claim to make?

There are also some rather concrete examples here:

http://edsko.net/2017/01/08/linearity-in-haskell/

[kccqzy]

What Rust has implemented is very different from the current linear type proposal in Haskell world.

[kuwze]

Does motor[0] work for your use case?

[0]: https://hackage.haskell.org/package/motor