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

201–210 of 218 posts

Re: Rust as a gateway drug to Haskell

#201

Post by crimsonalucard »

crimsonalucard wrote: post #178
haskellandchill wrote: post #173

Earlier quoted context omitted.

The statement makes no sense. See FRP for a take on how to handle time-varying behavior.

It does make sense. Man of course whenever the functional paradigm switches to IO things change. The functional program needs to have an exception somewhere or nothing gets done. I'm talking about the functional part of functional programming, not how the IO monad is implemented.

Let me make my statement clearer. The FRP loop has a part that is not pure (IO). This is where time enters the picture. FRP is not 100% functional, no functional programming language is... but if you look at the functional part of a functional programming language you will see that it is immutable.

Re: Rust as a gateway drug to Haskell

#202

Post by FullyFunctional »

xwvvvvwx wrote: post #104
whatshisface wrote: post #84

Earlier quoted context omitted.

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.

This is an oversimplification. Some compute intensive parts can get significant speed ups through careful use of data parallelism (such as SIMD). Others needs parallelism at the thread level. Etc. Optimizing for memory patterns is important as is trying to keep the working set within a near-level cache.

Re: Rust as a gateway drug to Haskell

#203

Post by FullyFunctional »

hajile wrote: post #100
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 :)

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.

The difference in both syntax and type system is vast, unless you are coming from, say Fortran or APL.

Re: Rust as a gateway drug to Haskell

#204

Post by Tarean »

kqr wrote: post #175
pathsjs wrote: post #78

Earlier quoted context omitted.

Well, these are mutable, but only in the ST or IO monad - which is a guarantee, but at the same time it is not quite the same thing. You cannot just accumulate state by mutating some stuff, then in a separate part of the program mutate it again. Which is intentional, of course, but quite opposite to the imperative mindset. About {#- Language Strict #-}, thank you - I was not aware of it. I think the first example in…

Well, if you want to do full imperative programming with warts and all, you'll probably want to stick to the IO monad for your entire program anyway. You just have to be aware that you're actively handicapping your compiler by choosing to do full imperative programming. (In most other languages, the compilers come handicapped out of the box...) I think the first example in that post is a bit unfair. The Haskell code…

Technically this is only correct if a and b have the same length so you would need to do a length check prior:

    foldZip a b
      | T.length a /= T.length b = Nothing
      | otherwise = foldl' step 0 (T.zip a b)
      where step acc (l, r) = if l == r then acc+1 else acc
This is slightly awkward because T.length is an O(n) operation, though. I think the optimal implementation would be a hyper optimized variant that depends on correct byte alignment and this as slow fallback method if that fails.

Re: Rust as a gateway drug to Haskell

#206

Post by Tarean »

delhanty wrote: post #85
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…

I agree with all that, particularly the bit about the c ffi call. It's more relevant to compare Rust with C and C++, as Rust is a language that could reasonably display C for the ffi call. But then remember that @wyager is claiming >80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C If it's really only 10% of the effort then one shouldn't really have "to work on it" to get semi-decent perf…

Tried my hand at the knucleotide[1] one. Lifted the algorithm from the fastest rust solution. As optimization I dropped some Unpack pragmas and strictness annotations, used Data.Hashtable.Cuckoo for in-place updating hash tables because that seemed necessary for the task, and added naive parallelization via

   let outputs = map (exec content) tasks `using` parList rseq
That got around 24 seconds which seems acceptable for a fairly straightforward solution that is around half the size of the rust one I copied. Might try to optimize later.

[1]: http://benchmarksgame.alioth.debian.org/u64q/knucleotide.htm...

Re: Rust as a gateway drug to Haskell

#207

Post by adamwk »

lmm wrote: post #185
adamwk wrote: post #141

Earlier quoted context omitted.

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.

I think you're confusing higher-kinded types with type classes. You're right that neither has type classes.

Re: Rust as a gateway drug to Haskell

#208

Post by vmchale »

igouy wrote: post #199
vmchale wrote: post #169

Earlier quoted context omitted.

>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 whil…

Really bad benchmark ? Inappropriate choice of benchmark?

I have a hard time seeing the value in a Mandelbrot benchmark. I absolutely don't have a problem with benchmarks that make Haskell look bad (e.g. directory traversal, regex), but I would like a benchmark that provides insight into the code you'd feasibly be writing in that language.

Re: Rust as a gateway drug to Haskell

#209

Post by jandrese »

AlexeyBrin wrote: post #162
jandrese wrote: post #124

Earlier quoted context omitted.

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.

They use a language without a standard library in production?

Re: Rust as a gateway drug to Haskell

#210

Post by kqr »

Tarean wrote: post #204
kqr wrote: post #175

Earlier quoted context omitted.

Well, if you want to do full imperative programming with warts and all, you'll probably want to stick to the IO monad for your entire program anyway. You just have to be aware that you're actively handicapping your compiler by choosing to do full imperative programming. (In most other languages, the compilers come handicapped out of the box...) I think the first example in that post is a bit unfair. The Haskell code…

Technically this is only correct if a and b have the same length so you would need to do a length check prior: foldZip a b | T.length a /= T.length b = Nothing | otherwise = foldl' step 0 (T.zip a b) where step acc (l, r) = if l == r then acc+1 else acc This is slightly awkward because T.length is an O(n) operation, though. I think the optimal implementation would be a hyper optimized variant that depends on correct…

I discovered yesterday that my previous benchmarks were wrong for some reason. Zip+fold isn't actually that fast: http://i.xkqr.org/scrot_20170615223112.png

What is fast – without reaching into the Text object internal representation – is good old tail-call recursion. And you can even integrate the length check into the traversal! Making it an O(min(n,m)) operation in total.

Post reply on HN