Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust vs. Haskell

serokell.io

Post reply on HN
Print view View original

31–40 of 189 posts

Re: Rust vs. Haskell

#31

Post by masklinn »

sshine wrote: post #3

Great article. Rust struct and Haskell records work pretty much the same way, too: // Rust Item { name, price } Item { name: name, price: price } match item { Item { name, .. } => todo!(), } corresponding to -- Haskell Item { item, price } Item { item = item, price = price } case item of Item { name, .. } -> undefined Haskell has some opt-in flexibility wrt. packing and unpacking of field names [1]. [1]: https://ghc.…

FWIW if you’re just “unpacking” a structure `match` / `case` is unnecessary syntactic overhead, you can just use a regular let:

    // rust
    let Item { name, .. } = item;

    -- haskell
    let Item { name } = item in …
(Note: the haskell version requires NamedFieldPuns, or RecordWildCards for something like Rust’s version)

Re: Rust vs. Haskell

#32

Post by naasking »

sshine wrote: post #3

Great article. Rust struct and Haskell records work pretty much the same way, too: // Rust Item { name, price } Item { name: name, price: price } match item { Item { name, .. } => todo!(), } corresponding to -- Haskell Item { item, price } Item { item = item, price = price } case item of Item { name, .. } -> undefined Haskell has some opt-in flexibility wrt. packing and unpacking of field names [1]. [1]: https://ghc.…

There's one important difference: aren't Rust structs unboxed by default, where in Haskell they are boxed by default?

Re: Rust vs. Haskell

#33

Post by Y_Y »

qwertox wrote: post #22

About Haskell's function type annotations: "But it usually results in a warning, and adding a type signature is a good practice." I prefer Rust's way of doing this. When you're a beginner it ensures that you're passing and returning the proper type to and from the function, you kind of have the function as a guard which ensures that you're using the correct types.

I prefer to have a choice. You could have a compiler that doesn't run it you haven't eaten a balanced breakfast either. Haskell's type system is designed around type inference (of the Hindley-Milner kind), if it can infer the type I'd like to have the option to let it do so.

It's certainly good practise to write out your types, and often your editor can do it for you, but there are tons of little places where it's a waste.

Re: Rust vs. Haskell

#34

Post by masklinn »

Agingcoder wrote: post #29
lvass wrote: post #24

Can someone explain why/whether a language like Rust requires mutability? Wouldn't it be better if we could just have the compiler guarantee that functions marked as such are doing TCO, so algorithms would look better and had the full benefit of persistent data structures?

Maybe because otherwise you need a 'sufficiently smart compiler' which will be able to extract the right amount of performance from the underlying hardware which is mutable. Also I don't know if you can implement persistent data structures without a gc and with the rust typesystem. Maybe because it's designed to replace existing, familiar imperative and mutable languages.

> Also I don't know if you can implement persistent data structures without a gc and with the rust typesystem.

Well you can use Rc/Arc (that’s what Bodil’s imrs does for instance), but essentially yes, by design and purpose a persistent data structure has confused ownership, and thus requires a separate layer handling memory reclamation.

Re: Rust vs. Haskell

#35

Post by bryanlarsen »

ghostwriter wrote: post #27
qwertox wrote: post #22

About Haskell's function type annotations: "But it usually results in a warning, and adding a type signature is a good practice." I prefer Rust's way of doing this. When you're a beginner it ensures that you're passing and returning the proper type to and from the function, you kind of have the function as a guard which ensures that you're using the correct types.

> it ensures that you're passing and returning the proper type to and from the function You don't need it for all function declarations though, there are many trivial cases where type signatures don't add value. Consider that you probably would prefer most of the variables within a function to be inferred for you by the compiler. A similar thing could be said about the most of the functions within a given module. Imp…

pub functions: should be explicit

module functions: if I chose, I'd let them be derived, but I'm relatively indifferent

inner functions: should be allowed to be derived, IMO. They're very infrequently used so this choice doesn't have much impact.

Re: Rust vs. Haskell

#36

Post by tgv »

thedataangel wrote: post #9
armchairhacker wrote: post #6

This article paints Rust and Haskell as very similar languages, but when I saw the title I was thinking about how they are fundamentally different. Rust is technical and exposes/requires you to understand the reality of computation, while Haskell hides it away and lets you program in a system based on lambda-calculus (you don't even have strict order of evaluation!) Interesting to see that they are very similar regar…

Quite a few of Rust's features were borrowed from or inspired by ones in Haskell - albeit often modified to be more suitable for systems programming (and systems programmers!). Most Haskellers I know are quite fond of Rust :)

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.

Re: Rust vs. Haskell

#37

Post by zozbot234 »

amelius wrote: post #21
armchairhacker wrote: post #6

This article paints Rust and Haskell as very similar languages, but when I saw the title I was thinking about how they are fundamentally different. Rust is technical and exposes/requires you to understand the reality of computation, while Haskell hides it away and lets you program in a system based on lambda-calculus (you don't even have strict order of evaluation!) Interesting to see that they are very similar regar…

I think painting Rust and Haskell as similar languages is very misleading. Haskell has a garbage collector for a reason. You can't program naturally with closures unless you have a garbage collector, because closures introduce cyclic references. Also, Haskell has a type inference system that allows e.g. the IO monad to work seamlessly with the rest of the language. EDIT: and laziness of course.

Rust has closures and does not use a GC. The borrow checker just makes sure that a closure never outlives its captures or any of its references. The most prominent difference between Rust and Haskell is that Haskell uses lazy evaluation throughout; it's the language's unique selling point. Rust doesn't even have generators in the stable variety of the language yet, although they are internally used to implement async/await.

Re: Rust vs. Haskell

#38

Post by pjmlp »

amelius wrote: post #21
armchairhacker wrote: post #6

This article paints Rust and Haskell as very similar languages, but when I saw the title I was thinking about how they are fundamentally different. Rust is technical and exposes/requires you to understand the reality of computation, while Haskell hides it away and lets you program in a system based on lambda-calculus (you don't even have strict order of evaluation!) Interesting to see that they are very similar regar…

I think painting Rust and Haskell as similar languages is very misleading. Haskell has a garbage collector for a reason. You can't program naturally with closures unless you have a garbage collector, because closures introduce cyclic references. Also, Haskell has a type inference system that allows e.g. the IO monad to work seamlessly with the rest of the language. EDIT: and laziness of course.

Also Haskell is getting linear types, which gets us the best of both worlds, GC productivity and low level performance when needed.

Re: Rust vs. Haskell

#39

Post by sbergot »

lvass wrote: post #24

Can someone explain why/whether a language like Rust requires mutability? Wouldn't it be better if we could just have the compiler guarantee that functions marked as such are doing TCO, so algorithms would look better and had the full benefit of persistent data structures?

The price for immutability is pretty high. Haskell garbage collection has a lot of work to do.

When you say 'algorithms would look better' this is pretty subjective. Graph based algorithms or inplace algorithms doesn't look too good in haskell.

Post reply on HN