Live data from Hacker News

Rust as a gateway drug to Haskell

xion.io

31–40 of 218 posts

Re: Rust as a gateway drug to Haskell

#31

The similarities are striking. Both have a problem with undocumented or experimental modules for everyday tasks, both use compiler plugins to make sure that every package is using its own superset of the language (although in Rust this only applies to nightly), both tout lofty goals while rarely producing production grade systems. Rust is the first toe dip into the world of blog posts heralding the"coming of the age…

Although clearly presented to push some buttons, it isn't completely wrong.

Am upvote hoping you don't get buried.

Re: Rust as a gateway drug to Haskell

#32
post #7

> More advanced type systems, however, allow to specify the generic constraints explicitly. Well, Java allows it, even if it looks a bit unglier than the Rust example. > T min (T a, T b) { if (a.compareTo(b) > 0) { return b; } else { return a; } } And even without general availability of concepts (already in gcc 6.x), one can achieve it in C++ via if constrexpr .

The difference with Rust is that you can apply a trait to an extant type you don't "own" - you can't do that in Java or C#: you would need to use the decorator-pattern (boilerplate ahoy!). C++'s checks are closer to duck-typing in practice.

I agree with you in regard to Java and C#, not so much regarding C++, because GCC already supports concepts since version 6.0, with other compilers adding support for them as part of the validation work to have them finally on ANSI C++20 standard.

In any case, regardless of the fine grain details, all of them allow for to "specify the generic constraints explicitly.".

Re: Rust as a gateway drug to Haskell

#35
post #29

Earlier quoted context omitted.

> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2]. The following is just my vague, uninfor…

The benchmarks game falls squarely under the umbrella of "short, simple programs", not the sort of real-world stuff where you would benefit from having a language that scales well. That said, Haskell performs pretty well in the toy benchmarks anyway. Your comparison between Haskell and Go is about market size, not language design. I suspect you would have a similarly hard time finding Rust devs as Haskell devs (i.e.…

> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C.

I don't mean to be personal, but your quantative claim smells a little like unsubstantiated BS. Do you have any data to back it up?

> That said, Haskell performs pretty well in the toy benchmarks anyway.

Currently, "pretty well" looks like GHC performance is 50% to 10% of hand-crafted C using perhaps 5 times as much memory. (If the GHC program builds at all that is.)

fannkuch-redux

Haskell GHC: 16.70 sec 7,628 mem

C gcc: 8.97 sec 1,660 mem

spectral-norm

Haskell GHC: 4.06 sec, 9,880 mem

C gcc: 1.99 sec, 1,824 mem

n-body

Haskell GHC: 24.48 sec, 6,468 mem

C gcc: 9.96 sec, 1,016 mem

reverse-complement

Haskell GHC: 1.39 sec, 132,176 mem

C gcc: 0.42 sec, 143,948 mem

mandelbrot

Haskell GHC: 11.64 sec, 41,180 mem

C gcc: 1.65 sec, 32,684 mem

fasta

Haskell GHC: 14.68 sec, 455,088 mem

C gcc: 1.33 sec, 2,856 mem

binary-trees

Haskell GHC: 26.28 sec 511,444 mem

C gcc: 2.38 sec 131,728 mem

k-nucleotide

Haskell GHC: Make Error

C gcc 0.06 sec ? mem

pidigits

Haskell GHC: Make Error

C gcc: 0.06 sec ? mem

regex-redux

Haskell GHC: Make Error

C gcc: 0.02 sec ? mem

Haskell GHC: The Glorious Glasgow Haskell Compilation System, version 8.0.2

C gcc: gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406

Re: Rust as a gateway drug to Haskell

#36
post #23

Rust still allows imperative programming whereas Haskell doesn't. This makes a big difference. Rust is closer to Alan Turing than it is to Alonzo Church.

Haskell definitely allows imperative programming, it's just not particularly good at it.

What is it lacking for imperative programming? I find it to be immensely good at it!

Re: Rust as a gateway drug to Haskell

#37
post #29

Earlier quoted context omitted.

> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2]. The following is just my vague, uninfor…

The benchmarks game falls squarely under the umbrella of "short, simple programs", not the sort of real-world stuff where you would benefit from having a language that scales well. That said, Haskell performs pretty well in the toy benchmarks anyway. Your comparison between Haskell and Go is about market size, not language design. I suspect you would have a similarly hard time finding Rust devs as Haskell devs (i.e.…

Language design choice pretty obviously relates to market size as my comment makes clear.

I referenced Rust because that was the article was about.

Swift and F# are languages that are not as basic as Go, but easier to find devs than Haskell.

That said, Rust has a lot going for it, even if there are a lot less devs than Swift.

Re: Rust as a gateway drug to Haskell

#38
post #18

Earlier quoted context omitted.

Hence a reason why so many people are sticking to ML despite the lack of social momentum.

ocaml is a great language in its own right too; the only haskell features I find myself really missing are do notation and operator overloading.

F# does have operator overloading.

Re: Rust as a gateway drug to Haskell

#39
post #7

> More advanced type systems, however, allow to specify the generic constraints explicitly. Well, Java allows it, even if it looks a bit unglier than the Rust example. > T min (T a, T b) { if (a.compareTo(b) > 0) { return b; } else { return a; } } And even without general availability of concepts (already in gcc 6.x), one can achieve it in C++ via if constrexpr .

The difference with Rust is that you can apply a trait to an extant type you don't "own" - you can't do that in Java or C#: you would need to use the decorator-pattern (boilerplate ahoy!). C++'s checks are closer to duck-typing in practice.

Actually you can do ad-hoc polymorphism in C# (and I assume Java too, although I've not used it). Here's an example of implementing an Eq and Ord 'type class' in C#, with 'class instances' of OrdInt and OrdString. Then a simple generic bubble-sort function which works on any type that has an Ord instance:

    public interface Eq
    {
        bool Equals(A x, A y);
    }

    public interface Ord : Eq
    {
        bool GreaterThan(A x, A y);
        bool GreaterThanOrEq(A x, A y);
        bool LessThan(A x, A y);
        bool LessThanOrEq(A x, A y);
    }

    public struct OrdInt : Ord
    {
        public bool Equals(int x, int y) => x == y;
        public bool GreaterThan(int x, int y) => x > y;
        public bool GreaterThanOrEq(int x, int y) => x >= y;
        public bool LessThan(int x, int y) => x  x 
    {
        public bool Equals(string x, string y) => x == y;
        public bool GreaterThan(string x, string y) => x.CompareTo(y) > 0;
        public bool GreaterThanOrEq(string x, string y) => x.CompareTo(y) >= 0;
        public bool LessThan(string x, string y) => x.CompareTo(y)  x.CompareTo(y) (x);
            BubbleSort(y);
        }

        public static void BubbleSort(A[] values) where OrdA : struct, Ord
        {
            bool swap;
            do
            {
                swap = false;

                for (var i = 0; i 

Re: Rust as a gateway drug to Haskell

#40

Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

This is what's really nice about Nim. It writes like Python, but is fast like Rust. Ran across Option in it the other day, though it's not used heavily. I really wish there was something like Haskell but with a runtime like Nim or Go. Perhaps that is OCaml?

Have you looked at Swift? It's pretty similar to Rust, but eschews all the lifetime stuff in favour of a runtime that does reference counting.
Post reply on HN