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

91–100 of 189 posts

Re: Rust vs. Haskell

#91

Post by jeremyjh »

weavie wrote: post #76
jeremyjh wrote: post #70

Earlier quoted context omitted.

I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.

I would say using them is beginner->intermediate. Writing them is intermediate->advanced.

I'd agree in general and almost made this same point but it depends on what you are doing. If you write a transformer that is essentially just a specific kind of Reader (like ResourceT), then you can just follow existing examples and not really have to understand how to write all the instances yourself.

Re: Rust vs. Haskell

#92

Post by mayoff »

ghostwriter wrote: post #74
jeremyjh wrote: post #70

Earlier quoted context omitted.

I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.

> Its not impossible to do serious work without them but I'm not sure its worth doing. How do you think the folks on Java and C# find their work worth doing on their end in that case?

Java code is always in the IO and Except monads.

Re: Rust vs. Haskell

#93

Post by bryanlarsen »

nicoburns wrote: post #52
bryanlarsen wrote: post #35

Earlier quoted context omitted.

pub functions: should be explicit module functions: if I chose, I'd let them be derived, but I'm relatively indifferent inner functions: should be allowed to be derived, IMO. They're very infrequently used so this choice doesn't have much impact.

You can use closures as functions with type inferred signatures

Closures capture variables so have significant differences compared to inner functions. Capture can affect lifetimes so the difference is significant in Rust.

Re: Rust vs. Haskell

#94

Post by anon291 »

masklinn wrote: post #83
rom-antics wrote: post #45

Earlier quoted context omitted.

"Worthless" is a bit strong. The Rust devs want to add TCO/TCE, but there are still problems left to solve. The "become" keyword is already reserved in anticipation of guaranteed tail calls being added. https://github.com/rust-lang/rfcs/issues/2691

> "Worthless" is a bit strong. No, TCO is worthless, it’s an unreliable optimisation.

If given explicit support in a language then no it's not. Especially with the keyword approach rust is taking, the compiler will guarantee the semantics.

Do you believe the exec system call is similarly unreliable at replacing your process image? Amazing that unix systems work at all

Re: Rust vs. Haskell

#95

Post by ghostwriter »

jeremyjh wrote: post #84
ghostwriter wrote: post #74

Earlier quoted context omitted.

> Its not impossible to do serious work without them but I'm not sure its worth doing. How do you think the folks on Java and C# find their work worth doing on their end in that case?

Because they aren't using Haskell? Haskell more or less creates all the problems that transformers solve.

Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?

Re: Rust vs. Haskell

#97

Post by Hirrolot »

burntsushi wrote: post #71
marcosdumay wrote: post #57

Earlier quoted context omitted.

There is nothing "natural" about working with Rust closures. If you want to take a losing fight against the borrow checker, they are the best way to do it. (Rust has your C-like run of the mill function references too. People should emphasize those more, because differently from closures, those work very well.)

Closures work very well in Rust and are a core aspect of the standard library. The 'Iterator' trait adapters, for example, make very heavy use of closures, as do the combinators on 'Option' and 'Result'. Closures are also how you spawn threads. They are absolutely ubiquitous and quite natural. In contrast, function pointers are very rarely used. Are they equivalently nice in every way to closures in Haskell? Of cours…

Closures in Rust are fundamentally broken. See [1] for the discussion.

[1] https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...

Re: Rust vs. Haskell

#98

Post by debuggerpk »

marcosdumay wrote: post #57
zozbot234 wrote: post #37

Earlier quoted context omitted.

Rust has closures and does not use a GC. The borrow checker just makes sure that a closure never outlives its captures or any of its references. The most prominent difference between Rust and Haskell is that Haskell uses lazy evaluation throughout; it's the language's unique selling point. Rust doesn't even have generators in the stable variety of the language yet, although they are internally used to implement async…

There is nothing "natural" about working with Rust closures. If you want to take a losing fight against the borrow checker, they are the best way to do it. (Rust has your C-like run of the mill function references too. People should emphasize those more, because differently from closures, those work very well.)

this comment made my day.

Re: Rust vs. Haskell

#99

Post by jeremyjh »

ghostwriter wrote: post #95
jeremyjh wrote: post #84

Earlier quoted context omitted.

Because they aren't using Haskell? Haskell more or less creates all the problems that transformers solve.

Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?

I'm not making any points about users of mainstream languages. They have no use for transformers. Using a lot of global IORefs is possible but relies on a trick using unsafePerformIO; its definitely not in the spirit of Haskell to work this way though it is sometimes needed.

Re: Rust vs. Haskell

#100

Post by thethimble »

thedataangel wrote: post #13
vlovich123 wrote: post #8

> if we have a map and want to do some operation on a slightly modified map, we can have a value that keeps the old map but also works with the new map (without much performance cost). What black magic is this? Is the article just glossing over the cost of a copy or does Haskell do something weird here to avoid the copy while retaining both versions?

The second. Because everything in Haskell is immutable, it can take a _lot_ of liberties in terms of letting structures share parts of one another, in the case where one version is derived from the other. Conversely, in the case where something like a list is modified in entirety (e.g. with a `map` function), if the compiler can determine that the original is no longer needed, it can run the map operation in place -…

The immutability guarantees let you build some really powerful constructs. Check out the world of immutable/functional data structures: https://en.wikipedia.org/wiki/Purely_functional_data_structu...
Post reply on HN