4 ms·
> If so, do you think a comment here in HN is going to convince you of picking language X over Y? Yes. Because I'm a highly fallible person and very open to th
by spekcular 5y ago
> If so, do you think a comment here in HN is going to convince you of picking language X over Y?
Yes. Because I'm a highly fallible person and very open to the idea that a Haskell expert might be able to point out a good use case that I missed.
> Realistically, which kind of answer do you expect? A summary of the "Why Haskell" and "Why Rust" pages? I'm sure they exist and you could take a look at them and decide.
The selling point of Rust is (very, very) roughly "C++ without the bad parts, and some more good parts." Given the demonstrated utility of C++ (and demonstrated pitfalls) this is manifestly appealing. Avoiding memory safety related security holes alone is huge.
That's an example of the kind of answer I expect.
- the_af 5y ago> a Haskell expert I'm not a Haskell expert, I just dabbled with it and liked it. > The selling point of Rust is (very, very) roughly "C++ without the bad parts, and some more good parts." Given the demonstrated utility of C++ (and demonstrated pitfalls) this is manifestly appealing. Avoiding memory safety related security holes alone is huge. The selling point of Haskell is that it's a Functional Programming first language (see: "Why Functional Programming Matters"), has a better statically type system than C/C++/Java which makes whole classes of bugs common in those languages harder to write in Haskell (so if writing correct code is a priority, that's your use case), and memory safety related security holes are harder to write, just like with Rust. Laziness (or non-strictness, whatever) is also a big if controversial selling point (why: read "Why Functional Programming Matters"). If you like slightly less opinionated (or non-strict by default) languages, you could go with OCaml or Standard ML instead. Why would you prefer Rust? Why don't you ask a Rust advocate?
- spekcular 5y agoRust has better tooling, more direct control in performance-sensitive contexts (no opaque performance traps like, arguably, Haskell), and more community/industry support (meaning more useful and high quality packages). So from the perspective of practically solving problems, it seems better to me. But I could be convinced otherwise by a good argument.