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

171–180 of 189 posts

Re: Rust vs. Haskell

#171

Post by tgv »

kilgnad wrote: post #51
tgv wrote: post #36

Earlier quoted context omitted.

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.

Rust is immutable by default. You have to deliberately opt in for mutability. When you don't opt in to mutability the programming styles are very similar at a basic level. First the type system is very similar with the capability of building sum and product types with recursive values. Second pattern matching over sum types is also very very similar. Rust is like the bastard child of C++ and haskell.

You can build "product types with recursive values" in any language that remotely descends from C or Algol. Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar.

> When you don't opt in to mutability

Rust's whole shtick is safe mutability.

Re: Rust vs. Haskell

#172

Post by martinflack »

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…

I always imagined a mountain climb. So steep learning curve would mean daunting, high effort, high "drag" (gravity), but if you undertake it and push hard, you do, in fact, gain tons of utility (rather than proficiency per se) in a short amount of time.

Re: Rust vs. Haskell

#173

Post by 29athrowaway »

Martinsos wrote: post #55
29athrowaway wrote: post #40

"What do you use Haskell for?" Most important question about Haskell

I know it is common to think that Haskell is used only in academia and side/weird-projects, but there is a decent amount of companies using Haskell - e.g. we use Haskell in production for developing a DSL / web framework for building web apps ( https://github.com/wasp-lang/wasp )! I participated teaching students Haskell on my alma mater this year and "what can Haskell be used for" was a common question, with genuine…

What concrete, user facing, revenue generating product have you built using Wasp?

How is Wasp more convenient than other frameworks? How do I hire people that know it or can train themselves to use it?

Re: Rust vs. Haskell

#174

Post by majewsky »

ghostwriter wrote: post #170
kzrdude wrote: post #115

Earlier quoted context omitted.

Is it the most trivial? C++ doesn't support it, and it has type inference using `auto`. Note that in my example the type information flows from the variable to picking which generic method that is called, which is reversed information flow of what I would call the most trivial case - when the variable gets its type from the method that was called. (This is trivial: let x = 1i32;)

> For example using the return type to deduce type parameters for a method like let samples: Vec = iterator.collect(); > C++ doesn't support it How exactly is it different? #include #include int main() { std::vector v1 = {1,2,3}; auto it = v1.begin(); std::vector v2 (it + 1, it + 2); for (auto i: v2) { std::cout

C++ auto can only do forward type-inference, i.e. the RHS must have a definitive type and this type is what `it` will end up having in your example. In the Rust example from above:

  let samples: Vec = iterator.collect();
The RHS by itself has the type "B for any B that implements FromIterator where I is the Item type of the given iterator". This cannot be assigned directly to a variable without any type hint (like with C++ auto) because it's an entire class of types and not a specific type. However, in the provided example, the Rust type checker can use the provided clue to narrow this down to an exact type, Vec, without requiring an explicit statement of the type I (instead the underscore serves as a placeholder).

Re: Rust vs. Haskell

#175

Post by LegionMammal978 »

bryanlarsen wrote: post #147
nicoburns wrote: post #145

Earlier quoted context omitted.

Closures don't have to capture variables. If they don't then they're equivalent to functions.

That's what I thought too, but I fixed some compiler errors by turning a closure into an inner function. Probably a PBKAC, but...

Perhaps it's due to the fact that you can't really have type-generic closures in Rust: once the compiler has inferred one type, the closure cannot be used with another type. In contrast, inner functions can have any number of additional type parameters.

Re: Rust vs. Haskell

#176

Post by SkyMarshal »

mananaysiempre wrote: post #153
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 am (or used to be) a Haskeller, and I just can’t get over how spectacularly ugly Rust’s syntax looks compared to Haskell or SML and finally force myself to learn it. Call me shallow, but it’s true.

I love how Haskell splits the type definition and function definition into two lines. It’s so readable that way. Also enables outlining your program first with just type definitions, and then going back and filling in the function definitions later.

Re: Rust vs. Haskell

#177

Post by [deleted] »

wyager wrote: post #148
IshKebab wrote: post #50

Earlier quoted context omitted.

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.

> I think Rust's features were actually inspired by OCaml rather than Haskell The old alpha/beta rust docs specifically referenced Haskell all over the place, and I don't recall them mentioning OCaml. > OCaml feels a lot more similar to Rust than Haskell does I disagree very strongly with this. OCaml doesn't even have type classes/traits! Rust lacks polymorphic variants, functorial modules, etc. It's really nothing l…

[deleted]

Re: Rust vs. Haskell

#178

Post by kilgnad »

tgv wrote: post #171
kilgnad wrote: post #51

Earlier quoted context omitted.

Rust is immutable by default. You have to deliberately opt in for mutability. When you don't opt in to mutability the programming styles are very similar at a basic level. First the type system is very similar with the capability of building sum and product types with recursive values. Second pattern matching over sum types is also very very similar. Rust is like the bastard child of C++ and haskell.

You can build "product types with recursive values" in any language that remotely descends from C or Algol. Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar. > When you don't opt in to mutability Rust's whole shtick is safe mutability.

>You can build "product types with recursive values" in any language that remotely descends from C or Algol.

You cut off the part where I said sum AND product types. Variant and union are post C++11 and not traditionally part of Algol style languages. Even nowadays the only time I see variant is from some haskell engineer stuck on a C++ job.

>Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar.

No pattern matching is a safety feature. Most of rust code should be using pattern matching as much as possible. In fact there's a language called Elm that achieves a claim for code that has ZERO runtime exceptions via the pattern matching feature. See: https://elm-lang.org/

Don't believe me? You know about programmings biggest mistake right? Null? Well C++ sort of got rid of it by discouraging it's use but even with optionals the issue is still there because optionals can still crash your program.

With rust, optionals never crash unless you deliberately ask it to via unwrap. If you use pattern matching exclusively to unroll optionals a crash is virtually impossible. Try it, and try to guess how pattern matching prevents optionals from crashing your program in rust, while in C++ the lack of pattern matching forces empty optionals to crash when you try to access it.

>Rust's whole shtick is safe mutability.

Yes, but at the same time it's opt in. Algol languages are by default mutable and you have to opt in for immutability via keywords like const. Rust offers extended safety via a single usage mutable borrow ans single usage mutable ownership but this is opt in. You should avoid using the keyword mut as much as possible.

Re: Rust vs. Haskell

#179

Post by ghostwriter »

majewsky wrote: post #174
ghostwriter wrote: post #170

Earlier quoted context omitted.

> For example using the return type to deduce type parameters for a method like let samples: Vec = iterator.collect(); > C++ doesn't support it How exactly is it different? #include #include int main() { std::vector v1 = {1,2,3}; auto it = v1.begin(); std::vector v2 (it + 1, it + 2); for (auto i: v2) { std::cout

C++ auto can only do forward type-inference, i.e. the RHS must have a definitive type and this type is what `it` will end up having in your example. In the Rust example from above: let samples: Vec = iterator.collect(); The RHS by itself has the type "B for any B that implements FromIterator where I is the Item type of the given iterator". This cannot be assigned directly to a variable without any type hint (like wit…

Sorry, I still don't get how it's different from C++, and my point wasn't about `auto` but rather about `std::vector v2`:

    std::vector v2 (v1.begin() + 1, v1.begin() + 2);
> However, in the provided example, the Rust type checker can use the provided clue to narrow this down to an exact type

The Rust example is incomplete and its RHS by the time it gets to `.collect()` within the context of `iterator` has to be bound to a particular type of the context via `impl Iterator for `. This is pretty much the same thing as template argument deduction for class templates in C++17 [1][2], and in C++20 it got extended to generic concepts and constraints [3]:

    #include 
    #include 
    #include 
    #include 

    template  
    requires std::integral || std::floating_point
    constexpr auto avg(std::vector const &v) {
        auto sum = std::accumulate(v.begin(), v.end(), 0.0);        
        return sum / v.size();
    }

    int main() {
        std::vector v { 1, 2, 3 };
        std::cout
Note that nowhere in the snippet do I specify the type explicitly except for the container of type vector.

[1] https://en.cppreference.com/w/cpp/language/template_argument...

[2] https://devblogs.microsoft.com/cppblog/how-to-use-class-temp...

[3] https://www.cppstories.com/2021/concepts-intro/

Re: Rust vs. Haskell

#180

Post by eggy »

mananaysiempre wrote: post #153
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 am (or used to be) a Haskeller, and I just can’t get over how spectacularly ugly Rust’s syntax looks compared to Haskell or SML and finally force myself to learn it. Call me shallow, but it’s true.

No, you're not shallow. Rust's syntax has put me off a lot. I was looking to learn an alternate Erlang VM language and liked Gleam, which originally had a Haskell/ML syntax, but they've decided it's a popularity contest, so they chose to go to an Algol, C, Rust looking syntax. Shame. I was learning LFE (Lisp Flavoured Erlang), buecause Lisp, but then Elixir took off because all of the Ruby programmers took to it (and it's got a lot of other stuff going for it, but it's closer to Ruby than LFE!).
Post reply on HN