Live data from Hacker News

Rust as a gateway drug to Haskell

xion.io

131–140 of 218 posts

Re: Rust as a gateway drug to Haskell

#131

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.

I had the same experience: I really enjoyed the expressiveness and power of Haskell, as well as the strong type system. But Rust gives me all those things, as well as iterators for laziness when desired , without the pervasive laziness that had me constantly chasing down space leaks and adding strictness annotations.

>But Rust gives me all those things, as well as iterators for laziness when desired, without the pervasive laziness that had me constantly chasing down space leaks

Well, yeah, Rust has manual memory management. Of course you don't get space leaks.

Anyways, Rust's laziness is not on par with Haskell. Iterators are great but it's not at all the same as e.g. GHC's lazy IO.

Re: Rust as a gateway drug to Haskell

#132

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…

Do you have source code? It sounds like you were writing unidiomatic Haskell.

Re: Rust as a gateway drug to Haskell

#133

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.

I don't use Haskell but didn't I read recently that the latest version of Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly?

>Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly

It's a common concern but it's a terrible critique. Laziness has many subtle benefits, but everyone whines about it because its pitfalls are decidedly not subtle.

Re: Rust as a gateway drug to Haskell

#134
post #119
post #108

Earlier quoted context omitted.

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

Yes, you're right. I'm sorry.

Re: Rust as a gateway drug to Haskell

#135

I have heard the same thing about Kotlin now - https://hackernoon.com/kotlin-functors-applicatives-and-mona...

Err kotlin as a gateway drug to haskell? They might wanna fix type erasure first....

Can't fix that w/o fixing the JVM.

Re: Rust as a gateway drug to Haskell

#136
post #100
post #8

Earlier quoted context omitted.

Comparing it against Rust doesn't really seem fair. If I wasn't using Haskell, I'd be writing Erlang, and last I checked GHC is much faster than Erlang/OTP. Certainly faster than CPython, Ruby, and most Node.js. Trying to compete with Rust or C++ performance in Haskell is certainly frustrating to reason about :)

Why not SML/CML where you basically get haskell syntax and types, but get modules, no laziness, and you can mutate things when it's more efficient to do so.

I couldn't stand to work without HKT now that I'm used to them. (Hell, I'm struggling with Scala's lack of polykinded types; you don't need them until you do, but then you really need them).

Re: Rust as a gateway drug to Haskell

#137

Earlier quoted context omitted.

Since performance is exactly a measure of the number of imperative steps that need to happen in a program This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.

Cache locality will never beat algorithmic complexity as a performance factor. Don't exaggerate its importance.

It can, when the constant portion of the algorithm chosen is high and the number of items being pushed through the algorithm is low.

e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted.

Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).

Re: Rust as a gateway drug to Haskell

#138
post #108

Earlier quoted context omitted.

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

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

To keep producing responsive compute programs as the complexity of those programs continues to rise while the single-core CPU performance remains steady, program performance must become more and more important.

Re: Rust as a gateway drug to Haskell

#139

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.

It's not just laziness. Functional programming is what happens to the universe when you eliminate the concept of Time. It is a mega abstraction over the what's really going on under the hood. However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie. Reasoning about the perfo…

>Functional programming is what happens to the universe when you eliminate the concept of Time.

I've heard this a lot but still can't find a good code example to illustrate this. Any help?

Re: Rust as a gateway drug to Haskell

#140

Earlier quoted context omitted.

I had the same experience: I really enjoyed the expressiveness and power of Haskell, as well as the strong type system. But Rust gives me all those things, as well as iterators for laziness when desired , without the pervasive laziness that had me constantly chasing down space leaks and adding strictness annotations.

>But Rust gives me all those things, as well as iterators for laziness when desired, without the pervasive laziness that had me constantly chasing down space leaks Well, yeah, Rust has manual memory management. Of course you don't get space leaks. Anyways, Rust's laziness is not on par with Haskell. Iterators are great but it's not at all the same as e.g. GHC's lazy IO.

> Well, yeah, Rust has manual memory management. Of course you don't get space leaks.

I wouldn't call Rust's memory management "manual". It's the only language I know of that I'd describe as having automatic memory management without garbage collection.

> Anyways, Rust's laziness is not on par with Haskell. Iterators are great but it's not at all the same as e.g. GHC's lazy IO.

Iterators, futures, and macros (for creating new language constructs) tend to provide the laziness I want. Beyond that, I've tended to find laziness as much a source of bugs as features. (Speaking from a perspective of having written and maintained large programs in Haskell, and in Rust.)

Post reply on HN