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

71–80 of 218 posts

Re: Rust as a gateway drug to Haskell

#71

Post by pas »

toprerules wrote: post #15

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…

There's nothing wrong with the ability to generalize abstractions, the problem is when all you know are category theory everything looks like a zygohistomorphic prepromorphism.

Case in point, TypeScript and mypy. Both are adding more abstractions, more powerful types, more aspects, because people find/have fitting use cases for those features.

That doesn't mean let blah = document.getElementById("blah") ; blah.innerHTML = "..." or import requests ; requests.post(...) will become deprecated, but it means it'll be easier to express more things (like conditions/assumptions on shape or state of data, control flow, component dependencies) without boilerplate (and copy-paste), and maybe helping other developers make sure they cross all the t-s and dot all the i-s.

Does this have a cognitive cost? Yes, especially in Rust/Haskell.

Are there escape hatches? Yes, of course, like unsafe and whatever Haskell has.

Should a developer who isn't familiar with those assumptions/conditions work on the code base anyway? No, not really.

(Is Haskell ugly? Yes. :( )

Re: Rust as a gateway drug to Haskell

#72

Post by chongli »

jnordwick wrote: post #31
toprerules wrote: post #15

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…

Although clearly presented to push some buttons, it isn't completely wrong. Am upvote hoping you don't get buried.

it isn't completely wrong

It may get some of the facts right, but the tone is completely wrong. Cynicism is just a step or two away from nihilism. It's far, far easier to destroy than it is to create. The world needs more creators, not destroyers.

Re: Rust as a gateway drug to Haskell

#73

Post by guipsp »

pas wrote: post #71
toprerules wrote: post #15

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…

There's nothing wrong with the ability to generalize abstractions, the problem is when all you know are category theory everything looks like a zygohistomorphic prepromorphism. Case in point, TypeScript and mypy. Both are adding more abstractions, more powerful types, more aspects, because people find/have fitting use cases for those features. That doesn't mean let blah = document.getElementById("blah") ; blah.innerH…

The haskell escape hatches are the unsafe family of functions, such as unsafePerformIO

Re: Rust as a gateway drug to Haskell

#74

Post by dgroshev »

oconnore wrote: post #8
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.

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 hand, is thoroughly optimized for minimal latency.

TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense.

[1] https://making.pusher.com/latency-working-set-ghc-gc-pick-tw...

[2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and...

Re: Rust as a gateway drug to Haskell

#76

Post by Retra »

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…

Just because it doesn't translate 1-to-1 from another imperative language doesn't mean it isn't imperative itself. Haskell is not in the C family. It's not going to accept straight translations from C, but C doesn't monopolize imperativeness either.

Re: Rust as a gateway drug to Haskell

#77

Post by AlexeyBrin »

beefsack wrote: post #68
nicoburns wrote: post #40

Earlier quoted context omitted.

Have you looked at Swift? It's pretty similar to Rust, but eschews all the lifetime stuff in favour of a runtime that does reference counting.

Swift is useful if you're an Apple developer only targeting Apple users, seems like a bit of a niche.

Swift works reasonably well on Linux. You can even run Swift on Windows 10 through Windows Subsystem for Linux.

Re: Rust as a gateway drug to Haskell

#78

Post by pathsjs »

Tarean wrote: post #46
pathsjs wrote: post #41

Earlier quoted context omitted.

Don't know... mutable collections? A way to make sure things are evaluated without writing seq every other line?

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 this post https://markkarpov.com/post/migrating-text-metrics.html makes it clear that, while one can program in imperative style, it is not at all natural, and it is going to introduce as much boilerplate as, say, trying to program in functional style in Java 6

Re: Rust as a gateway drug to Haskell

#79

Post by marcosdumay »

wyager wrote: post #16
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.

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

Some real world programs have a very clear request-response cycle that Haskell deals with very well (although a more predictable garbage collector would be great).

Other real world programs have a strict "always push things into the world, react to inputs" cycle that Haskell has trouble supporting.

Re: Rust as a gateway drug to Haskell

#80

Post by cbcoutinho »

allengeorge wrote: post #75

The article references using trait objects for dynamic dispatch. FWIW, I found them extremely limited: you can't use generics, can't return Self... I wonder how often people use them.

What do you mean you can't return self? I'm just starting out with learning rust, but from what I've gathered you can use objects in a myriad of ways that will allow you do what you need.

Instead of returning self, you could just pass a reference - you need to mutate self then just pass a mutable reference. Did I miss something here?

Post reply on HN