Live data from Hacker News

Rust as a gateway drug to Haskell

xion.io

171–180 of 218 posts

Re: Rust as a gateway drug to Haskell

#172
post #30

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.

That's... not really true. JavaScript solves trivial problems, and it's mainly popular because it's literally the only web language around.

Re: Rust as a gateway drug to Haskell

#173

Earlier quoted context omitted.

It's not just laziness. Functional programming is what happens to the universe when you eliminate the concept of Time. It is a mega abstraction over the what's really going on under the hood. However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie. Reasoning about the perfo…

>Functional programming is what happens to the universe when you eliminate the concept of Time. I've heard this a lot but still can't find a good code example to illustrate this. Any help?

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

Re: Rust as a gateway drug to Haskell

#174

Earlier quoted context omitted.

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

You might have better luck with the fast-logger library, for one. I'd also suggest using ansi-wl-pprint, which would work on Windows and also probably be faster than string concatenation (which is just plain bad in Haskell).

As was pointed out, GHC is calling getCurrentTime too often. If you take advantage of GHC's laziness, the value will stay valid longer. I assume that is what fast-logger does.

https://hackage.haskell.org/package/fast-logger

Re: Rust as a gateway drug to Haskell

#175
post #78
post #46

Earlier quoted context omitted.

Mutable hashtables: https://hackage.haskell.org/package/hashtables Mutable arrays: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat... Strict by default: Put {#- Language Strict #-} at the top of files where necessary but usually you'd just use bangpatterns and unbox-strict-fields.

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 is unusually complicated because it avoids a complicated problem that exists in the C code. (Which is that 16-bit encodings can't cover all of UCS-4 with fixed character widths.)

Besides, I don't understand why they are making such a complicated solution. In this comparison [1], the first example in that post is the "target". The best performing solution is... you guessed it:

    foldZip a b =
        List.foldl' (\r (cha, chb) -> if cha /= chb then r+1 else r) 0 (Text.zip a b)
And a pet peeve: the way you say "only in the ST monad" is a funny rhetoric device. You make it sound like everyone agrees it's a bad thing to isolate mutation to local regions. Here's the thing: it's not. And the way you can integrate local mutation in your application with the ST monad is fantastic.

By just typing "ST" a few extra times you get local mutation exactly where you want to, and nowhere you don't want it!

[1]: http://i.xkqr.org/scrot_20170615032548.png

Re: Rust as a gateway drug to Haskell

#176
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.

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 memorize." Sure, a valid complaint if you've been forced to only use goto in your life, but not a reflection on good programming practise.

Re: Rust as a gateway drug to Haskell

#177
post #91

Isn't the most significant line: "For work-related reasons, I had to recently get up to speed on programming in Haskell"? I was somewhat disappointed not to have a followup to what work-related reasons there might be. Note also that the About page says "work at Facebook".

If you're puzzling at the connection between Facebook and Haskell, https://github.com/facebook/Haxl is the most obvious one.

Re: Rust as a gateway drug to Haskell

#178

Earlier quoted context omitted.

>Functional programming is what happens to the universe when you eliminate the concept of Time. I've heard this a lot but still can't find a good code example to illustrate this. Any help?

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.

Re: Rust as a gateway drug to Haskell

#179

Earlier quoted context omitted.

It's not just laziness. Functional programming is what happens to the universe when you eliminate the concept of Time. It is a mega abstraction over the what's really going on under the hood. However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie. Reasoning about the perfo…

>Functional programming is what happens to the universe when you eliminate the concept of Time. I've heard this a lot but still can't find a good code example to illustrate this. Any help?

Immutability is equivalent of eliminating time. To be unchanging is to be timeless.

Re: Rust as a gateway drug to Haskell

#180
post #115
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…

>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 safer bet, even if it lacks many nice things. The sum is probably quite a lot better still.

Post reply on HN