Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust as a gateway drug to Haskell

xion.io

Post reply on HN
Print view View original

101–110 of 218 posts

Re: Rust as a gateway drug to Haskell

#101

Post by tome »

k__ wrote: post #65
slaymaker1907 wrote: post #2

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.

Wasn't the selling point of laziness performance? "It only does what is needed!" I didn't use Haskell but Nix and at least there it seemed reasonable to "not do" everything.

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 conditions in evaluating compound expressions."

In my several-year experience as a professional Haskell developer the first and second points are at least an order of magnitude more important than the third.

[1] https://en.wikipedia.org/wiki/Lazy_evaluation

Re: Rust as a gateway drug to Haskell

#102

Post by leshow »

I have found them to be very similar too. I started learning Haskell in earnest last September, following along with the exceptional "Haskell: First Principles" which I highly recommend. I had been toying with Rust around this time and I found a confluence of ideas between the two languages. Most things I learned in Haskell I was able to carry over to Rust.

The inverse was not quite as true. But I still love Rust. Any time I need something performant, or I just want to play around, it's my first choice.

Re: Rust as a gateway drug to Haskell

#103

Post by cesarb »

whatshisface wrote: post #84
chongli wrote: post #69

Earlier quoted context omitted.

super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-non…

A sufficiently smart [compiler | developer] can [make it so that | think] anything is easy. Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs…

> "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.

Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).

Re: Rust as a gateway drug to Haskell

#104

Post by xwvvvvwx »

whatshisface wrote: post #84
chongli wrote: post #69

Earlier quoted context omitted.

super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-non…

A sufficiently smart [compiler | developer] can [make it so that | think] anything is easy. Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs…

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.

Re: Rust as a gateway drug to Haskell

#105

Post by dpratt »

oconnore wrote: post #8
slaymaker1907 wrote: post #2

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.

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 :)

Scala would like to have a word with you.

Re: Rust as a gateway drug to Haskell

#106

Post by logicchains »

mrkgnao wrote: post #19
delhanty wrote: post #5

Earlier quoted context omitted.

>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. +1 One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production. It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but sti…

I'm under the impression that SPJ made that comment thinking of adoption (for a future "regrettably popular" Haskell), since the difficulty of reasoning about laziness does put people off. I might be wrong though: maybe he was arguing that laziness doesn't warrant the user and compiler-author cost it brings. I don't remember where I picked this up from. Idris is strict too, but optional laziness is built into the com…

>something similar to Rust lifetimes, but weaker

Why weaker? My understanding is that linear types provide a stronger guarantee than Rust's affine types: linear types guarantee that a value is used once, while affine types only guarantee that a value is used no more than once.

Re: Rust as a gateway drug to Haskell

#107

Post by tom_mellior »

k__ wrote: post #63
agumonkey wrote: post #61

Earlier quoted context omitted.

not even the monomorphism, I forgot but there's a few warts at the syntactic level only.

A few months ago I read monomorphism is the way to go performance wise. Something about people writing fast code with Flow/TypeScript than with plain JavaScript because the typing leads to less polymorphic code which is easier to optimize for the compiler.

In this context, "monomorphism" just meant that OCaml requires you to write "+" to add integers and "+." to add floats (and yet other things to add bignums or whatever).

This has nothing to do with performance per se. It doesn't make OCaml code faster than languages that allow you to write "+" for both int+int and float+float. The compiler knows anyway.

Re: Rust as a gateway drug to Haskell

#108

Post by k__ »

tome wrote: post #101
k__ wrote: post #65

Earlier quoted context omitted.

Wasn't the selling point of laziness performance? "It only does what is needed!" I didn't use Haskell but Nix and at least there it seemed reasonable to "not do" everything.

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.

Re: Rust as a gateway drug to Haskell

#109

Post by Jweb_Guru »

logicchains wrote: post #106
mrkgnao wrote: post #19

Earlier quoted context omitted.

I'm under the impression that SPJ made that comment thinking of adoption (for a future "regrettably popular" Haskell), since the difficulty of reasoning about laziness does put people off. I might be wrong though: maybe he was arguing that laziness doesn't warrant the user and compiler-author cost it brings. I don't remember where I picked this up from. Idris is strict too, but optional laziness is built into the com…

>something similar to Rust lifetimes, but weaker Why weaker? My understanding is that linear types provide a stronger guarantee than Rust's affine types: linear types guarantee that a value is used once, while affine types only guarantee that a value is used no more than once.

Lifetimes are not the same as linear (or affine) types... they're related to "fractional permissions" in the upcoming formalism (and also related to region types found in many other systems, which can be partially emulated with monads).

Re: Rust as a gateway drug to Haskell

#110

Post by Sharlin »

motet_a wrote: post #30
toprerules wrote: post #15

The similarities are striking. Both have a problem with undocumented or experimental modules for everyday tasks, both use compiler plugins to make sure that every package is using its own superset of the language (although in Rust this only applies to nightly), both tout lofty goals while rarely producing production grade systems. Rust is the first toe dip into the world of blog posts heralding the"coming of the age…

Yes. Complex languages are not required to solve complex problems. This is why Go and JavaScript are so popular.

I'd say neither Go nor JavaScript are predominantly used to solve complex problems. The main use cases for both are solving mundane problems by mundane programmers. In case of Go that's an explicit design philosophy.
Post reply on HN