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

41–50 of 189 posts

Re: Rust vs. Haskell

#41

Post by ghkbrew »

naasking wrote: post #32
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?

This is true. Though I believe GHC is pretty aggressive about unboxing (when posible), but don't quote me on that.

Another possible gotcha is that by default Haskell records introduce a named accessor function into the surrounding scope. So defining two records with a `name` field next to each other is an error

Re: Rust vs. Haskell

#42

Post by ianpurton »

> As a result, both languages have steep learning curves compared with other languages.

Well yes and no. In a way the features such as immutability and algebraic data types are things you should know about as a software developer even if your current language means you can't use them at the moment.

My 16 year old son has learned Rust coming from a python at school background and is now writing small games in the bevy game engine.

Re: Rust vs. Haskell

#43

Post by kzrdude »

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.

You should look at what you can do with the Rust type inference too, it's not too far away from Haskell, at least not superficially. For example using the return type to deduce type parameters for a method like let samples: Vec = iterator.collect();

Re: Rust vs. Haskell

#44

Post by kzrdude »

tgv wrote: post #36
thedataangel wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Rust vs. Haskell

#45

Post by rom-antics »

masklinn wrote: post #26
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 significa…

"Worthless" is a bit strong. The Rust devs want to add TCO/TCE, but there are still problems left to solve. The "become" keyword is already reserved in anticipation of guaranteed tail calls being added.

https://github.com/rust-lang/rfcs/issues/2691

Re: Rust vs. Haskell

#46

Post by sbergot »

hgsgm wrote: post #17
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…

It's both solvable and easy to accidentally have blowups by accident.

yeah sadly this summarize my haskell experience. I would hate to do code reviews in haskell.

Re: Rust vs. Haskell

#47

Post by satvikpendem »

Surprised to see no mention of higher kinded types. Rust has generic associated types but they're not exactly the same and are more limited in their functionality than true HKTs.

Re: Rust vs. Haskell

#48

Post by ilovecaching »

As a systems programmer any mention of the word Haskell next to the word Rust sends shivers down my spine. Haskell is the king of yak shaving abstractions and is almost the polar opposite in all the ways that made C the most practically successful language on the earth.

I do not want abstractions where they aren't needed. I want control, simplicity, a clear correspondence between what I'm writing and what logical assembly I'll be generating (logical, not physical). Most of all I want my code to be stupidly clear to the next person reading it. Systems programming isn't like writing a Java app, the domain is complicated enough that there's no room for abstraction astronauts to create problems where there are none.

I am still very wary of Rust. I have used it and will continue to use it, but it still teeters on being too complicated to be useful in the same way as C.

Re: Rust vs. Haskell

#49

Post by FpUser »

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?"

Why not? Why this "there can only be one" mentality?

Re: Rust vs. Haskell

#50

Post by IshKebab »

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

I think Rust's features were actually inspired by OCaml rather than Haskell. Rust was originally written in OCaml, and OCaml feels a lot more similar to Rust than Haskell does.

Of course Haskell is heavily influenced by ML so it also has a lot of the same features.

Post reply on HN