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

21–30 of 189 posts

Re: Rust vs. Haskell

#21

Post by amelius »

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.

Re: Rust vs. Haskell

#22

Post by qwertox »

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.

Re: Rust vs. Haskell

#23

Post by herbstein »

api wrote: post #11
rkangel wrote: post #10

Earlier quoted context omitted.

I don't know about Haskell particularly but the underlying implementation of data structures in pure languages is sometimes more complicated to enable this sort of thing. For example, the new updated copy of the map may refer to the "old" map for most of its data, thereby making it cheap to have both.

So copy-on-write basically?

Yes, but with granularity at the "node" level instead of being across the whole container. Imagine a linked list.

If you add prepend an element to an existing list, no copy is necessary. It's just a new head with the tail being the original list. That's an easy case.

If you add a node in the middle of the list you can still share the unchanged tail between the two slightly different prefix sequences.

Re: Rust vs. Haskell

#24

Post by lvass »

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?

Re: Rust vs. Haskell

#25

Post by rkangel »

api wrote: post #11
rkangel wrote: post #10

Earlier quoted context omitted.

I don't know about Haskell particularly but the underlying implementation of data structures in pure languages is sometimes more complicated to enable this sort of thing. For example, the new updated copy of the map may refer to the "old" map for most of its data, thereby making it cheap to have both.

So copy-on-write basically?

No, because you don't copy the whole structure. You create a new partial structure.

E.g. let's say you create a map with keys A and B. You then insert a new key C. In memory you might have two objects: One is the origi al map with A and B and the other has "Key C and a ref to the first map".

Re: Rust vs. Haskell

#26

Post by masklinn »

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?

> Can someone explain why Rust has mutability?

Because it’s target domain requires reliable efficiency.

> Wouldn't it be better if we could just have the compiler guarantee that functions marked as such

As such what?

> are doing TCO

TCO is worthless, and Rust does not have TCE, nor does it care about TCE.

> so algorithms would look better and had the full benefit of persistent data structures?

Rust does not significantly care for persistent data structures, there are crates which provide them, but not the standard library.

Rust is not a functional language.

Re: Rust vs. Haskell

#27

Post by ghostwriter »

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. Important interface methods can be defined explicitly though, for extra clarity and self-documenting purposes.

Re: Rust vs. Haskell

#28

Post by andrewflnr »

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?

Rust is designed for maximal performance, so it's designed to be close to machine language, where mutability is an unavoidable reality. That's pretty much the whole story.

Re: Rust vs. Haskell

#29

Post by Agingcoder »

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.

Re: Rust vs. Haskell

#30

Post by thedataangel »

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.

In "serious" Haskell code, almost all top-level definitions (i.e. functions) are given types - for exactly the reason you specify.
Post reply on HN