Hacker News Reader

Comment by massysett | Hacker News Reader

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++?

View on HN

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).

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())

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.

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.

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.

> Yes, the next Haskell will be strict; that's generally although not universally accepted.

The essence of Haskell is non-strictness. It is the very reason Haskell was created.

There are already strict functional languages, like OCaml. What value comes from stripping Haskell of the soul of its existence?

Rust was absolutely intended for systems programming from the start, it’s just that the “you can drop the GC but still have memory safety” bit wasn’t there at the beginning. Safe systems programming was the goal from the beginning.

http://venge.net/graydon/talks/intro-talk-2.pdf

I am aware. My post was about Rust not originally being intended for much of the non-concurrent and performance-agnostic application programming it is currently being used for (e.g. the enormous amount of CLI utilities cropping up). Its popularity in this domain is due to qualities that were not part of (or at least orthogonal to) the original vision.

Ah, I see, my bad. I misunderstood. (I think part of it is also like, what even is "systems" is confusing; I think many folks would think of those CLI apps as being bread and butter systems stuff, but you can slice it both ways really.)

Hopefully someone finds the presentation interesting if they haven't seen it before :)

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.

Haskell developers want Haskell to be fast and safe. Rust is fast and safe.

Reply on news.ycombinator.com