Rust vs. Haskell

Post by Hirrolot » Tue, Feb 14, 2023, 3:02 PM UTC

satvikpendem wrote: post #47

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.

Post by ghostwriter » Tue, Feb 14, 2023, 3:09 PM UTC

jeremyjh wrote: post #99

ghostwriter wrote: post #95

Earlier quoted context omitted.

Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?

I'm not making any points about users of mainstream languages. They have no use for transformers. Using a lot of global IORefs is possible but relies on a trick using unsafePerformIO; its definitely not in the spirit of Haskell to work this way though it is sometimes needed.

Post by thomastjeffery » Tue, Feb 14, 2023, 3:12 PM UTC

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…

Post by burntsushi » Tue, Feb 14, 2023, 3:14 PM UTC

Hirrolot wrote: post #97

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…

Closures in Rust are fundamentally broken. See [1] for the discussion. [1] https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...

Post by burntsushi » Tue, Feb 14, 2023, 3:20 PM UTC

chongli wrote: post #102

burntsushi wrote: post #89

Earlier quoted context omitted.

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

Wait, they got rid of proc closures? Hahaha. Shows how long it’s been since I last looked at Rust. Okay, now they do look quite natural!

    fn adder(x: i32) -> impl Fn(i32) -> i32 {
        move |y| y + x
    }

    fn main() {
        let add2 = adder(2);
        assert_eq!(7, add2(5));
        assert_eq!(10, add2(8));
    }