[whateveracct]

The F in FP definitely hugely benefits from GC. Closures in Rust don't compare to Haskell.

Combine that with GHC's optimizer and it's no contest which language to choose if both ergonomics and performance of code written largely as lambdas is your priority.

[lambda_obrien]

With linear types you could get rid of the GC, probably.

[steveklabnik]

The core issue here isn't exactly GC, though it is related. The issue is that abstraction is about hiding things, and Rust's type machinery is about exposing things. In Haskell, you have lambdas, and you have types of all of the same size data, because it's all on the heap. In Rust, each closure is a distinct type, plus the three different types of closures, plus types of different sizes...

It's not so much the GC, as it is "in a GC'd language, everything is on the heap and a lot of information (from Rust's perspective) is erased." You may be able to get rid of GC in some sense, but you'd end up with something halfway to Rust, not the whole way.

[lambda_obrien]

> Rust's type machinery is about exposing things

That makes sense, thanks for explaining that, I am used to Haskell but never used Rust.

[steveklabnik]

No problem. I mean, in some sense, it's also about abstracting things, it's just that Rust cares about a lot more details than other languages, and those get reflected in type signatures.

[whateveracct]

Hm ATS is prior art re: linear types and closures. It's definitely not the same.

That said, -XLinearTypes in GHC 9.x will open up a world of memory management capabilities in library-space for Haskell. Very exciting stuff! If you push the heavy stuff off-heap, then the GC just becomes a slightly fancier arena allocator.

[lambda_obrien]

I'm very interested in that. I was using zig for a while, and I wish I could build my own (simple) memory allocators for certain things in Haskell like that. I have a project where I want to be able to directly control the memory layout of the data structures but since that's just a tiny part of the whole program I don't want to build the whole thing in zig or something like C, I prefer Haskell for this specific purpose (it's a stream processing application with a small [code-wise, the data set can be huge] in-memory tree database which I want to be able to do the memory object allocation for myself).

[whateveracct]

Yeah you can do that. I'm actually working on a little library to do just that (control memory layout) although it's more focused on 0-copy FFI w/hsc2hs

You can also have the RTS manage the memory itself, but have complete access to a pointer to raw memory. That doesn't work if you have pointers in the raw memory ofc, but it is a nice option if that's not the case.

[lambda_obrien]

If you don't mind, can you send me your repos if it's public work? I'm interested in 0-copy stuff, too, the database I'm doing can benefit from 0-copy (again, a small part of the codebase but a big part of the technical challenge), and I'm seeing that linear types help a lot with that kind of thing from the reading I've done lately. I'm mostly a tinkerer and like to see what's the newest cool stuff people are making. My email is in my profile.

[whateveracct]

Will do!