Live data from Hacker News

Rust as a gateway drug to Haskell

xion.io

111–120 of 218 posts

Re: Rust as a gateway drug to Haskell

#111

Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

Haskell's laziness is an issue for you? Then how do strictness annotations (and/or module flags) not solve this problem? Haskell also has inline-C FFI support for "type safe" performance escape hatches (in the sense that you can manually bring C constructs into Haskell's type system): https://github.com/fpco/inline-c The only way that Haskell inescapably suffers from performance hits (that I'm aware of) is not in its…

> Then how do strictness annotations (and/or module flags) not solve this problem?

Strictness annotations (and associated pragmas) only change the strictness of constructors and functions defined in my modules. I still have to reason about laziness as I use almost anything from the Haskell ecosystem.

Re: Rust as a gateway drug to Haskell

#112

Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

While I've found that Haskell's laziness can often be worked around with appropriately-implemented memoization, it's an absolute PITA for anything that requires frequent hops into the IO monad (unsurprisingly). Historically, this has been a bottleneck for me that's prevented me from using Haskell in any major projects.

A Haskell port of a logging library I'd originally written in Python ended up being almost 2 orders of magnitude slower than CPython 3, and almost 3 orders of magnitude slower than PyPy3.

PyPy3 resulted in performance similar to a barely-optimized C port.

Re: Rust as a gateway drug to Haskell

#113
post #108
post #101

Earlier quoted context omitted.

I don't think anything is the unique selling point of laziness. Wikipedia[1] says "The benefits of lazy evaluation include: * The ability to define control flow (structures) as abstractions instead of primitives. * The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms. * Performance increases by avoiding needless calculations, and error cond…

"the first and second points are at least an order of magnitude more important than the third." No offense, but 'performance is not as important as...' is what basically all pro-FP devs say for years, still it seems that the rest of the world thinks exactly the opposite.

On the contrary, the rest of the world seems to think "the performance gains given by laziness" aren't worthwhile at all.

It's true that there are also performance costs associated with laziness, but those weren't under discussion.

Re: Rust as a gateway drug to Haskell

#114
post #18

Earlier quoted context omitted.

ocaml is a great language in its own right too; the only haskell features I find myself really missing are do notation and operator overloading.

F# does have operator overloading.

but F# doesn't have Ocaml's performance, which I believe was the point being made for ML over Haskell

I honestly don't know how F# compares to Haskell over performance

Re: Rust as a gateway drug to Haskell

#115
post #13

I wonder if Idris could some day take Haskell's place. It sports default eager evaluation. Seems like the tooling (package managers etc.) isn't quite there yet, though.

Is a difference in a default option really enough for a language to take the place of another? And if it's not just a change in a default option, but the removal of laziness, we lose something, which will make the choice less obvious.

I think it's more likely that, if dependent types prove really useful, Haskell will adopt these, and people will adapt their code, rather than port everything to a new language.

As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering.

Re: Rust as a gateway drug to Haskell

#116

Earlier quoted context omitted.

Haskell's laziness is an issue for you? Then how do strictness annotations (and/or module flags) not solve this problem? Haskell also has inline-C FFI support for "type safe" performance escape hatches (in the sense that you can manually bring C constructs into Haskell's type system): https://github.com/fpco/inline-c The only way that Haskell inescapably suffers from performance hits (that I'm aware of) is not in its…

> Then how do strictness annotations (and/or module flags) not solve this problem? Strictness annotations (and associated pragmas) only change the strictness of constructors and functions defined in my modules. I still have to reason about laziness as I use almost anything from the Haskell ecosystem.

Good point. I wonder if there are Strict versions of the Prelude that could help out?

Re: Rust as a gateway drug to Haskell

#117
post #72

Earlier quoted context omitted.

Although clearly presented to push some buttons, it isn't completely wrong. Am upvote hoping you don't get buried.

it isn't completely wrong It may get some of the facts right, but the tone is completely wrong. Cynicism is just a step or two away from nihilism. It's far, far easier to destroy than it is to create. The world needs more creators, not destroyers.

We need more people creating the right things, and more people destroying the wrong things and baggage that we've overburdened ourselves with.

Cynicism is a self-defense mechanism.

Re: Rust as a gateway drug to Haskell

#118
post #13

I wonder if Idris could some day take Haskell's place. It sports default eager evaluation. Seems like the tooling (package managers etc.) isn't quite there yet, though.

That place being the cool esoteric language that everybody fools around with on the weekends, but is almost never used seriously?

Re: Rust as a gateway drug to Haskell

#119
post #108
post #101

Earlier quoted context omitted.

I don't think anything is the unique selling point of laziness. Wikipedia[1] says "The benefits of lazy evaluation include: * The ability to define control flow (structures) as abstractions instead of primitives. * The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms. * Performance increases by avoiding needless calculations, and error cond…

"the first and second points are at least an order of magnitude more important than the third." No offense, but 'performance is not as important as...' is what basically all pro-FP devs say for years, still it seems that the rest of the world thinks exactly the opposite.

You've completely missed the point.

I make no claim about the importance of performance.

My claim is that the performance gains brought by lazy evaluation are far less important than the other gains it brings (because the performance gains it brings are rather small).

Re: Rust as a gateway drug to Haskell

#120
post #108
post #101

Earlier quoted context omitted.

I don't think anything is the unique selling point of laziness. Wikipedia[1] says "The benefits of lazy evaluation include: * The ability to define control flow (structures) as abstractions instead of primitives. * The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms. * Performance increases by avoiding needless calculations, and error cond…

"the first and second points are at least an order of magnitude more important than the third." No offense, but 'performance is not as important as...' is what basically all pro-FP devs say for years, still it seems that the rest of the world thinks exactly the opposite.

It's hard to believe that a world where Ruby, Python and Node are massively popular cares about performance above expressiveness. Even Java became popular first and fast afterwards—not even talking about memory efficiency!

I'd agree that a lot of developers still over-index on performance though, probably because it's sexy and easy to measure.

Post reply on HN