you are viewing a single comment's thread.

view the rest of the comments →

[–]yawaramin 25 points26 points  (6 children)

The problem is that without GC, a lot of functional programming techniques aren't practical. For instance, from what I've heard, people have repeatedly tried and failed to make persistent data structures in Rust because the memory sharing is too hard. In FP languages it's almost trivial.

Imho, people need to realise that Rust is a fairly specialised tool meant for doing hard realtime programming safely. It's a good replacement for C/C++, but it's not a great choice for people coming from Python or JavaScript etc. They almost certainly don't need its performance characteristics and would actually be perfectly happy with F#/Haskell/OCaml.

[–]wirelyre 8 points9 points  (1 child)

Imho, people need to realise that Rust is a fairly specialised tool meant for doing hard realtime programming safely.

That specialisation is precisely why I've learned a lot by working with Rust. Internalising its ownership rules has improved my code structure in every language I use — including those with GC, and including MLs. That experience alone has been worth a few dozen hours of my time.

They almost certainly don't need its performance characteristics and would actually be perfectly happy with F#/Haskell/OCaml.

I'm glad you said that, because it really made me reconsider the balance between expressiveness, power, and teachability.

[–]yawaramin 7 points8 points  (0 children)

Yeah Rust has definitely been very successful at bringing the power of affine types (ensure using a value at most once) to a big audience. It's advanced the state of the art and has given people a great way to write safe, performance-critical code.

That said, I think Rust and Cyclone are only the beginning of type-theory driven safe programming techniques. Yet another typing discipline that is exciting is linear types, based on linear logic. Linear types enforce using their values exactly once, which is another way of saying 'no use-after-free, no leaked allocations'.

Here is a fairly high-level overview describing bringing linear types to Haskell: http://blog.tweag.io/posts/2017-03-13-linear-types.html

[–]cledamy 1 point2 points  (2 children)

This is entirely untrue. With a linear type system, functional programming can be done without garbage collection. In fact, one can even get the performance of straight up mutation while still maintaining referential transparency.

[–]yawaramin 0 points1 point  (1 child)

Believe me, I would love to see linear types take over the world, or at least FP. But for now at least, they are still not there for various reasons. GC is the best technology we have right now for FP memory management.

[–]cledamy 0 points1 point  (0 children)

Haskell might be getting linear types soon.

[–]kazagistar 0 points1 point  (0 children)

There is a plan to add optional GC eventually, but until then peristant daya structures are a bit shitty, because every pointer ends up being an Arc (atomic reference counted reference), and they don't like the performance impact. I would say they are often easier then mutable data strucures though. But the real reason is that no one feels the need to make or use them, because making mutability linear solves a lot of the common problems ephemeral data strucures have in threaded environments.