Hacker News Reader

Comment by msla | Hacker News Reader

>> The problem you're having is only a problem because you haven't tried hard enough.

And it actually does work that way with Haskell, in my experience. There's a big hill to get over where you flail against the type system, IO monad and all, and then you realize that, while Haskell's type system isn't perfect, being able to say

    Num t => (t -> b) -> [t] -> [b]

is really pretty powerful, and being able to search for functions by type signature is just plain convenient.

But Haskell isn't for every problem in the way Rust is apparently made out to be. For example, I've seen some posts about developing games in Haskell, but it isn't common, and nobody would try to push a game developer into using Haskell.

View on HN

> being able to search for functions by type signature is just plain convenient.

It's certainly not all the way there, but now that we are over the mostly empty promises of encapsulation and (worse) trying to model the world with classes, but grouping by that implicit first argument type for discoverability is exactly what OOP is, in this age of post-OOP.

The "you're not trying hard enough" position reminds me a lot of the Scala community's disdain for java-in-scala-syntax: if you don't use it like an almost-Haskell you're on your own (1). Here, I think Rust is actually more open: I don't read too much of the community, but most of what I saw seemed to be quite welcoming to the idea of placating the borrow checker with refcounting when "the rust way" fails to sufficiently click.

((1) but with Kotlin having taken over the entire not-almost-Haskell part of scala it's not an issue anymore: is has its niche and it fills it well, no more taking over the entire JVM while also magically converting everybody into an almost-Haskellian)

Maybe https://dev.epicgames.com/documentation/en-us/uefn/verse-lan... is as close as we're going to get to game dev Haskell.

Agree. Some languages like Haskell have a steep learning curve, until you grok it. Then you have a big productivity gain.

But this article is seeming about someone that has put in the time, has written a lot of Rust, and now says, it wasn't really worth it.

What does this after do with the topic?

I'm comparing one unusual language (Rust) with another language (Haskell) and examining why the first gets push-back whereas the second gets more positive mentions.

They both have a single odd idea that's hard to wrap your head around at first, Rust's borrow checker and Haskell's type system with its enforced immutability by default, and which intentionally drives program design, in that both languages demand you write your program such that the static analysis can prove it's valid, but Rust's borrow checker seems to get more people throwing their hands up and leaving the language than Haskell's type system does.

Haskell's type system can be a bit inexpressive, sometimes, too, and there are language extensions which address some of this, but it seems to hit more of a sweet spot where, in most programs, if the type system is forbidding something, you really do have some kind of error in your thinking leading to inconsistent code. Plus, it enables design instead of just forbidding, because you know that any function which is valid in the type system is at least sensical to use in a given context.

Reply on news.ycombinator.com