A recentish /r/haskell discussion[1] had some brief thoughts.
[1] https://old.reddit.com/r/haskell/comments/zk2u6k/what_do_has...
Rust vs. Haskell
161–170 of 189 posts
Re: Rust vs. Haskell
#162Another recent article that compared the expressiveness of several languages for a particular project including Rust and Haskell[0] as well as C++, Python, Scala and OCaml. That comparison was for a complex task undertaken by adept users of each language. The variance was within a +/- factor of 2 with an exception of one team which made choices that led to much more typing.
Re: Rust vs. Haskell
#163Earlier quoted context omitted.
It is saying a lot because no other language offers that combination of performance and high level abstraction. The speed of C++ with high level language features of haskell. And none of the safety pitfalls of C++ either. That's a lot. When compared with haskell the benefits aren't clear. When compared with C++, rust is clearly better when viewed from strictly a language standpoint.
But C++ is an outlier in systems software. Systemd is written in C. Grub is written in C. The Linux kernel is written in C. Firmware is written in C. Sure there are some kernels that use a bit of C++, but it's an outlier, not the norm. C++ never proved the is was so worthwhile to have a higher level language that we should drop everything and write C++. C++ only dominates in performance critical applications where th…
No C++ is considered systems software. I largely agree with you, except on the fact that C++ is an outlier in systems software. It's only an outlier for GNU linux.
Re: Rust vs. Haskell
#164About Haskell's function type annotations: "But it usually results in a warning, and adding a type signature is a good practice." I prefer Rust's way of doing this. When you're a beginner it ensures that you're passing and returning the proper type to and from the function, you kind of have the function as a guard which ensures that you're using the correct types.
Rust only half-asses this though. Lifetime annotations are part of the type of the function but can be elided if unambiguous. For beginners and generally people who read code that's confusing. I don't think there's anything to be gained by writing a few less characters and editors can easily add them as well.
Is 4 ‘a, ‘b, etc. really more readable?
Re: Rust vs. Haskell
#165Earlier quoted context omitted.
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;)
I think they meant trivial in comparison to Haskell's type inference, which you had started off comparing against, not C++.
Re: Rust vs. Haskell
#166Earlier quoted context omitted.
Compiler optimizations are best-effort. -O3 gets you 90% of the optimization for 10% of the work of writing hand-rolled assembly. Individual optimizations are not guaranteed, and sometimes even regress in newer compiler versions, but everyone uses them because overall programs run much faster with optimizations than without. I don't see how TCO is any different. Would you say all optimizations are worthless because t…
> Would you say all optimizations are worthless because they're not guaranteed? Context is relevant, the context here is language semantics, not things going faster. TCO is fine to make things go faster, like inlining, unrolling, LICM, .... TCO is hot garbage when you rely on it for program correctness.
Weird how none of that context was present in your first two iterations of the claim.
Re: Rust vs. Haskell
#167Earlier quoted context omitted.
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 mon…
Wel IO is State, cf. https://hackage.haskell.org/package/transformers-0.6.1.0/doc...
You set up your pipeline in terms of monads and then when you want to execute it you run it in IO. You can generalize IO to MonadIO or define an alias to some transformer pinned at IO. It adds a Computational overhead. Transformers are a solution to monad composition which isn’t naturally possible.
Re: Rust vs. Haskell
#168Earlier 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
None. Transformers are a solution to the composability of monads.
Re: Rust vs. Haskell
#169Earlier quoted context omitted.
If essentially everyone uses it to mean one thing, that's what it means now. That's how definitions work.
Does that apply to “Hacker” in Hacker News?
Sure. Language is contextual. If you find yourself explaining why hacker isn't really hacker to the people that you talk to _about_ hacker news, then yes it is actually impeding communication
Re: Rust vs. Haskell
#170Earlier quoted context omitted.
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;)
> For example using the return type to deduce type parameters for a method like let samples: Vec = iterator.collect();
> C++ doesn't support it
How exactly is it different?
#include
#include
int main() {
std::vector v1 = {1,2,3};
auto it = v1.begin();
std::vector v2 (it + 1, it + 2);
for (auto i: v2) { std::cout