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

81–90 of 189 posts

Re: Rust vs. Haskell

#81

Post by chongli »

burntsushi wrote: post #71
marcosdumay wrote: post #57

Earlier quoted context omitted.

There is nothing "natural" about working with Rust closures. If you want to take a losing fight against the borrow checker, they are the best way to do it. (Rust has your C-like run of the mill function references too. People should emphasize those more, because differently from closures, those work very well.)

Closures work very well in Rust and are a core aspect of the standard library. The 'Iterator' trait adapters, for example, make very heavy use of closures, as do the combinators on 'Option' and 'Result'. Closures are also how you spawn threads. They are absolutely ubiquitous and quite natural. In contrast, function pointers are very rarely used. Are they equivalently nice in every way to closures in Haskell? Of cours…

I think the word ‘natural’ in this context is too vague. If you’re coming to Rust from C++, sure, Rust’s closures feel quite natural. If, on the other hand, you’re coming to Rust from Haskell then they’ll feel wholly unnatural and confusing.

Re: Rust vs. Haskell

#82

Post by yboris »

ianpurton wrote: post #42

> 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…

steep learning curve usually means the opposite of what the author wants to say:

"The common expression "a steep learning curve" is a misnomer suggesting that an activity is difficult to learn and that expending much effort does not increase proficiency by much, although a learning curve with a steep start actually represents rapid progress."

https://en.wikipedia.org/wiki/Learning_curve

When writing, consider "challenging learning curve" instead (I'd love other suggestions too).

Re: Rust vs. Haskell

#83

Post by masklinn »

rom-antics wrote: post #45
masklinn wrote: post #26

Earlier quoted context omitted.

> 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

> "Worthless" is a bit strong.

No, TCO is worthless, it’s an unreliable optimisation.

Re: Rust vs. Haskell

#84

Post by jeremyjh »

ghostwriter wrote: post #74
jeremyjh wrote: post #70

Earlier quoted context omitted.

I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.

> Its not impossible to do serious work without them but I'm not sure its worth doing. How do you think the folks on Java and C# find their work worth doing on their end in that case?

Because they aren't using Haskell? Haskell more or less creates all the problems that transformers solve.

Re: Rust vs. Haskell

#85

Post by anon291 »

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…

They are extremely similar.

Rust just happens to heavily use linear types. Haskell let's you use both. If you write your Haskell program using linear types you get borrow checker semantics.

The main difference is mem management. However haskell could likely be written to be manually memory managed. There are manual men based ocaml implementations.

Haskell is not typically used for systems programming.

> you don't even have strict order of evaluation!)

People say this but I'm not sure people understand it. Haskell evaluation order is exotic but deterministic in all cases unless you introduce threads, which bring non determinism into any language including rust

Re: Rust vs. Haskell

#86

Post by weavie »

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.

Infix operators and currying give Haskell completely different ergonomics to Rust, even if you could largely do the same thing in both languages.

Re: Rust vs. Haskell

#87

Post by anon291 »

platz wrote: post #63
pjmlp wrote: post #38

Earlier quoted context omitted.

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

Every talk I've seen on Haskell linear types is that at best they can do some specific compuatations more efficiently (especially with arrays) but are not a good fit in Haskell to significantly elide GC.

> but are not a good fit in Haskell to significantly elide GC

That's because the entire haskell ecosystem would have to be rewritten which seems insurmountable.

Re: Rust vs. Haskell

#88

Post by anon291 »

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.

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.

Re: Rust vs. Haskell

#89

Post by burntsushi »

chongli wrote: post #81
burntsushi wrote: post #71

Earlier quoted context omitted.

Closures work very well in Rust and are a core aspect of the standard library. The 'Iterator' trait adapters, for example, make very heavy use of closures, as do the combinators on 'Option' and 'Result'. Closures are also how you spawn threads. They are absolutely ubiquitous and quite natural. In contrast, function pointers are very rarely used. Are they equivalently nice in every way to closures in Haskell? Of cours…

I think the word ‘natural’ in this context is too vague. If you’re coming to Rust from C++, sure, Rust’s closures feel quite natural. If, on the other hand, you’re coming to Rust from Haskell then they’ll feel wholly unnatural and confusing.

Sure it's vague. We're expressing opinions here. :-) But it's important to push back here. Closures are absolutely natural enough in Rust that a huge swath of very fundamental APIs in Rust rely on them. If they weren't natural in at least some sense, it would be absolutely bonkers to do that.

I came to Rust from Haskell (among other languages). I was a little confused by closures, but I attributed that to the fact that I started writing Rust before 1.0 when closures were far far far less convenient than they are today. (This is back when there were 'proc' closures.) Now I find them extremely natural.

Re: Rust vs. Haskell

#90

Post by creata »

yboris wrote: post #82
ianpurton wrote: post #42

> 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…

steep learning curve usually means the opposite of what the author wants to say: "The common expression "a steep learning curve" is a misnomer suggesting that an activity is difficult to learn and that expending much effort does not increase proficiency by much, although a learning curve with a steep start actually represents rapid progress." https://en.wikipedia.org/wiki/Learning_curve When writing, consider "challe…

Easy fix, put time on the y-axis.
Post reply on HN