Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust vs. Haskell

serokell.io

Post reply on HN
Print view View original

181–189 of 189 posts

Re: Rust vs. Haskell

#181

Post by jeremyjh »

jmaker wrote: post #167
jeremyjh wrote: post #118

Earlier quoted context omitted.

The main problems are immutability and inability perform I/O outside the IO monad. To address immutability you have Monads like Reader, Writer, State which can give you a similar experience that you would have with mutable data and/or global variables. For example with the state monad you can have code like: runState do value The problem comes when you also want to do IO with that state; if your code is in the IO mon…

Wel IO is State, cf. https://hackage.haskell.org/package/transformers-0.6.1.0/doc... You set up your pipeline in terms of monads and then when you want to execute it you run it in IO. You can generalize IO to MonadIO or define an alias to some transformer pinned at IO. It adds a Computational overhead. Transformers are a solution to monad composition which isn’t naturally possible.

Yes and they are essential to working in serious, modern Haskell. You could never be an intermediate without know how to use them.

Re: Rust vs. Haskell

#182

Post by Ericson2314 »

ilovecaching wrote: post #66
Ericson2314 wrote: post #58

Earlier quoted context omitted.

I've helped write some very abstract combinator-y Rust that compiled down to an embedded program that runs with only 4K RAM. Get over it. > and what logical assembly I'll be generating The problem with Rust and C is not worrying about what assembly I'll get, it is that one has very little control over the layout of the stack. It's the last implicit data structure and that's a PITA for highly resource constrained prog…

With all due respect, writing one program with a small memory footprint doesn't disprove my point. I'm referring to writing very large, complex programs that interact directly with hardware - kernels, boot loaders, firmware, all of which must be as clear as possible. And I say this with many years of experience dealing with other companies badly written device drivers and firmware. I absolutely need to worry about wh…

> I'm referring to writing very large, complex programs

Then the power of good abstractions should be all the more useful!

> that interact directly with hardware

OK if you are using various privileged instructions, writing things with weird calling conventions like interrupt handlers, etc. Then the assembly matters.

But, and this may sound heretical, this stuff is the boundary of the lower level code; its interface with the hardware. For the interior, the precise assembly once again doesn't matter.

> And I say this with many years of experience dealing with other companies badly written device drivers and firmware.

There is a lot of crap low level code out there, yes. And I would say a chief mistake of crap code is not properly respecting layers of abstraction. The low level world needs more http://langsec.org/ where we precisely and mechanistically document the interface, rather than half-assing it with reference implementations.

Just as user space weird instructions get intrinsics exposed to spare the user from writing inline assembly, libraries like https://docs.rs/x86/latest/x86/ should be maintained the device manufacturer or ISA consortium. They should be unit-tested with an emulator too.

We properly do all this legwork to fix the foundation, and the rest of the low-level software will practical write itself, compared to today, and be accessible to a much larger pool of programmers.

Re: Rust vs. Haskell

#183

Post by nextaccountic »

armchairhacker wrote: post #6

This article paints Rust and Haskell as very similar languages, but when I saw the title I was thinking about how they are fundamentally different. Rust is technical and exposes/requires you to understand the reality of computation, while Haskell hides it away and lets you program in a system based on lambda-calculus (you don't even have strict order of evaluation!) Interesting to see that they are very similar regar…

> you don't even have strict order of evaluation

You do, with `seq`. And a lot of Haskell programming in practice is deciding between lazy vs strict programming.

The only lazy feature commonly used by Rust programmers are iterators, but they are just lazy lists (that are immediately discarded after being forced)

Re: Rust vs. Haskell

#184

Post by jnordwick »

kilgnad wrote: post #51
tgv wrote: post #36

Earlier quoted context omitted.

IMO, that's too superficial to compare them. So what if both have a bunch of similar looking constructs? Rust is imperative, and sequential, and nearly everything is mutable, hence the borrow checker. That makes programming in Rust rather different.

Rust is immutable by default. You have to deliberately opt in for mutability. When you don't opt in to mutability the programming styles are very similar at a basic level. First the type system is very similar with the capability of building sum and product types with recursive values. Second pattern matching over sum types is also very very similar. Rust is like the bastard child of C++ and haskell.

Rust's new claim is now that references isn't immutable, it's shared by default. There is no concept of immutable data in rust. All data is mutable in various ways and that is a product of the binding not the data, from the cell interior mutability eupphamisn to shadowing in the same frame: (`let x = 2; let x += y;` is valid even though x isn't defined as mutable. The mental gymnastics a rust parishioner has to go thrown to shout down other languages while theirs fills with the same concepts is growing by the hour.

Re: Rust vs. Haskell

#185

Post by sbergot »

ColonelPhantom wrote: post #75
sbergot wrote: post #39

Earlier quoted context omitted.

The price for immutability is pretty high. Haskell garbage collection has a lot of work to do. When you say 'algorithms would look better' this is pretty subjective. Graph based algorithms or inplace algorithms doesn't look too good in haskell.

In-place maybe not, but what language would be more suitable for graph based algorithms? Of course it depends on how you represent the graph, but writing something like breadth-first search is quite nice and easy to implement in Haskell, in my experience.

This is maybe just me but I find any kind of self referenced data structure a bit awkward to define in haskell. The thing mentioned in http://wiki.haskell.org/Tying_the_Knot .

Re: Rust vs. Haskell

#186

Post by ploppyploppy »

mananaysiempre wrote: post #153
thedataangel wrote: post #9

Earlier quoted context omitted.

Quite a few of Rust's features were borrowed from or inspired by ones in Haskell - albeit often modified to be more suitable for systems programming (and systems programmers!). Most Haskellers I know are quite fond of Rust :)

I am (or used to be) a Haskeller, and I just can’t get over how spectacularly ugly Rust’s syntax looks compared to Haskell or SML and finally force myself to learn it. Call me shallow, but it’s true.

I share this opinion. Haskell was my hobby language for 2 years until Rust. I still miss the brevity of Haskell and point-free style in particular.

Re: Rust vs. Haskell

#187

Post by ColonelPhantom »

sbergot wrote: post #185
ColonelPhantom wrote: post #75

Earlier quoted context omitted.

In-place maybe not, but what language would be more suitable for graph based algorithms? Of course it depends on how you represent the graph, but writing something like breadth-first search is quite nice and easy to implement in Haskell, in my experience.

This is maybe just me but I find any kind of self referenced data structure a bit awkward to define in haskell. The thing mentioned in http://wiki.haskell.org/Tying_the_Knot .

I generally express graphs as a `Map k (Set k)` or similar, with extra data as desired. Using keys and lookups means you don't need self-references. I guess in a way this approach sacrifices some purity, but I find it works very well.

Re: Rust vs. Haskell

#188

Post by noloblo »

jeremyjh wrote: post #181
jmaker wrote: post #167

Earlier quoted context omitted.

Wel IO is State, cf. https://hackage.haskell.org/package/transformers-0.6.1.0/doc... You set up your pipeline in terms of monads and then when you want to execute it you run it in IO. You can generalize IO to MonadIO or define an alias to some transformer pinned at IO. It adds a Computational overhead. Transformers are a solution to monad composition which isn’t naturally possible.

Yes and they are essential to working in serious, modern Haskell. You could never be an intermediate without know how to use them.

Would it be possible to give an example of monad composition that shows both state and Io on one computation unit?

Re: Rust vs. Haskell

#189

Post by noloblo »

jeremyjh wrote: post #118
noloblo wrote: post #112

Earlier quoted context omitted.

What problems does haskell create How do Monad transformers solve it @jeremyjh

The main problems are immutability and inability perform I/O outside the IO monad. To address immutability you have Monads like Reader, Writer, State which can give you a similar experience that you would have with mutable data and/or global variables. For example with the state monad you can have code like: runState do value The problem comes when you also want to do IO with that state; if your code is in the IO mon…

Is there an example of StateT applied to IO? That's not too complex for python#++ devs?
Post reply on HN