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

161–170 of 218 posts

Re: Rust as a gateway drug to Haskell

#161

Post by firethief »

runeks wrote: post #115
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.

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.

Re: Rust as a gateway drug to Haskell

#162

Post by AlexeyBrin »

jandrese wrote: post #124
AlexeyBrin wrote: post #99

Earlier quoted context omitted.

AFAIK only the core language is fully ported, for the libraries ... it is a work in progress.

In other words it is useless currently.

Tell that to IBM that uses Swift in production. See IBM's Kitura open source server framework if you are interested.

Re: Rust as a gateway drug to Haskell

#164

Post by verandaguys_alt »

vmchale wrote: post #132
verandaguys_alt wrote: post #112

Earlier quoted context omitted.

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.

I actually posted the port on the Code Review SE, where (after almost a month of silence), someone stepped up and offered a CFFI solution.

https://codereview.stackexchange.com/questions/157118/a-port...

Re: Rust as a gateway drug to Haskell

#165

Post by Tarean »

dgroshev wrote: post #74
oconnore wrote: 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 :)

I would argue that at least for client-server apps Erlang is faster . Here is why: in most cases the perceived performance of a server is constrained by maximum (or 99%, whatever) latency, not by throughput. Moreover, you can scale throughput horizontally, while scaling for latency is more or less impossible. Haskell's GC can give you horrendous pauses (see [1][2]), ruining perceived performance. Erlang, on the other…

Yeah, the worst case of ghc's garbage collection is awful and can dwarf the actual work being done. That's the man driving factor behind adding linear types to haskell - they let long lived and large data live on a separate non-gced heap.

The other big part of this is that it can make stream fusion predictable. Currently haskell programs can become 100x slower or faster after some innocuous change, so linear types will make it a lot easier to write fast haskell in general.

http://blog.tweag.io/posts/2017-03-13-linear-types.html

Re: Rust as a gateway drug to Haskell

#166

Post by Tarean »

igouy wrote: post #148
Tarean wrote: post #43

Earlier quoted context omitted.

The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work on it. Can't say for sure, though, so maybe I just should try a task and implement it to see how fast it'd be without amazing optimization foo. Although of course these benchmarks aren't really representative of the real world because they'd just end up as a c…

That pi-digits program does not "build on [your] machine no problem". It cannot. The line "main = putStr.pidgits.read.head =<< getArgs" has been commented out because the program author has optimised-away some of the work that must be done.

Fair enough, I only checked the two knucleotide programs which both failed because of missing dependencies.

Re: Rust as a gateway drug to Haskell

#167

Post by Tarean »

kccqzy wrote: post #49
Tarean wrote: post #44

Earlier quoted context omitted.

Did rust ever have a large scale breaking change? Anyway, the linear type proposal is designed to be completely backwards compatible so that shouldn't be as big of an issue.

Yes I know it's completely backwards compatible. But in practice if the standard libraries don't change, (a) there won't be a ready source of inspiration and examples to copy from; (b) actually the feature is really geared more towards libraries than applications, so it's less useful if the base library doesn't adopt it wholeheartedly.

Fair enough, although it would be easy to have an alternative prelude with linear types that libraries could depend on. Just that the extra dependency would really suck.

Haven't sunk a lot of time into it yet to be honest, I think the biggest beneficiaries will be streaming libraries and non-gced data structures like long lived queues?

Re: Rust as a gateway drug to Haskell

#168

Post by hydraz »

haldean wrote: post #154
Symmetry wrote: post #151

Earlier quoted context omitted.

Yes, stream fusion is super nifty. But can Haskell alter the size of the chunks it's sending through the stream? There was a recent HN thread about how GNU 'yes' is so fast thanks to buffering. Obviously too large a buffer would blow out the cache and stream fusion avoids that but a moderate amount of buffering so that you're neither working array by array nor element by element but cachable chunk by cachable chunk s…

I think that the issue you're describing about `yes` was around building a buffer and issuing one big write() syscall instead of a bunch of small ones. I'm not sure about the actual implementation of the IO monad, and whether or not it coalesces call to write(), but it would definitely be possible. Also, idiomatic Haskell would make large writes, because usually (at least in my experience) you create a large string/T…

GHC doesn't actually perform stream fusion. Not by default, anyway: The default (by that I mean "ships with base", not that it's baked into the compiler) is something weaker, called build/foldr fusion, described by this rule:

  foldr z f (build g) = g f z
Foldr is the usual catamorphism for the inductive list type, and build is an "abstracted constructor", of sorts:

  build :: (forall b. (a -> b -> b) -> b -> b) -> [a]
  build f = f (:) []
Note that build's argument is rank-2 polymorphic, and also the same as foldr's type.

Re: Rust as a gateway drug to Haskell

#169

Post by vmchale »

delhanty wrote: post #25
wyager wrote: post #16

Earlier quoted context omitted.

This is a very overstated concern, in my opinion. Based on my experience, once you learn the common gotchas (lazy folds, WHNF, etc.) it's rarely an issue. Real-world programs (web servers, databases, etc.) typically end up using frameworks that deal with strictness concerns for you anyway. For maybe the first couple weeks I was learning Haskell, this was a source of confusion, but I don't seem to run into it anymore.…

> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2]. The following is just my vague, uninfor…

>Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2].

That's a really bad benchmark. The power of Haskell is not that it's fast for generating the Mandelbrot set, it's that it allows you to things you couldn't do in any other language while still being fast enough to write e.g. compilers (Idris) or web services (Yesod).

Re: Rust as a gateway drug to Haskell

#170

Post by vmchale »

cousin_it wrote: post #54
eklavya wrote: post #36

Earlier quoted context omitted.

What is it lacking for imperative programming? I find it to be immensely good at it!

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.

Ah, but there is! Recursion schemes.

>Usually an imperative algorithm will be much clearer in an imperative language than in Haskell, and easier to get right on the first try.

Not sure what an "imperative algorithm" is, but I agree there are tasks better suited to imperative languages.

Post reply on HN