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

181–190 of 218 posts

Re: Rust as a gateway drug to Haskell

#181

Post by vesak »

douche wrote: post #118
vesak wrote: 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?

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

Indeed. Some people actually use Haskell, though. They even claim it's fun and productive, but having done so myself, I'm forced to be undecided on whether they're just suffering from Stockholm Syndrome.

Re: Rust as a gateway drug to Haskell

#182

Post by cousin_it »

kqr wrote: post #176
cousin_it wrote: post #54

Earlier quoted context omitted.

I tried implementing some simple imperative algorithms (like union-find) and found the Haskell code very noisy. For example, "var x = f(y)" in an imperative language might translate to "let x = f y" or "do x <- f y" in a Haskell do block, and the wrong variant won't compile. There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Writing code that mixes…

> There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Well, yes, there is: general recursion. You can recreate any loop with plain old recursion. But stating that as a problem is a little like coming to Java and saying that "there's no general purpose idiom you can use to replace goto, only tons of special semantic branching constructs you must memor…

I don't think that's true. Say you have an imperative algorithm that modifies an array in a loop. Then the Haskell encoding of that algorithm will use writeArray. But since it's monadic, it won't look like general recursion, it'll need to use a combinator like forM. You could say it's general recursion plus bind and return, but it gets worse. If the loop body needs to use both writeArray and randomness, you need more combinators. I'm not sure anyone can reliably write that stuff on a napkin, the way I can write a loop. That's not like the situation with gotos, because code with gotos is harder to write on a napkin.

Re: Rust as a gateway drug to Haskell

#183

Post by codygman »

snovv_crash wrote: post #82
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.

In other languages when the compiler misses an optimization you get a constant order penalty on a small piece of code. In Haskell when the compiler misses an optimization the performance hit is potentially unbounded, as it could think anything is a dependency. (You want the first N digits of pi? Just wait while I calculate all of them for you...)

> You want the first N digits of pi? Just wait while I calculate all of them for you...

I don't think that example cold actually happen, or at least I can't see how it would happen in Haskell.

Re: Rust as a gateway drug to Haskell

#184

Post by yitzg »

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.

As a Haskell practitioner in industry - for several years we have been creating technical documentation sites for large enterprise customers, providing fast semantic search for gigabytes of content serving millions of users - I can attest that this simply isn't true. We have found that reasoning about performance in a pure functional language is not harder than for any other kind of mainstream language. Except in the sense that it is different, so not all of your skills and intuition from other languages necessarily apply.

Re: Rust as a gateway drug to Haskell

#185

Post by lmm »

adamwk wrote: post #141
lmm wrote: post #136

Earlier quoted context omitted.

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

MLs have higher kinder types.

Which ones? OCaml is planning to add them via its "modular implicits" work but that hasn't happened yet; none of the SML implementations I used mentioned them.

Re: Rust as a gateway drug to Haskell

#186

Post by tome »

k__ wrote: post #134
tome wrote: post #119

Earlier quoted context omitted.

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.

That's OK!

Re: Rust as a gateway drug to Haskell

#187

Post by taktoa »

firethief wrote: post #161
runeks wrote: post #115

Earlier quoted context omitted.

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…

A System F type system can't be replaced by a dependent type system without affecting existing code. There is no way to turn the libraries in Haskell into libraries in dependently-typed Haskell without "porting them to a new language" and all the work that entails.

This is 100% false. The Calculus of Constructions is a superset of System F. You may be thinking of the fact that if you want your type system to be sound when interpreted as a logic, then termination must be guaranteed (which would break backwards compatibility). Dependent types and totality are often found together, but are in actuality orthogonal features.

Re: Rust as a gateway drug to Haskell

#188

Post by taktoa »

pathsjs wrote: post #70
lmm wrote: post #60

Earlier quoted context omitted.

Languages without HKT are horribly impractical for large codebases.

Yet there are not many large codebases in languages with HKT, and even those which are there (mainly big Scala projects) do not use HKT

Standard Chartered has a multimillion line codebase in Haskell (technically an internal variant called Mu).

Re: Rust as a gateway drug to Haskell

#189

Post by tome »

cousin_it wrote: post #182
kqr wrote: post #176

Earlier quoted context omitted.

> There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Well, yes, there is: general recursion. You can recreate any loop with plain old recursion. But stating that as a problem is a little like coming to Java and saying that "there's no general purpose idiom you can use to replace goto, only tons of special semantic branching constructs you must memor…

I don't think that's true. Say you have an imperative algorithm that modifies an array in a loop. Then the Haskell encoding of that algorithm will use writeArray. But since it's monadic, it won't look like general recursion, it'll need to use a combinator like forM. You could say it's general recursion plus bind and return, but it gets worse. If the loop body needs to use both writeArray and randomness, you need more…

What's wrong with this?

    import qualified Data.Vector.Mutable as V
    import           Control.Monad       (when)
    import qualified System.Random       as R
    
    main = do
        v

Re: Rust as a gateway drug to Haskell

#190

Post by thesz »

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.

Something I found about going to Haskell from is that Haskell provides many powerful abstractions without compromising on performance. Especially programmer's performance.

If you do not need to write notoriously slow code in Haskell, just don't do it. Use libraries (containers and mtl especially great), keep state strict (a handful of bang patterns).

I use Haskell's laziness with great success (look for paper "generating power of lazy semantics" it's fascinating; look "the essence of functional programming" for even more fascination). I use Haskell's flexibility with great success (how about beating C speed ten times? how about parallelization to all cores with couple lines of code?). It is really great language.

BTW, Haskell's RTS reuse chunk type field which is needed for implementation of laziness for synchronization and it is great! This means that it can provide everything that Java and/or .Net provides and get away with twice as less overhead for it.

Post reply on HN