Rust as a gateway drug to Haskell

Post by vesak » Fri, Jun 16, 2017, 7:11 AM UTC

runeks wrote: post #197

vesak wrote: post #180

Earlier quoted context omitted.

>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. What would we exactly lose? >As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering. That is true, though. Perhaps Rust is the saf…

> What would we exactly lose? We'd lose composability and clearer code. This[1] section of the Haskell Wiki contains a good example. In short, with something like this: any :: (a -> Bool) -> [a] -> Bool any f lst = or boolLst where boolLst = map f lst the compiler can produce reasonably optimal code, because it doesn't have to convert the entire [a] to a [Bool] , because of lazy evaluation -- when or encounters the f…

Post by runeks » Fri, Jun 16, 2017, 3:26 PM UTC

vesak wrote: post #211

runeks wrote: post #197

Earlier quoted context omitted.

> What would we exactly lose? We'd lose composability and clearer code. This[1] section of the Haskell Wiki contains a good example. In short, with something like this: any :: (a -> Bool) -> [a] -> Bool any f lst = or boolLst where boolLst = map f lst the compiler can produce reasonably optimal code, because it doesn't have to convert the entire [a] to a [Bool] , because of lazy evaluation -- when or encounters the f…

I don't know Idris so this syntax is probably wrong, but by reading the docs for a short while, this would be any : (a -> Bool) -> Lazy List a -> Bool ... which would make it as performant and clearer than Haskell's any, since the laziness is explicit. Someone with actual Idris experience might tell if it actually would work like this :) I guess we'd have to make sure that the used or function is also lazy.

Post by igouy » Fri, Jun 16, 2017, 9:04 PM UTC

Tarean wrote: post #43

delhanty wrote: post #35

Earlier quoted context omitted.

> .. 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. I don't mean to be personal, but your quantative claim smells a little like unsubstantiated BS. Do you have any data to back it up? > That said, Haskell performs pretty well in the toy benchmarks anyway. Currently, "pretty well" looks like GHC performance is 50% to 10% of…

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…

Post by wtetzner » Tue, Jun 20, 2017, 2:39 AM UTC

hxegon wrote: post #145

zem wrote: post #18

Earlier quoted context omitted.

ocaml is a great language in its own right too; the only haskell features I find myself really missing are do notation and operator overloading.

OCaml seems like the ideal language for me on the surface, but the onboarding process is... suboptimal IMO. There's a lack of good soft/hard documentation (AKA the "no, type signatures are not sufficient documentation" problem), but my biggest turn off is the multiple standard libraries. Some might see that as a plus, but when I'm just trying to get a small learning project off the ground, and I find out there's a cr…