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

131–140 of 189 posts

Re: Rust vs. Haskell

#131

Post by dgb23 »

kzrdude wrote: post #44
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.

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.

I get what GP is implying. The way you program (and think) is entirely different if you are working with immutable data structures and functions versus safe mutability.

Re: Rust vs. Haskell

#132

Post by rebeccaskinner »

OJFord wrote: post #113
Martinsos wrote: post #55

Earlier quoted context omitted.

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…

> The biggest factor for deciding if Haskell is a good fit for the problem is probably ecosystem support And hiring right, or being prepared to train/let new hires climb up a steeper learning curve than hiring someone with Python experience for a Ruby app say. Rust has reached that critical mass I think, got past the chicken/egg issue of experienced people to hire & companies interested in hiring them (to work on a r…

Anecdotally, hiring Haskell developers seems far easier than you’d expect. There are a lot more people out there who want to use Haskell than there are Haskell jobs. Having some training is good- you don’t want to lose out on talented people because they haven’t used Haskell before, but it’s not like everything you know goes out the window when you learn Haskell either. With some help most people should be pretty proficient in a couple of months, and you can have people learn the language in parallel with learning the codebase and business domain, so you aren’t really losing that much time in practice.

Re: Rust vs. Haskell

#133

Post by zozbot234 »

Hirrolot wrote: post #123
zozbot234 wrote: post #114

Earlier quoted context omitted.

> currently it's not quite clear what's the best way to integrate dependent types with systems programming. Dependent types dispense with the phase separation between compile-time and run-time code, which is inherent to system languages. So you can easily have dependent types in a systems language as part of compile-time evaluation , but not really as a general feature. It would work quite similar to the "program ext…

Yeah, the main problem with dependent types being used in low-level programming is that they're now able to perform arbitrary computation. That's why I think castrated dependent types might do the trick, since if you accept only integer indices as parameters to types, then you can boil down type checking to constraint solving without actually performing arbitrary computation.

Strictly speaking, dependent types cannot really perform arbitrary computation (as usually implemented) because general recursion is restricted. And most real-world programs, especially systems programs, need general recursion. So, for all the supposed generality of dependent types, you end up with two quite separate feature sets for compile-time and run-time execution that can only share a comparatively trivial common subset.

Re: Rust vs. Haskell

#134

Post by pitaj »

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

That's not just closures, but a confluence of closures, async, and more.

Re: Rust vs. Haskell

#135

Post by Hirrolot »

phplovesong wrote: post #124

Would not a better comparison be Ocaml vs Rust? In the end Rust WAS written in OCaml, and is heavily influenced by it.

That would not be a comprehensive comparison, but:

- OCaml is definitely tailored for more "high-level" tasks, such as writing a programming language or a theorem prover (there are many of them in the OCaml world, and even Rust was initially written in OCaml, as you've mentioned). OCaml has a GC, which might be a problem under certain circumstances.

- Rust has a far better ecosystem despite being a younger language. You can just compare the number of packages on crates.io and OPAM.

- OCaml _sometimes_ has some more fancy type features, such as functors (modules parameterized by other modules), first-class modules, GADTs (Generalized Algebraic Data Types), algebraic effects, and the list could go on. It doesn't have type classes or an ownership system though.

- OCaml is more ML-like, while Rust quite often feels C-like. For example, you have automatically curried functions in OCaml and the omnipresent HM type inference.

- OCaml has a powerful optimizer called Flambda [1], which is designed to optimize FP-style programs.

Having written some code both in OCaml and Rust, I can say they are in a lot of aspects quite similar though. They both take a more practical POV on programming than Haskell, which affects language design quite evidently.

[1] https://v2.ocaml.org/manual/flambda.html

Re: Rust vs. Haskell

#136

Post by dgb23 »

qwertox wrote: post #22

About Haskell's function type annotations: "But it usually results in a warning, and adding a type signature is a good practice." I prefer Rust's way of doing this. When you're a beginner it ensures that you're passing and returning the proper type to and from the function, you kind of have the function as a guard which ensures that you're using the correct types.

Rust only half-asses this though. Lifetime annotations are part of the type of the function but can be elided if unambiguous. For beginners and generally people who read code that's confusing. I don't think there's anything to be gained by writing a few less characters and editors can easily add them as well.

Re: Rust vs. Haskell

#137

Post by SnowflakeOnIce »

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 understand your point and perhaps I'm in fierce agreement.

OTOH, things like parser combinators are much more ergonomic in Haskell than Rust.

Re: Rust vs. Haskell

#138

Post by Hirrolot »

zozbot234 wrote: post #133
Hirrolot wrote: post #123

Earlier quoted context omitted.

Yeah, the main problem with dependent types being used in low-level programming is that they're now able to perform arbitrary computation. That's why I think castrated dependent types might do the trick, since if you accept only integer indices as parameters to types, then you can boil down type checking to constraint solving without actually performing arbitrary computation.

Strictly speaking, dependent types cannot really perform arbitrary computation (as usually implemented) because general recursion is restricted. And most real-world programs, especially systems programs, need general recursion. So, for all the supposed generality of dependent types, you end up with two quite separate feature sets for compile-time and run-time execution that can only share a comparatively trivial comm…

You can have general recursion with dependent types though. Theorem provers prohibit it because otherwise it'd render the system logically inconsistent, which is far less severe in programming than in mathematics. But I agree that a great deal of expressivity of dependent types would be lost if they're applied to systems programming, which is somewhat unfortunate.

Re: Rust vs. Haskell

#139

Post by retrac »

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 see Rust as heavily influenced by ML, perhaps even descended from it loosely, just with C family syntax. This seems to be a commonly expressed view? Rust has everything ML has, pretty much. Rust's concept of ownership/RAII was first implemented in an experimental ML variant, one that didn't need garbage collection. (The first version of Rust was implemented in Ocaml, perhaps not coincidentally.) And of course, ML and Haskell are close cousins, if not siblings.
Post reply on HN