5 ms·

Are you saying there's a way to use haskell without the GC or other runtime overhead? I like rust because it doesn't have much in the way of runtime requiremen

Are you saying there's a way to use haskell without the GC or other runtime overhead? I like rust because it doesn't have much in the way of runtime requirements (almost zero, like C).

runeks 9y ago
> Are you saying there's a way to use haskell without the GC or other runtime overhead? There isn't yet, but there will be when, first, the LinearTypes extension arrives (scheduled for GHC 8.4) and, secondly, GHC's garbage collector is modified to take of advantage of the fact that linear types are always consumed exactly once. This will take 1-2 years or so. After this it should be possible to write no-runtime-overhead Haskell functions by using the "lollipop" arrow after an argument, and then consuming that argument exactly once in your function. So you will have to split your functions into small enough functions, that consume their arguments exactly once, and then compose them into something that will not need a garbage collector at runtime. In theory you could write an entire application this way, although in practice you probably wouldn't bother avoiding the GC for the outermost constructions of your program, since this would offer little in performance gains and be a lot more difficult (remember, a no-GC function must consume its arguments exactly once). But time will tell how this will compare to something like Rust's borrow checker.
evincarofautumn 9y ago
There’s been some work lately by Tweag I/O on a linear types extension to GHC.[1][2] It would allow us to safely allocate things from malloc memory or a “linear heap” separate from the main GC heap, and that should reduce pause times by reducing GC pressure, but I don’t think we’ll ever be able to avoid the GC entirely. However, we can still expect some nice performance advantages from the fact that linear types can enforce guarantees about inlining & fusion (which are currently somewhat unpredictable) as well as resource lifetimes. [1]: https://github.com/tweag/linear-types https://github.com/tweag/linear-types [2]: https://github.com/tweag/ghc/tree/linear-types https://github.com/tweag/ghc/tree/linear-types

Are you saying there's a way to use haskell without the GC or other runtime overhead? I like rust because it doesn't have much in the way of runtime requirements (almost zero, like C).

runeks 9y ago

> Are you saying there's a way to use haskell without the GC or other runtime overhead? There isn't yet, but there will be when, first, the LinearTypes extension arrives (scheduled for GHC 8.4) and, secondly, GHC's garbage collector is modified to take of advantage of the fact that linear types are always consumed exactly once. This will take 1-2 years or so. After this it should be possible to write no-runtime-overhead Haskell functions by using the "lollipop" arrow after an argument, and then consuming that argument exactly once in your function. So you will have to split your functions into small enough functions, that consume their arguments exactly once, and then compose them into something that will not need a garbage collector at runtime. In theory you could write an entire application this way, although in practice you probably wouldn't bother avoiding the GC for the outermost constructions of your program, since this would offer little in performance gains and be a lot more difficult (remember, a no-GC function must consume its arguments exactly once). But time will tell how this will compare to something like Rust's borrow checker.

evincarofautumn 9y ago

There’s been some work lately by Tweag I/O on a linear types extension to GHC.[1][2] It would allow us to safely allocate things from malloc memory or a “linear heap” separate from the main GC heap, and that should reduce pause times by reducing GC pressure, but I don’t think we’ll ever be able to avoid the GC entirely. However, we can still expect some nice performance advantages from the fact that linear types can enforce guarantees about inlining & fusion (which are currently somewhat unpredictable) as well as resource lifetimes. [1]: https://github.com/tweag/linear-types https://github.com/tweag/linear-types [2]: https://github.com/tweag/ghc/tree/linear-types https://github.com/tweag/ghc/tree/linear-types