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

111–120 of 189 posts

Re: Rust vs. Haskell

#111

Post by klntsky »

anon291 wrote: post #78
surement wrote: post #64

Earlier quoted context omitted.

> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

You don't need to know that to write haskell Effect systems and monad transformers are advanced topics. They're possible to use in my language yet most people do not and can still write software. Certainly no need for them in Haskell to be successful. You can just program at the lower levels of abstraction common in other languages. The only difference is that Haskell's community tends to emphasize abstraction

There's no way to even get a job without understanding monad transformers.

Re: Rust vs. Haskell

#112

Post by noloblo »

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.

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

Re: Rust vs. Haskell

#113

Post by OJFord »

Martinsos wrote: post #55
29athrowaway wrote: post #40

"What do you use Haskell for?" Most important question about Haskell

I know it is common to think that Haskell is used only in academia and side/weird-projects, but there is a decent amount of companies using Haskell - e.g. we use Haskell in production for developing a DSL / web framework for building web apps ( https://github.com/wasp-lang/wasp )! I participated teaching students Haskell on my alma mater this year and "what can Haskell be used for" was a common question, with genuine…

> The biggest factor for deciding if Haskell is a good fit for the problem is probably ecosystem support

And hiring right, or being prepared to train/let new hires climb up a steeper learning curve than hiring someone with Python experience for a Ruby app say.

Rust has reached that critical mass I think, got past the chicken/egg issue of experienced people to hire & companies interested in hiring them (to work on a rust codebase). Against the odds I think, there are plenty of languages you hear about similarly up and coming that haven't (D, Zig) or have only in a niche (F#, Swift, Kotlin - the last two I include mainly because I'm thinking Go could so easily have gone the same way, just been the one Google pushed for K8s plugins and GAE applications, not used generally as it is despite being a general-purpose language).

Re: Rust vs. Haskell

#114

Post by zozbot234 »

Hirrolot wrote: post #106

One important thing Rust and Haskell have in similar is the nearly complete absence of an endeavour to unify things. As more fancy type system features get added, both languages become quite complex, thus increasing the learning curve and compiler complexity. This is quite aptly expressed by the recent paper on dependent types [1]: > Previous versions of Haskell, based on System Fω , had a simple kind system with a f…

> currently it's not quite clear what's the best way to integrate dependent types with systems programming.

Dependent types dispense with the phase separation between compile-time and run-time code, which is inherent to system languages. So you can easily have dependent types in a systems language as part of compile-time evaluation, but not really as a general feature. It would work quite similar to the "program extraction" feature in current dependent-language implementations, which does enable improved type checking because you can express arbitrary proofs and check them reliably as part of compilation.

Re: Rust vs. Haskell

#115

Post by kzrdude »

ghostwriter wrote: post #53
kzrdude wrote: post #43

Earlier quoted context omitted.

You should look at what you can do with the Rust type inference too, it's not too far away from Haskell, at least not superficially. For example using the return type to deduce type parameters for a method like let samples: Vec = iterator.collect();

But this is the most trivial example of inference. Rust has neither generic implementation of higher kinded data nor global inference for the existing specific cases of it like GAT.

Is it the most trivial? C++ doesn't support it, and it has type inference using `auto`.

Note that in my example the type information flows from the variable to picking which generic method that is called, which is reversed information flow of what I would call the most trivial case - when the variable gets its type from the method that was called. (This is trivial: let x = 1i32;)

Re: Rust vs. Haskell

#116

Post by jeremyjh »

ghostwriter wrote: post #103
jeremyjh wrote: post #99

Earlier quoted context omitted.

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.

I get this point and I agree with it, but I also object to your comment on having to use transformers as otherwise it's not worthy. My objection has to do with seemingly different standards and expectations applied to levels of users of mainstream languages. In my opinion they should be the same, even if Haskell allows for safer and better results with transformers: they are not universally required and expected to b…

If you aren't going to learn to write Haskell in the spirit of Haskell why learn it at all? Learning a language also involves learning the communities norms and accepted practices.

Re: Rust vs. Haskell

#117

Post by chongli »

burntsushi wrote: post #109
chongli wrote: post #102

Earlier quoted context omitted.

Wait, they got rid of proc closures? Hahaha. Shows how long it’s been since I last looked at Rust. Okay, now they do look quite natural!

Indeed. My (and by no means am I the only one) mental model of closures is really simple. A closure is a struct with no name, and the free variables of the closure are fields in the struct. If the closure is annotated with 'move', then those fields are owned, otherwise the fields are borrowed and the lifetime parameter on the struct is the shortest of the bunch. Then, calling the closure is just calling it with 'self…

That’s really nice. One of my favourite uses for returning closures is to separate a function into ‘configuration’ and ‘execution’ stages. It becomes extremely useful when you have a ton of parameters but only a few change between typical invocations.

Re: Rust vs. Haskell

#118

Post by jeremyjh »

noloblo wrote: post #112
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.

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 monad it has no access to the State monad and can't call those methods. There are ways to work around that but monad transformers give you a StateT which can be applied to any base monad, including IO, giving you the capability of both.

Re: Rust vs. Haskell

#119

Post by Hirrolot »

burntsushi wrote: post #107
Hirrolot wrote: post #97

Earlier quoted context omitted.

Closures in Rust are fundamentally broken. See [1] for the discussion. [1] https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...

Lol. "fundamentally broken" and yet I've been using them with little to no friction for pretty close to a decade now. If that's what you think "broken" means, then, well, you've completely devalued the word. This right here is what we call sensationalism folks. Now if you said, "Rust has some rough points at the intersection of generics, closures and async programming," I'd say that's absolutely true!

> "fundamentally broken" and yet I've been using them with little to no friction for pretty close to a decade now.

This might rather confirm my point, since engineers using a specific programming language quite often have a contorted picture of how code in other languages is written, as they become more and more acquainted with their main tool. If we compare Rust closures with those of ML languages, it becomes pretty clear how natural closures are in ML and tricky in Rust.

Not quite a sensation either to anybody who happened to use closures in a typical Rust code, which, apparently, happens to have quite a lot of generics and async!

Re: Rust vs. Haskell

#120

Post by Hirrolot »

burntsushi wrote: post #109
chongli wrote: post #102

Earlier quoted context omitted.

Wait, they got rid of proc closures? Hahaha. Shows how long it’s been since I last looked at Rust. Okay, now they do look quite natural!

Indeed. My (and by no means am I the only one) mental model of closures is really simple. A closure is a struct with no name, and the free variables of the closure are fields in the struct. If the closure is annotated with 'move', then those fields are owned, otherwise the fields are borrowed and the lifetime parameter on the struct is the shortest of the bunch. Then, calling the closure is just calling it with 'self…

Your example indeed perfectly demonstrates the subtlety of closures in Rust. Now let's imagine I want to return a nested closure, e.g., `impl Fn(i32) -> impl Fn(i32) -> i32`, or something like that:

    fn adder(x: i32) -> impl Fn(i32) -> impl Fn(i32) -> i32 {
        move |y| move |z| y + x + z
    }
Alright, I can't. I can do that for a single closure, but can't for two or more of them. Here's why we have `#![feature(impl_trait_in_fn_trait_return)]` -- in Nightly, among many other such features.
Post reply on HN