Hacker News new | ask | show | jobs
by tgv 1220 days ago
IMO, that's too superficial to compare them. So what if both have a bunch of similar looking constructs? Rust is imperative, and sequential, and nearly everything is mutable, hence the borrow checker. That makes programming in Rust rather different.
3 comments

Haskell controls mutable data by pervasive immutability.

Rust controls mutable data by the borrow checker system: allow sharing OR mutation but not both at the same time.

I get what GP is implying. The way you program (and think) is entirely different if you are working with immutable data structures and functions versus safe mutability.
Rust is immutable by default. You have to deliberately opt in for mutability. When you don't opt in to mutability the programming styles are very similar at a basic level.

First the type system is very similar with the capability of building sum and product types with recursive values. Second pattern matching over sum types is also very very similar.

Rust is like the bastard child of C++ and haskell.

Rust's new claim is now that references isn't immutable, it's shared by default. There is no concept of immutable data in rust. All data is mutable in various ways and that is a product of the binding not the data, from the cell interior mutability eupphamisn to shadowing in the same frame: (`let x = 2; let x += y;` is valid even though x isn't defined as mutable. The mental gymnastics a rust parishioner has to go thrown to shout down other languages while theirs fills with the same concepts is growing by the hour.
You can build "product types with recursive values" in any language that remotely descends from C or Algol. Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar.

> When you don't opt in to mutability

Rust's whole shtick is safe mutability.

>You can build "product types with recursive values" in any language that remotely descends from C or Algol.

You cut off the part where I said sum AND product types. Variant and union are post C++11 and not traditionally part of Algol style languages. Even nowadays the only time I see variant is from some haskell engineer stuck on a C++ job.

>Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar.

No pattern matching is a safety feature. Most of rust code should be using pattern matching as much as possible. In fact there's a language called Elm that achieves a claim for code that has ZERO runtime exceptions via the pattern matching feature. See: https://elm-lang.org/

Don't believe me? You know about programmings biggest mistake right? Null? Well C++ sort of got rid of it by discouraging it's use but even with optionals the issue is still there because optionals can still crash your program.

With rust, optionals never crash unless you deliberately ask it to via unwrap. If you use pattern matching exclusively to unroll optionals a crash is virtually impossible. Try it, and try to guess how pattern matching prevents optionals from crashing your program in rust, while in C++ the lack of pattern matching forces empty optionals to crash when you try to access it.

>Rust's whole shtick is safe mutability.

Yes, but at the same time it's opt in. Algol languages are by default mutable and you have to opt in for immutability via keywords like const. Rust offers extended safety via a single usage mutable borrow ans single usage mutable ownership but this is opt in. You should avoid using the keyword mut as much as possible.

In most Haskell codebases most code is written imperatively and executes sequentially.

It is very rare that anyone is actually using the truly advanced techniques like knot tying or TARDIS monads which are truly impossible in other languages.