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

1–10 of 189 posts

Re: Rust vs. Haskell

#3

Post by sshine »

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.gitlab.haskell.org/ghc/doc/users_guide/exts/reco...

Re: Rust vs. Haskell

#4

Post by Joker_vD » 

    let nums = take 10000000 naturals
    print $ (sum nums, length nums)
> Because the nums list is used for both sum and length computations, the compiler can’t discard list elements until it evaluates both.

Now that makes me wonder, if I write something like

    print $ (sum (take 10000000 naturals), length (take 10000000 naturals))
will it run in constant memory? I think it ought to, but are there mechanisms in GHC optimizer to prevent extraction of CSEs that would cause huge increases in memory consumption?

Re: Rust vs. Haskell

#5

Post by endgame »

Joker_vD wrote: post #4

let nums = take 10000000 naturals print $ (sum nums, length nums) > Because the nums list is used for both sum and length computations, the compiler can’t discard list elements until it evaluates both. Now that makes me wonder, if I write something like print $ (sum (take 10000000 naturals), length (take 10000000 naturals)) will it run in constant memory? I think it ought to, but are there mechanisms in GHC optimizer…

The solution to this is a package like https://hackage.haskell.org/package/foldl , which lets you fuse multiple traversals of a lazy list into a single pass and get the laziness right.

Re: Rust vs. Haskell

#6

Post by armchairhacker »

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 regardless.

Re: Rust vs. Haskell

#8

Post by vlovich123 »

> if we have a map and want to do some operation on a slightly modified map, we can have a value that keeps the old map but also works with the new map (without much performance cost).

What black magic is this? Is the article just glossing over the cost of a copy or does Haskell do something weird here to avoid the copy while retaining both versions?

Re: Rust vs. Haskell

#9

Post by thedataangel »

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 :)

Re: Rust vs. Haskell

#10

Post by rkangel »

vlovich123 wrote: post #8

> if we have a map and want to do some operation on a slightly modified map, we can have a value that keeps the old map but also works with the new map (without much performance cost). What black magic is this? Is the article just glossing over the cost of a copy or does Haskell do something weird here to avoid the copy while retaining both versions?

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.
Post reply on HN