4 ms·

If you're into safety than you should probably go with a functional programming language with low-cost abstractions. Rust isn't an expressive language, its only

by idobai 10y ago

If you're into safety than you should probably go with a functional programming language with low-cost abstractions. Rust isn't an expressive language, its only benefit compared to other general purpose languages is its memory management.

mmstick 10y ago
Rust is very expressive. The main benefits of functional programming languages is contained with Rust's Iterator trait and the ad-hoc polymorphism that traits allow.
- kibwen 10y ago
  I don't know that traits in Rust are an example of ad-hoc polymorphism, since they're fully type-safe.
  - burntsushi 10y ago
    I don't think that means it isn't ad hoc. Type classes in Haskell were originally introduced as a form of ad hoc polymorphism, for example: http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/ad-hoc-polymorphism.pdf http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/a... (One of Wadler's great papers btw, worth a read.) See also: https://en.wikipedia.org/wiki/Type_class https://en.wikipedia.org/wiki/Type_class Of course, Haskell type classes and Rust traits aren't the same. But they are quite similar!
  - dllthomas 10y ago
    As I understand the term, "ad-hoc polymorphism" refers to dispatch based on types (as opposed to "parametric polymorphism", where one code path works for any type). Nothing to do with type-safety.
  - mmstick 10y ago
    Here's an example: `Stdin` and `File` both implement the `Read` trait. Therefore, you can write a function that takes the traits that you want to use as input parameters. fn do_something_with<S: Read>(source: S) { // do something with input source } Then you can do the following: let stdout = io::stdout(); do_something_with(stdout.lock()); let file = File::open(path).unwrap(); do_something_with(file); You're free to narrow down/expand the types/methods that can be used with the function if you add more traits.
  - tatterdemalion 10y ago
    "ad-hoc polymorphism" is an informal term; traits are sort of both ad hoc and parametric. I've sometimes imagined someone writing a paper about specialization and naming it "How to make parametric polymorphism less parametric" after Wadler's paper.
- idobai 10y ago
  > Rust is very expressive. Compared to what? C? That'd be true but rust is really complex and verbose which takes away its expressive powers. Just compare Rust code to Scala/Haskell/OCaml/Elm code and you'll see. > The main benefits of functional programming languages is contained with Rust's Iterator trait... Then you should look up for modern FP languages because iterators and similars aren't a part of modern FP languages. Also, you should take a look at the following paper to understand the difference between the types of polymorphisms: http://lucacardelli.name/papers/onunderstanding.a4.pdf http://lucacardelli.name/papers/onunderstanding.a4.pdf
deleted 10y ago
[deleted]
geofft 10y ago
I haven't developed this thesis fully, but I've been thinking that Rust's model is a better version of functional programming, and we lack a good term for it (since it's obviously not a pure functional language). The point of functional programming is to avoid shared mutable state by eliminating all side effects and using a rich type system that's hopefully easy for the programmer to use. Rust avoids unsafe shared mutable state, without requiring the avoidance of all side effects, and by using an even richer static-analysis system that tracks exactly what side effects are safe. Of course, there are a lot of useful things a pure functional programming language gets you, like Haskell's implicit IO scheduling and threading, that Rust doesn't. But for many use cases where functional programming languages are great, they're great for specific reasons that Rust is also great at.
- vvanders 10y ago
  I've had similar thoughts. Rust does a really good job of asking, are you really sure you want that shared mutable state? It's possible to break out but I've found the friction involved has guided me towards better solutions.
- Gankro 10y ago
  It's worth noting that Haskell has "shared xor mutable" via the ST Monad. It effectively providing mutable memory cells that aren't allowed to "escape" a scope in much the same way as `&mut`. Also having actual purity knowledge (something Rust punted on before 1.0) can sometimes be useful. Although honestly 99% of the time it's only for the benefit of the compiler, which isn't a big deal if you have the tools to write code that's efficient from the get-go. e.g. list fusion is enabled by purity, but is largely uninteresting in Rust because lazy iterator chaining already orders operations and avoids intermediate lists just like list fusion.
- Manishearth 10y ago
  A common point I've seen is that "Functional programming sees the aliasing vs mutability issue and declares that the solution is to avoid mutability altogether. Rust goes in a different direction, saying that only aliasing XOR mutability is allowed". It's solving the same problems, and the solution ends up having many similarities with functional programming.
stymaar 10y ago
Can you elaborate more what makes you think Rust isn't an expressive language ? And what feature your «functional programming language with low-cost abstractions» has that your miss with Rust ? In my experience Rust is really close to OCaml in term of expressiveness. I don't know what feature Scala or F# have that Rust doesn't. The only major thing I can think about is Higher Kinded Type in Haskell. They are indeed cool and there is work underway to add HKT to Rust (but nobody is sure yet if it's possible though).
- thinkpad20 10y ago
  I don't know a great deal about scala or f#, but I know scala has higher kinded types as well as implicit function arguments which are things that rust does not have. OCaml had parameterizable modules and functors, tail call optimization, and presumably other important features. I'm much more familiar with Haskell, which definitely has a lot of things that rust does not, not just higher kinded types but sophisticated type level programming, type families, functional dependencies, existential types, etc etc etc. Additionally it has lazy evaluation, a very sophisticated green threading system, software transactional memory, etc. Not to mention of course the purity. Haskell has a bunch that rust does not -- of course the reverse is true as well, but it's worth mentioning. At the end of the day, though, rust is meant to address use cases that no mainstream functional language does, and it is very successful at it, while also having a ton of really cool features which makes it very exciting for FP enthusiasts.
  - stymaar 10y ago
    Thanks !
- idobai 10y ago
  Why would be rust an expressive language if it's really verbose, complex, hard to read and its typesystem is pretty much just a struct, an enumeration and a pseudo-typeclass? Have you ever compared rust code to functional code? Who said it first that rust is "expressive" and if it is compared to what high-level language? Rust is just a small subset of C++ with compile-time smart pointers - or reference counters/trackers which is just another(but effective) aspect of garbage collection. I don't understand how can rust receive so much hype - besides the borrow-checker rust hasn't brought anything new to the table. Yeah, "zero-cost abstraction" and stuff but it isn't like a new goal in PLT.

by idobai 10y ago

mmstick 10y ago

Rust is very expressive. The main benefits of functional programming languages is contained with Rust's Iterator trait and the ad-hoc polymorphism that traits allow.

kibwen 10y ago
I don't know that traits in Rust are an example of ad-hoc polymorphism, since they're fully type-safe.
- burntsushi 10y ago
  I don't think that means it isn't ad hoc. Type classes in Haskell were originally introduced as a form of ad hoc polymorphism, for example: http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/ad-hoc-polymorphism.pdf http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/a... (One of Wadler's great papers btw, worth a read.) See also: https://en.wikipedia.org/wiki/Type_class https://en.wikipedia.org/wiki/Type_class Of course, Haskell type classes and Rust traits aren't the same. But they are quite similar!
- dllthomas 10y ago
  As I understand the term, "ad-hoc polymorphism" refers to dispatch based on types (as opposed to "parametric polymorphism", where one code path works for any type). Nothing to do with type-safety.
- mmstick 10y ago
  Here's an example: `Stdin` and `File` both implement the `Read` trait. Therefore, you can write a function that takes the traits that you want to use as input parameters. fn do_something_with<S: Read>(source: S) { // do something with input source } Then you can do the following: let stdout = io::stdout(); do_something_with(stdout.lock()); let file = File::open(path).unwrap(); do_something_with(file); You're free to narrow down/expand the types/methods that can be used with the function if you add more traits.
- tatterdemalion 10y ago
  "ad-hoc polymorphism" is an informal term; traits are sort of both ad hoc and parametric. I've sometimes imagined someone writing a paper about specialization and naming it "How to make parametric polymorphism less parametric" after Wadler's paper.
idobai 10y ago
> Rust is very expressive. Compared to what? C? That'd be true but rust is really complex and verbose which takes away its expressive powers. Just compare Rust code to Scala/Haskell/OCaml/Elm code and you'll see. > The main benefits of functional programming languages is contained with Rust's Iterator trait... Then you should look up for modern FP languages because iterators and similars aren't a part of modern FP languages. Also, you should take a look at the following paper to understand the difference between the types of polymorphisms: http://lucacardelli.name/papers/onunderstanding.a4.pdf http://lucacardelli.name/papers/onunderstanding.a4.pdf

deleted 10y ago

[deleted]

geofft 10y ago

I haven't developed this thesis fully, but I've been thinking that Rust's model is a better version of functional programming, and we lack a good term for it (since it's obviously not a pure functional language). The point of functional programming is to avoid shared mutable state by eliminating all side effects and using a rich type system that's hopefully easy for the programmer to use. Rust avoids unsafe shared mutable state, without requiring the avoidance of all side effects, and by using an even richer static-analysis system that tracks exactly what side effects are safe. Of course, there are a lot of useful things a pure functional programming language gets you, like Haskell's implicit IO scheduling and threading, that Rust doesn't. But for many use cases where functional programming languages are great, they're great for specific reasons that Rust is also great at.

vvanders 10y ago
I've had similar thoughts. Rust does a really good job of asking, are you really sure you want that shared mutable state? It's possible to break out but I've found the friction involved has guided me towards better solutions.
Gankro 10y ago
It's worth noting that Haskell has "shared xor mutable" via the ST Monad. It effectively providing mutable memory cells that aren't allowed to "escape" a scope in much the same way as `&mut`. Also having actual purity knowledge (something Rust punted on before 1.0) can sometimes be useful. Although honestly 99% of the time it's only for the benefit of the compiler, which isn't a big deal if you have the tools to write code that's efficient from the get-go. e.g. list fusion is enabled by purity, but is largely uninteresting in Rust because lazy iterator chaining already orders operations and avoids intermediate lists just like list fusion.
Manishearth 10y ago
A common point I've seen is that "Functional programming sees the aliasing vs mutability issue and declares that the solution is to avoid mutability altogether. Rust goes in a different direction, saying that only aliasing XOR mutability is allowed". It's solving the same problems, and the solution ends up having many similarities with functional programming.

stymaar 10y ago

Can you elaborate more what makes you think Rust isn't an expressive language ? And what feature your «functional programming language with low-cost abstractions» has that your miss with Rust ? In my experience Rust is really close to OCaml in term of expressiveness. I don't know what feature Scala or F# have that Rust doesn't. The only major thing I can think about is Higher Kinded Type in Haskell. They are indeed cool and there is work underway to add HKT to Rust (but nobody is sure yet if it's possible though).

thinkpad20 10y ago
I don't know a great deal about scala or f#, but I know scala has higher kinded types as well as implicit function arguments which are things that rust does not have. OCaml had parameterizable modules and functors, tail call optimization, and presumably other important features. I'm much more familiar with Haskell, which definitely has a lot of things that rust does not, not just higher kinded types but sophisticated type level programming, type families, functional dependencies, existential types, etc etc etc. Additionally it has lazy evaluation, a very sophisticated green threading system, software transactional memory, etc. Not to mention of course the purity. Haskell has a bunch that rust does not -- of course the reverse is true as well, but it's worth mentioning. At the end of the day, though, rust is meant to address use cases that no mainstream functional language does, and it is very successful at it, while also having a ton of really cool features which makes it very exciting for FP enthusiasts.
- stymaar 10y ago
  Thanks !
idobai 10y ago
Why would be rust an expressive language if it's really verbose, complex, hard to read and its typesystem is pretty much just a struct, an enumeration and a pseudo-typeclass? Have you ever compared rust code to functional code? Who said it first that rust is "expressive" and if it is compared to what high-level language? Rust is just a small subset of C++ with compile-time smart pointers - or reference counters/trackers which is just another(but effective) aspect of garbage collection. I don't understand how can rust receive so much hype - besides the borrow-checker rust hasn't brought anything new to the table. Yeah, "zero-cost abstraction" and stuff but it isn't like a new goal in PLT.