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

121–130 of 218 posts

Re: Rust as a gateway drug to Haskell

#121

Post by crimsonalucard »

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.

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 performance of a functional program is to peer through the lie and "reintroduce" time into this abstraction. This is why it it notoriously hard for functional programs to be reasoned about. Procedural programs are much more better for this in that regard.

Re: Rust as a gateway drug to Haskell

#122

Post by tome »

crimsonalucard wrote: post #121
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.

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…

This is utter nonsense.

Everything you wrote is somewhere between 90° and 180° wrong.

Re: Rust as a gateway drug to Haskell

#124

Post by jandrese »

AlexeyBrin wrote: post #99
beefsack wrote: post #81

Earlier quoted context omitted.

I tried under Arch a few months ago and found swathes of the standard library didn't appear to work, is this something which has been fixed?

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

In other words it is useless currently.

Re: Rust as a gateway drug to Haskell

#125

Post by willtim »

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.

Most problems arise from using linked-lists in inappropriate situations. This includes using the default String type. Both the list and string syntax have been overloadable for a while, so using alternatives when necessary shouldn't be an issue. Understand the complexity of the data structure operations you are using and you will get fast code, laziness does not change this (although space usage can be hard to reason about).

The benefits of laziness is difficult to appreciate if you are not used to it. For a great example of the benefits it brings, please read this:

http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...

Re: Rust as a gateway drug to Haskell

#126

Post by crimsonalucard »

tome wrote: post #122
crimsonalucard wrote: post #121

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…

This is utter nonsense. Everything you wrote is somewhere between 90° and 180° wrong.

I'm totally correct. You are completely unaware of what's going on. We can discuss this logically in the comments, you'll see. It's not going to pretty for you as my arguments will pick you apart piece by piece.

Re: Rust as a gateway drug to Haskell

#127

Post by nickpsecurity »

le0n wrote: post #22

Haskell/GHC will soon have an extension for linear types, which will bring the languages much closer: http://blog.tweag.io/posts/2017-03-13-linear-types.html

Rust uses affine types instead of linear types per some statements I've seen on the subject. I wonder why they wouldn't use affine types in this. Either way, it's good they're adding it.

Re: Rust as a gateway drug to Haskell

#128

Post by saosebastiao »

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.

Cache locality will never beat algorithmic complexity as a performance factor. Don't exaggerate its importance.

Re: Rust as a gateway drug to Haskell

#129

Post by vmchale »

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.

>It was very frustrating to try reasoning about performance in Haskell due to its laziness.

Conversely, I find it hard to achieve the same performance with strict code. I think it's likely a matter of familiarity.

>Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

The standard prelude is flawed in many ways. Haskell 2020 will hopefully fix this. In the meantime: the recursion-schemes library might be of great use.

Re: Rust as a gateway drug to Haskell

#130

Post by vmchale »

delhanty wrote: post #5
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.

>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. +1 One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production. It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but sti…

>GHC honcho Simon-Peyton Jones saying the next Haskell will be strict,

I think all he meant that strictness was an interesting paradigm that would differentiate a language enough to justify its existence alongside Haskell.

>Following on and presumably related to that PureScript is strict

Partly also to distinguish from GHCJS. Laziness in a strict language is really hard and PureScript generates semi-readable JavaScript.

Post reply on HN