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

141–150 of 189 posts

Re: Rust vs. Haskell

#141

Post by burntsushi »

SnowflakeOnIce wrote: post #137
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 understand your point and perhaps I'm in fierce agreement. OTOH, things like parser combinators are much more ergonomic in Haskell than Rust.

Well yes... For many reasons. Including automatic currying and the fact that eta reductions work seamlessly in Haskell and less so in Rust.

Re: Rust vs. Haskell

#143

Post by Martinsos »

rebeccaskinner wrote: post #132
OJFord wrote: post #113

Earlier quoted context omitted.

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

I can confirm this! We had no problem getting a very decent number of applications for Haskell position, both from very experienced Haskell devs, and from junior Haskell devs, all very motivated.

As for getting somebody on-board -> we hired a couple senior / intermediate devs that had no or introductory knowledge of Haskell, and all of them so far got up to speed in a month or so, while not learning exclusively Haskell but also the rest of the codebase at the same time, so normal learning process in the new company. So I wouldn't say at all that learning Haskell for them was an issue, but I am certain that big factor here was that they are generally experienced in other languages. That said, we do keep our codebase pretty tidy and simple (no super crazy Haskell features).

Re: Rust vs. Haskell

#144

Post by YuukiRey »

anon291 wrote: post #78
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 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

I hear this opinion every so often but I just don't think it's really the case. Many libraries out there expect you to use Monad transformers. You might try to keep MTL out of your own application code, but you'll find that the rest of the ecosystem favors it. You can still use these libraries without MTL, but it's often not ergonomic and therefore not really an option.

Re: Rust vs. Haskell

#145

Post by nicoburns »

bryanlarsen wrote: post #93
nicoburns wrote: post #52

Earlier quoted context omitted.

You can use closures as functions with type inferred signatures

Closures capture variables so have significant differences compared to inner functions. Capture can affect lifetimes so the difference is significant in Rust.

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

Re: Rust vs. Haskell

#146

Post by IAmYourDensity »

blep_ wrote: post #104
yboris wrote: post #82

Earlier quoted context omitted.

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…

If essentially everyone uses it to mean one thing, that's what it means now. That's how definitions work.

Does that apply to “Hacker” in Hacker News?

Re: Rust vs. Haskell

#147

Post by bryanlarsen »

nicoburns wrote: post #145
bryanlarsen wrote: post #93

Earlier quoted context omitted.

Closures capture variables so have significant differences compared to inner functions. Capture can affect lifetimes so the difference is significant in Rust.

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

Re: Rust vs. Haskell

#148

Post by wyager »

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.

> 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 like idiomatic ocaml, whereas I think it's pretty reasonable to describe Rust as "what Haskell devs would make if they weren't allowed to heap allocate". Maybe they'd also add a few more gizmos to the type system :)

Re: Rust vs. Haskell

#149

Post by Hirrolot »

pitaj wrote: post #134
Hirrolot wrote: post #97

Earlier quoted context omitted.

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.

The example provided in the post -- yes. But I can basically demonstrate other language features that are not working with closures, such as generics -- you just can't have generic closures in the same way as you have generic functions, even in a synchronous code. With closures, you have a pretty limited scope of what you can do, considering the rest of the language, so I think it'd be pretty useless to consider closures as a separate mechanism that shouldn't interact with the rest of the language.

Re: Rust vs. Haskell

#150

Post by wyager »

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…

Rust is the closest thing to Haskell that I can run on a processor without an MMU.

There's a pareto frontier of "best available language for a given project", and I think Haskell dominates the portion of the pareto frontier where you don't have super tight physical/memory/real-time constraints, and Rust dominates the portion where you do. This is by virtue of their similarity.

Post reply on HN