5 ms·

As a language, I think it was always good. Haskell is my main working language, so I tend to mostly see the warts, but whenever I have to use another language

by Athas 4y ago

As a language, I think it was always good. Haskell is my main working language, so I tend to mostly see the warts, but whenever I have to use another language I end up feeling very constricted. Haskell does have some very real warts, but I would say that for example the current state of the tooling is only bad when compared to the very best (e.g. cargo is arguably better than cabal, but cabal is better than what a lot of other languages have). I'm uncertain about Haskell ever becoming very popular. Rust seems to be sucking a lot of oxygen out of the room for new application programming languages, and Haskell is so old that I'd expect it to already be popular if it were ever going to become popular on its own merits. This doesn't matter much to me. There is enough manpower in the community to maintain the tooling and infrastructure, which keeps improving, and the language is fundamentally very very good. I originally learned Haskell from the book Real World Haskell. It's probably dated now (the language and libraries have changed), but I would certainly welcome an updated second edition.

runevault 4y ago
Yeah Haskell always seemed interesting, I just never got my head around it on the couple attempts I made. Mostly surprised because languages as old as Haskell rarely see potential at another surge in popularity when they have been around this long unless something (library/framework/etc) comes along and makes people reevaluate them.
massysett 4y ago
Putting Rust and Haskell in the same category always puzzles me a bit: I’d think Rust is more in the same category as C++?
- Athas 4y ago
  Yes, Rust as a language wasn't originally intended for much of what it's used for now. Many of the applications written in Rust would probably be fine without the borrow checker, and instead paying a performance overhead to have GC. I think Rust is succeeding on the strength of its tooling and the overall relative modernity of the language (e.g. proper sum types and sane metaprogramming). Of course, Haskell has these things too, although some of the incarnations may be a bit more crufty (Rust macros seem a lot more accepted than Template Haskell does).
  - runevault 4y ago
    One thing that can really mess with people as well is how much of Haskell is (or was last I played with it) lazy by default. Some things like infinite lists where you only take a subset obviously have to be lazy, but in other cases the way it messed with memory usage could be incredibly confusing. I wonder if a less lazy by default version of Haskell might have had any more success in the wider world. I know in the .NET world I've been burned more than a few times by the way Linq is lazy unless expressly realized (via methods like ToArray() and ToList())
    - Athas 4y ago
      Yes, the next Haskell will be strict; that's generally although not universally accepted. I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated). Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation. These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.
      - runevault 4y ago
        Perhaps there could exist a middle ground for cases where it does not risk significant "random" memory bloat and similar issues. I 100% think there are edge cases where laziness has value. Although in your fromMaybe case couldn't you just have it generate short circuiting code under the hood instead of always evaluating? That isn't necessarily quite the same thing as laziness.
        mibsl 4y ago
        Short circuiting is a special case of laziness. It's local only, so no thunks are required. The beauty of functions like fromMaybe is they're only that - just plain, regular functions. No special casing under the hood required.
- saghm 4y ago
  I agree that the lower-level details of Rust and the original vision for it was not super close to Haskell, but having said that, I think it often attracts a lot of the same people. Rust traits are very similar to Haskell's typeclasses, and stuff like the Iterator API and the fact that mutability is a first-class concept in the language (and therefore easy to keep track of if you want to avoid it) make it pretty well-suited to functional programming. Add that to the fact that developer productivity is valued pretty highly, which is why there's such a focus on good tooling e.g. cargo, compiler errors, and you end up with a language that does a surprisingly good impression of "Haskell but more user friendly". There's a bunch of other stuff too, like the ability to "drop down" into imperative programming, and the fact that you can use references and stuff to avoid allocations, but if you want to just take everything by value and clone everything without using `Arc` or `Rc` and go pure functional, Rust isn't going to get much in your way.
- HKH2 4y ago
  Haskell developers want Haskell to be fast and safe. Rust is fast and safe.

by Athas 4y ago

runevault 4y ago

Yeah Haskell always seemed interesting, I just never got my head around it on the couple attempts I made. Mostly surprised because languages as old as Haskell rarely see potential at another surge in popularity when they have been around this long unless something (library/framework/etc) comes along and makes people reevaluate them.

massysett 4y ago

Putting Rust and Haskell in the same category always puzzles me a bit: I’d think Rust is more in the same category as C++?

Athas 4y ago
Yes, Rust as a language wasn't originally intended for much of what it's used for now. Many of the applications written in Rust would probably be fine without the borrow checker, and instead paying a performance overhead to have GC. I think Rust is succeeding on the strength of its tooling and the overall relative modernity of the language (e.g. proper sum types and sane metaprogramming). Of course, Haskell has these things too, although some of the incarnations may be a bit more crufty (Rust macros seem a lot more accepted than Template Haskell does).
- runevault 4y ago
  One thing that can really mess with people as well is how much of Haskell is (or was last I played with it) lazy by default. Some things like infinite lists where you only take a subset obviously have to be lazy, but in other cases the way it messed with memory usage could be incredibly confusing. I wonder if a less lazy by default version of Haskell might have had any more success in the wider world. I know in the .NET world I've been burned more than a few times by the way Linq is lazy unless expressly realized (via methods like ToArray() and ToList())
  - Athas 4y ago
    Yes, the next Haskell will be strict; that's generally although not universally accepted. I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated). Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation. These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.
    - runevault 4y ago
      Perhaps there could exist a middle ground for cases where it does not risk significant "random" memory bloat and similar issues. I 100% think there are edge cases where laziness has value. Although in your fromMaybe case couldn't you just have it generate short circuiting code under the hood instead of always evaluating? That isn't necessarily quite the same thing as laziness.
      - mibsl 4y ago
        Short circuiting is a special case of laziness. It's local only, so no thunks are required. The beauty of functions like fromMaybe is they're only that - just plain, regular functions. No special casing under the hood required.
saghm 4y ago
I agree that the lower-level details of Rust and the original vision for it was not super close to Haskell, but having said that, I think it often attracts a lot of the same people. Rust traits are very similar to Haskell's typeclasses, and stuff like the Iterator API and the fact that mutability is a first-class concept in the language (and therefore easy to keep track of if you want to avoid it) make it pretty well-suited to functional programming. Add that to the fact that developer productivity is valued pretty highly, which is why there's such a focus on good tooling e.g. cargo, compiler errors, and you end up with a language that does a surprisingly good impression of "Haskell but more user friendly". There's a bunch of other stuff too, like the ability to "drop down" into imperative programming, and the fact that you can use references and stuff to avoid allocations, but if you want to just take everything by value and clone everything without using `Arc` or `Rc` and go pure functional, Rust isn't going to get much in your way.
HKH2 4y ago
Haskell developers want Haskell to be fast and safe. Rust is fast and safe.