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

71–80 of 189 posts

Re: Rust vs. Haskell

#71

Post by burntsushi »

marcosdumay wrote: post #57
zozbot234 wrote: post #37

Earlier quoted context omitted.

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…

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 course not. But I think your comment is swinging way too far in the opposite direction.

Re: Rust vs. Haskell

#72

Post by jeremyjh »

IshKebab wrote: post #50
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 :)

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.

Traits are definitely inspired by Haskell typeclasses (according to Graydon), but you are right that many other similarities are also shared with ML languages.

Re: Rust vs. Haskell

#73

Post by sshine »

cosmic_quanta wrote: post #68
surement wrote: post #64

Earlier quoted context omitted.

> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

You need to use the IO monad to get anything working, true. Monad transformers? Not at all. I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.

You don’t even really need to understand monad transformers in general to use just the ‘ReaderT IO’ pattern, and if you want to go crazier, free monads are both easier to understand, and more flexible.

Re: Rust vs. Haskell

#74

Post by ghostwriter »

jeremyjh wrote: post #70
cosmic_quanta wrote: post #68

Earlier quoted context omitted.

You need to use the IO monad to get anything working, true. Monad transformers? Not at all. I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.

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?

Re: Rust vs. Haskell

#75

Post by ColonelPhantom »

sbergot wrote: post #39
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.

In-place maybe not, but what language would be more suitable for graph based algorithms? Of course it depends on how you represent the graph, but writing something like breadth-first search is quite nice and easy to implement in Haskell, in my experience.

Re: Rust vs. Haskell

#76

Post by weavie »

jeremyjh wrote: post #70
cosmic_quanta wrote: post #68

Earlier quoted context omitted.

You need to use the IO monad to get anything working, true. Monad transformers? Not at all. I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.

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.

I would say using them is beginner->intermediate. Writing them is intermediate->advanced.

Re: Rust vs. Haskell

#77

Post by zozbot234 »

amelius wrote: post #56
zozbot234 wrote: post #37

Earlier quoted context omitted.

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…

> The borrow checker just makes sure that a closure never outlives its captures or any of its references. The point is that the borrow checker forces you to program in a fundamentally different style than idiomatic Haskell.

You are not forced into any design choice. You can use explicit reference counting to enable closure captures to add to object lifetime, or even a lightweight tracing GC implementation (such as the recently developed Samsara https://redvice.org/2023/samsara-garbage-collector/ ) to collect cycles as Haskell does. Of course, Rust makes the performance tradeoffs involved quite clear, even though the implementations it can use are quite possibly leaner than Haskell's.

Re: Rust vs. Haskell

#78

Post by anon291 »

surement wrote: post #64
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…

> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

You don't need to know that to write haskell

Effect systems and monad transformers are advanced topics. They're possible to use in my language yet most people do not and can still write software.

Certainly no need for them in Haskell to be successful. You can just program at the lower levels of abstraction common in other languages.

The only difference is that Haskell's community tends to emphasize abstraction

Re: Rust vs. Haskell

#79

Post by cosmic_quanta »

weavie wrote: post #76
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.

I would say using them is beginner->intermediate. Writing them is intermediate->advanced.

That's a good distinction

Re: Rust vs. Haskell

#80

Post by jeremyjh »

When I first learned Rust I'd been writing Haskell in serious side projects for four years, and had used C++ at work as well as a game project and was quite familiar with it (I'm not sure C++ is ever comfortable). Practically every feature in Rust other than the borrow checker was thus already known to me, and I still found Rust a quite significant learning curve, though to be fair I probably also learned about some things in C++ that looked safe but weren't.
Post reply on HN