4 ms·

I honestly can't see that. Functional programming and ownership are concepts that just don't mix well. Just think about OCaml's Set module (which uses balanced

I honestly can't see that. Functional programming and ownership are concepts that just don't mix well. Just think about OCaml's Set module (which uses balanced trees with partial sharing of subtrees as the result of set operations, if you look at the implementation).

MichaelGG 10y ago
When writing high perf F#, I wished for ownership capabilities to rely less on the GC and really get some speed. While Rust is a bit verbose, doesn't have custom operators, can't do pointfree, etc. -- it's not a bad FP language. And all the while, I get to think of how fast the code is, so that's often worth it. Rust does FP better than C# has done.
deleted 10y ago
[deleted]
milcron 10y ago
Linear types (ownership) are used in another ML-inspired functional programming language, ATS.
pjmlp 10y ago
> Functional programming and ownership are concepts that just don't mix well. Of course they do, ownership is part of substructural type systems, more precisely affine types.
- rbehrends 10y ago
  The particular problem I was getting at was that the structural sharing required by purely functional data structures is not a natural or easy task when you're restricted by affine or linear types. Several idiomatic functional programming techniques are similarly difficult to express with the additional invariants of affine types.
  - pjmlp 10y ago
    Yet there are quite a few programming languages considered functional with substructural type systems. Being easy or hard is not what defines FP.
    - rbehrends 10y ago
      Well, that was in the context of the claim that "Rust is very much ML". We weren't talking about (say) BitC here. I've got nearly two decades worth of ML code lying around (mostly OCaml, some SML and F#) and for most of it rewriting it in Rust would require significant redesign for the reasons I mentioned. This starts with even very simple things like List.rev.
      - pjmlp 10y ago
        > We weren't talking about (say) BitC here. No, we are talking in the context of ATS, LinearML, Idris, Mercury, F* and a few others.
kccqzy 10y ago
I've implemented balanced trees with partial sharing of subtrees in Rust too. Just use Rc everywhere.
- rbehrends 10y ago
  Well, that's my point. Rc<T>/Arc<T> essentially mean: "I can't figure out ownership here; let's use automatic memory management instead". The thing is that this is pervasive in ML (even simple functions like List.rev – functionally reversing a list – are a problem), so you end up having Rc<T>/Arc<T> all over the place. The underlying problem is that pure functions from data structures to data structures create multiple ownership naturally. Remember that this is about the claim that "Rust is very much ML". It really isn't. It's a totally different programming paradigm. That's not bad. Rust does some things very well that ML has a hard time with. But it's not the same.

MichaelGG 10y ago

When writing high perf F#, I wished for ownership capabilities to rely less on the GC and really get some speed. While Rust is a bit verbose, doesn't have custom operators, can't do pointfree, etc. -- it's not a bad FP language. And all the while, I get to think of how fast the code is, so that's often worth it. Rust does FP better than C# has done.

deleted 10y ago

[deleted]

milcron 10y ago

Linear types (ownership) are used in another ML-inspired functional programming language, ATS.

pjmlp 10y ago

> Functional programming and ownership are concepts that just don't mix well. Of course they do, ownership is part of substructural type systems, more precisely affine types.

rbehrends 10y ago
The particular problem I was getting at was that the structural sharing required by purely functional data structures is not a natural or easy task when you're restricted by affine or linear types. Several idiomatic functional programming techniques are similarly difficult to express with the additional invariants of affine types.
- pjmlp 10y ago
  Yet there are quite a few programming languages considered functional with substructural type systems. Being easy or hard is not what defines FP.
  - rbehrends 10y ago
    Well, that was in the context of the claim that "Rust is very much ML". We weren't talking about (say) BitC here. I've got nearly two decades worth of ML code lying around (mostly OCaml, some SML and F#) and for most of it rewriting it in Rust would require significant redesign for the reasons I mentioned. This starts with even very simple things like List.rev.
    - pjmlp 10y ago
      > We weren't talking about (say) BitC here. No, we are talking in the context of ATS, LinearML, Idris, Mercury, F* and a few others.

kccqzy 10y ago

I've implemented balanced trees with partial sharing of subtrees in Rust too. Just use Rc everywhere.

rbehrends 10y ago
Well, that's my point. Rc<T>/Arc<T> essentially mean: "I can't figure out ownership here; let's use automatic memory management instead". The thing is that this is pervasive in ML (even simple functions like List.rev – functionally reversing a list – are a problem), so you end up having Rc<T>/Arc<T> all over the place. The underlying problem is that pure functions from data structures to data structures create multiple ownership naturally. Remember that this is about the claim that "Rust is very much ML". It really isn't. It's a totally different programming paradigm. That's not bad. Rust does some things very well that ML has a hard time with. But it's not the same.