Rust as a gateway drug to Haskell

http://xion.io/post/programming/rust-into-haskell.html

by miqkt • 9 years ago

358 211 9 years ago

slaymaker1907• 9 years ago

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.

aaron-lebo• 9 years ago

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?

captainmuon• 9 years ago

Exactly. For me, Haskell was a gateway to Nim. I wanted something that feels familiar, but with a strong type system and native speed.

I wish I could invest some time in working with Nim. It doesn't get as much attention as it deserves in my opinion, and it would really benefit from growing the community a bit.

nicoburns• 9 years ago

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.

delhanty5• 9 years ago

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.

One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production.

It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but still pure with effects only via monads. [1], [2].

Following on and presumably related to that PureScript is strict. [3]

[1] https://news.ycombinator.com/item?id=1924094

[2] http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp... (PowerPoint) Slide 40

[3] https://github.com/purescript/purescript/wiki/Differences-fr...

mrkgnao• 9 years ago

I'm under the impression that SPJ made that comment thinking of adoption (for a future "regrettably popular" Haskell), since the difficulty of reasoning about laziness does put people off. I might be wrong though: maybe he was arguing that laziness doesn't warrant the user and compiler-author cost it brings. I don't remember where I picked this up from.

Idris is strict too, but optional laziness is built into the compiler with the use of a special-cased Lazy wrapper of the form

  data Lazy a = Delay a

This is kind of the opposite of strictness annotations (bang-patterns) from Haskell, except one doesn't need to pattern-match on Delay or use it to wrap arguments to functions expecting Lazy values. The Idris compiler can do something like "laziness analysis" (admittedly trivial in comparison to GHC's strictness analyser) to introduce and eliminate Delay constructors automatically. The laziness information is carried around in the types:

  force : Lazy a -> a
  force a = a

https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ#...

(purescript-lazy is also a thing, but I think it's not as seamless because of the "no compiler magic" position.)

In any case, what about -XStrict? I've never used it (or -XStrictData either), but isn't it a solution to the laziness problem, albeit a nuke-ish one at that?

And while we're thinking ahead, let's talk about the project to get linear types (something similar to Rust lifetimes, but weaker) into GHC :)

https://ghc.haskell.org/trac/ghc/wiki/LinearTypes

arianvanp• 9 years ago

SPJ also noted that the original success of haskell was due to their pursuit of laziness. Because laziness has no place in a system with side effects, their pursuit of laziness and functional programming is what led them to discover the usefulness of monads for describing it in the first place. If they were pursuing a strict language instead, then they were allowed to take shortcuts, because sneaking in side effects is a lot easier. YEs maybe the next haskell will be strict, but getting to the point to make that decision required laziness.

SPJ made a great lecture about this. It is very easy to follow and a fun insight into the academic history of modern functional languages https://www.youtube.com/watch?v=re96UgMk6GQ

vmchale11• 9 years ago

GHC honcho Simon-Peyton Jones saying the next Haskell will be strict,

I think all he meant that strictness was an interesting paradigm that would differentiate a language enough to justify its existence alongside Haskell.

Following on and presumably related to that PureScript is strict

Partly also to distinguish from GHCJS. Laziness in a strict language is really hard and PureScript generates semi-readable JavaScript.

oconnore• 9 years ago

Comparing it against Rust doesn't really seem fair. If I wasn't using Haskell, I'd be writing Erlang, and last I checked GHC is much faster than Erlang/OTP. Certainly faster than CPython, Ruby, and most Node.js.

Trying to compete with Rust or C++ performance in Haskell is certainly frustrating to reason about :)

pletnes• 9 years ago

While "GHC is faster than CPython" is a fairly accurate generalization, I still think python performance is easier to reason about. Haskell can give you fast code, but sometimes it will be super slow for no obvious reason.

dgroshev• 9 years ago

I would argue that at least for client-server apps Erlang is faster. Here is why: in most cases the perceived performance of a server is constrained by maximum (or 99%, whatever) latency, not by throughput. Moreover, you can scale throughput horizontally, while scaling for latency is more or less impossible. Haskell's GC can give you horrendous pauses (see [1][2]), ruining perceived performance. Erlang, on the other hand, is thoroughly optimized for minimal latency.

TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense.

[1] https://making.pusher.com/latency-working-set-ghc-gc-pick-tw...

[2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and...

hajile• 9 years ago

Why not SML/CML where you basically get haskell syntax and types, but get modules, no laziness, and you can mutate things when it's more efficient to do so.

dpratt• 9 years ago

Scala would like to have a word with you.

JoshTriplett2• 9 years ago

I had the same experience: I really enjoyed the expressiveness and power of Haskell, as well as the strong type system. But Rust gives me all those things, as well as iterators for laziness when desired, without the pervasive laziness that had me constantly chasing down space leaks and adding strictness annotations.

vmchale11• 9 years ago

But Rust gives me all those things, as well as iterators for laziness when desired, without the pervasive laziness that had me constantly chasing down space leaks

Well, yeah, Rust has manual memory management. Of course you don't get space leaks.

Anyways, Rust's laziness is not on par with Haskell. Iterators are great but it's not at all the same as e.g. GHC's lazy IO.

agumonkey3• 9 years ago

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

zem• 9 years ago

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.

wyager3• 9 years ago

This is a very overstated concern, in my opinion. Based on my experience, once you learn the common gotchas (lazy folds, WHNF, etc.) it's rarely an issue. Real-world programs (web servers, databases, etc.) typically end up using frameworks that deal with strictness concerns for you anyway. For maybe the first couple weeks I was learning Haskell, this was a source of confusion, but I don't seem to run into it anymore.

If it's really a struggle for some reason, you can always take the nuclear option and enable strict mode on your code.

Haskell is very good for writing extremely fast code that's also extremely composable, which most languages (even Rust, to a substantial degree) really struggle with. Haskell's pure non-strict semantics and support for fusion/rewrite systems means that you can write complex operations on vectors, byte arrays, text, etc. that span multiple modules but get compiled down to extremely tight in-place assembly code. Another way of looking at it is that the economies of scale for Haskell are very different. There's a higher up-front cost because you have to learn about how strictness works, but as a consequence 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.

delhanty5• 9 years ago

.. 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, uninformed impression, but Haskell and Go seem to be opposite ends of a spectrum, with Rust somewhere in between:

Haskell: good for expert individuals and small teams. The language is highly sophisticated and the compiler is rather slow. At heart, it's a research language, so the direction might not always suit production use. If you contract out to a Haskell development shop, who do you turn to with your Haskell code-base if things don't work out?

Go: designed by Google for their use-case - large teams of commodity programmers. It's very quick to onboard programmers - they can be productive and non-dangerous quickly. The language is very simple and the compiler is very quick - which is again good for scaling large teams.

[1] https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

[2] https://donsbot.wordpress.com/2008/05/06/write-haskell-as-fa...

marcosdumay• 9 years ago

Some real world programs have a very clear request-response cycle that Haskell deals with very well (although a more predictable garbage collector would be great).

Other real world programs have a strict "always push things into the world, react to inputs" cycle that Haskell has trouble supporting.

hellofunk• 9 years ago

I don't use Haskell but didn't I read recently that the latest version of Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly?

lkurusa• 9 years ago

There is -XStrict, see here for a discussion: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

vmchale11• 9 years ago

Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly

It's a common concern but it's a terrible critique. Laziness has many subtle benefits, but everyone whines about it because its pitfalls are decidedly not subtle.

k__5• 9 years ago

Wasn't the selling point of laziness performance?

"It only does what is needed!"

I didn't use Haskell but Nix and at least there it seemed reasonable to "not do" everything.

snovv_crash• 9 years ago

In other languages when the compiler misses an optimization you get a constant order penalty on a small piece of code.

In Haskell when the compiler misses an optimization the performance hit is potentially unbounded, as it could think anything is a dependency. (You want the first N digits of pi? Just wait while I calculate all of them for you...)

Tuna-Fish• 9 years ago

Haskell can be made very fast. The problem is that at least for me, performance is often quite non-intuitive. As in, make tiny change to program, it is now a hundred times slower. Then you get to hunt down the reason why it's now doing too much work/ why stream fusion isn't working anymore/why it's leaking so much space/etc for hours.

I enjoy writing Haskell for small hobby projects, but I doubt I would choose it for real work now that F# and Rust exist.

tome7• 9 years ago

I don't think anything is the unique selling point of laziness. Wikipedia[1] says "The benefits of lazy evaluation include:

* The ability to define control flow (structures) as abstractions instead of primitives.

* The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms.

* Performance increases by avoiding needless calculations, and error conditions in evaluating compound expressions."

In my several-year experience as a professional Haskell developer the first and second points are at least an order of magnitude more important than the third.

[1] https://en.wikipedia.org/wiki/Lazy_evaluation

georgewsinger3• 9 years ago

Haskell's laziness is an issue for you? Then how do strictness annotations (and/or module flags) not solve this problem?

Haskell also has inline-C FFI support for "type safe" performance escape hatches (in the sense that you can manually bring C constructs into Haskell's type system): https://github.com/fpco/inline-c

The only way that Haskell inescapably suffers from performance hits (that I'm aware of) is not in its laziness or lack of imperative programming support, but in its periodic GC pauses. In such cases where GC pauses are an issue, I still think you can -- in principle -- write more and more performance critical pieces of your application in a non-GC language (in fact, you could do this in Rust just as well as C/C++). You can also manually trigger a GC pass, although you cannot -- to my knowledge -- manually stop and start GC passes in your code.

This is the approach I'm currently taking in a performance critical VR application where GC pauses could absolutely be an issue (using as much Haskell as possible, with C and GC triggers as an escape hatch). And if someone could point out a flaw in my reasoning (in particular, how GC pauses might be inevitably avoided even with C FFI), I would gladly pay them money, because it's so important I not get this one wrong :).

mej10• 9 years ago

It is also possible to avoid GC pauses causing problems in your application with a load balancer. Basically shifting load between haskell processes when a big GC is imminent.

Read about that technique from Simon Marlow of Facebook's Haskell team. Of course it would be awesome to not have to worry about that.

dllthomas3• 9 years ago

Then how do strictness annotations (and/or module flags) not solve this problem?

Strictness annotations (and associated pragmas) only change the strictness of constructors and functions defined in my modules. I still have to reason about laziness as I use almost anything from the Haskell ecosystem.

brianberns• 9 years ago

You might want to consider F# as well. It supports both lazy and greedy functional programming very nicely.

verandaguys_alt2• 9 years ago

While I've found that Haskell's laziness can often be worked around with appropriately-implemented memoization, it's an absolute PITA for anything that requires frequent hops into the IO monad (unsurprisingly). Historically, this has been a bottleneck for me that's prevented me from using Haskell in any major projects.

A Haskell port of a logging library I'd originally written in Python ended up being almost 2 orders of magnitude slower than CPython 3, and almost 3 orders of magnitude slower than PyPy3.

PyPy3 resulted in performance similar to a barely-optimized C port.

vmchale11• 9 years ago

Do you have source code? It sounds like you were writing unidiomatic Haskell.

crimsonalucard6• 9 years ago

It's not just laziness. Functional programming is what happens to the universe when you eliminate the concept of Time. It is a mega abstraction over the what's really going on under the hood.

However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie.

Reasoning about the performance of a functional program is to peer through the lie and "reintroduce" time into this abstraction. This is why it it notoriously hard for functional programs to be reasoned about. Procedural programs are much more better for this in that regard.

tome7• 9 years ago

This is utter nonsense.

Everything you wrote is somewhere between 90° and 180° wrong.

akhilcacharya• 9 years ago

Functional programming is what happens to the universe when you eliminate the concept of Time.

I've heard this a lot but still can't find a good code example to illustrate this. Any help?

willtim• 9 years ago

Most problems arise from using linked-lists in inappropriate situations. This includes using the default String type. Both the list and string syntax have been overloadable for a while, so using alternatives when necessary shouldn't be an issue. Understand the complexity of the data structure operations you are using and you will get fast code, laziness does not change this (although space usage can be hard to reason about).

The benefits of laziness is difficult to appreciate if you are not used to it. For a great example of the benefits it brings, please read this:

http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...

vmchale11• 9 years ago

It was very frustrating to try reasoning about performance in Haskell due to its laziness.

Conversely, I find it hard to achieve the same performance with strict code. I think it's likely a matter of familiarity.

Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

The standard prelude is flawed in many ways. Haskell 2020 will hopefully fix this. In the meantime: the recursion-schemes library might be of great use.

Symmetry3• 9 years ago

Something I've always wondered about Haskell is whether there is, in practice, rope for the compiler to optimize things away from the theoretical underlying implementation. For instance a C compiler is free to turn

  for (int i = 0; i < N; i++) {
    a[i] = 2*b[i];
  }
  for (int i = 0; i < N; i++) {
    c[i] = 2*d[i];
  }

into

  for (int i = 0; i < N; i+=2) {
    a[i] = 2*b[i];
    a[i+1] = 2*b[i+1];
    c[i] = 2*d[i];
    c[i+1] = 2*d[i+1];
  }

It seems like GHC ought to similarly be able to turn some

  foo :: [Int] -> [Int]

into

  foo :: [(Int, Int)] -> [(Int, Int)]

under the covers for a similar speedup as long as it can, as with the C compiler, handle the case of an odd length with a bit of extra code.

There are limits to how much you can restructure a list that's exported outside the compilation unit (my Haskell knowledge is fuzzy here so that's probably not the right terminology). And if the list is being re-stitched in odd ways it might be a bad idea. But as far as I can tell it ought to be doable and useful in most common cases. Of course maybe it's already doing this in those cases where it can prove that it works and that's why Haskell performance generally is good but fragile.

haldean2• 9 years ago

Haskell performs a very cool optimization called "stream fusion" to deal with a whole class of traversal optimization problems; stream fusion removes intermediate list results completely, and bundles a bunch of things that look like maps/reduces/filters into a single operation. Your example doesn't quite hit it, but a similar bit of code like:

    for (int i = 0; i < N; i++)
        a[i] = 2 * b[i];
    for (int i = 0; i < N; i++)
        c[i] = 2 * a[i] + b[i];
    t = 0;
    for (int i = 0; i < N; i++)
        if (b[i] % 2 == 0) t += c[i];

Would be rewritten to the equivalent of:

    t = 0;
    for (int i = 0; i < N; i++)
        if (b[i] % 2 == 0) t += 5 * b[i];

Lots more info on the GHC optimizations page: https://wiki.haskell.org/GHC_optimisations#Fusion

Gackle_Murderer• 9 years ago

You might like Idris. Not nearly as mature as Haskell, but definitely as powerful, with much more reasonability when it comes to performance, thanks to eager evaluation.

yitzg• 9 years ago

As a Haskell practitioner in industry - for several years we have been creating technical documentation sites for large enterprise customers, providing fast semantic search for gigabytes of content serving millions of users - I can attest that this simply isn't true. We have found that reasoning about performance in a pure functional language is not harder than for any other kind of mainstream language. Except in the sense that it is different, so not all of your skills and intuition from other languages necessarily apply.

thesz• 9 years ago

Something I found about going to Haskell from <any other language> is that Haskell provides many powerful abstractions without compromising on performance. Especially programmer's performance.

If you do not need to write notoriously slow code in Haskell, just don't do it. Use libraries (containers and mtl especially great), keep state strict (a handful of bang patterns).

I use Haskell's laziness with great success (look for paper "generating power of lazy semantics" it's fascinating; look "the essence of functional programming" for even more fascination). I use Haskell's flexibility with great success (how about beating C speed ten times? how about parallelization to all cores with couple lines of code?). It is really great language.

BTW, Haskell's RTS reuse chunk type field which is needed for implementation of laziness for synchronization and it is great! This means that it can provide everything that Java and/or .Net provides and get away with twice as less overhead for it.

spullara• 9 years ago

Maybe the other way around.

asdfaoeu• 9 years ago

"the legacy C++"

Interesting reading but the author seems intent on pushing some buttons.

teamhappy• 9 years ago

Maybe that's just his way of saying "C++ without concepts."

vmchale11• 9 years ago

C++ is legacy. It was created in 1979.

pjmlp5• 9 years ago

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 extends Comparable<T>> 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.

DaiPlusPlus2• 9 years ago

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.

pjmlp5• 9 years ago

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

louthy2• 9 years ago

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<A>
    {
        bool Equals(A x, A y);
    }

    public interface Ord<A> : Eq<A>
    {
        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<int>
    {
        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 < y;
        public bool LessThanOrEq(int x, int y) => x <= y;
    }

    public struct OrdString : Ord<string>
    {
        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) < 0;
        public bool LessThanOrEq(string x, string y) => x.CompareTo(y) <= 0;
    }

    public static class Testing
    {
        public static void Test()
        {
            var x = new[] { 3, 8, 1, 2, 10 };
            var y = new[] { "mary", "had", "a", "little", "lamb" };

            BubbleSort<OrdInt, int>(x);
            BubbleSort<OrdString, string>(y);
        }

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

                for (var i = 0; i < values.Length - 1; i++)
                {
                    var x = values[i];
                    var y = values[i + 1];

                    if (default(OrdA).GreaterThan(x, y)) // Ad-hoc polymorphic call to GreaterThan
                    {
                        swap = true;
                        values[i] = y;
                        values[i + 1] = x;
                    }
                }
            }
            while (swap);
        }
    }

partycoder• 9 years ago

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.

wyager3• 9 years ago

Haskell allows you to recreate standard imperative semantics purely (with the State monad, plus lenses for familiar syntax), or to use actual stateful imperative mutability ("purely" via ST or impurely via IO).

danidiaz• 9 years ago

There was a recent post about "imperative Haskell": http://vaibhavsagar.com/blog/2017/05/29/imperative-haskell/

The code in this other post about implementing string distance metrics is also quite imperative: https://markkarpov.com/post/migrating-text-metrics.html

xedrac• 9 years ago

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

eklavya• 9 years ago

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

cannam• 9 years ago

"Haskell is, in my view, the world’s best imperative programming language, and second-best functional language" - Robert Harper (https://existentialtype.wordpress.com/2011/04/09/persistence...)

vesak4• 9 years ago

I wonder if Idris could some day take Haskell's place. It sports default eager evaluation. Seems like the tooling (package managers etc.) isn't quite there yet, though.

runeks3• 9 years ago

Is a difference in a default option really enough for a language to take the place of another? And if it's not just a change in a default option, but the removal of laziness, we lose something, which will make the choice less obvious.

I think it's more likely that, if dependent types prove really useful, Haskell will adopt these, and people will adapt their code, rather than port everything to a new language.

As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering.

firethief2• 9 years ago

A System F type system can't be replaced by a dependent type system without affecting existing code. There is no way to turn the libraries in Haskell into libraries in dependently-typed Haskell without "porting them to a new language" and all the work that entails.

vesak4• 9 years ago

And if it's not just a change in a default option, but the removal of laziness, we lose something, which will make the choice less obvious.

What would we exactly lose?

As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering.

That is true, though. Perhaps Rust is the safer bet, even if it lacks many nice things. The sum is probably quite a lot better still.

douche2• 9 years ago

That place being the cool esoteric language that everybody fools around with on the weekends, but is almost never used seriously?

vesak4• 9 years ago

That place being the cool esoteric language that everybody fools around with on the weekends, but is almost never used seriously?

Indeed. Some people actually use Haskell, though. They even claim it's fun and productive, but having done so myself, I'm forced to be undecided on whether they're just suffering from Stockholm Syndrome.

toprerules• 9 years ago

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 of reason" when we all see the error of our ways for writing dangling pointer references and impure functions. To be a complete cynic, I hope Rust runs right away from over generalized abstractions and the Haskell indifference to achieving real success by overcomplicting even the most mundane of problems.

motet_a2• 9 years ago

Yes. Complex languages are not required to solve complex problems. This is why Go and JavaScript are so popular.

Sharlin• 9 years ago

I'd say neither Go nor JavaScript are predominantly used to solve complex problems. The main use cases for both are solving mundane problems by mundane programmers. In case of Go that's an explicit design philosophy.

vmchale11• 9 years ago

That's... not really true. JavaScript solves trivial problems, and it's mainly popular because it's literally the only web language around.

jnordwick• 9 years ago

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

Am upvote hoping you don't get buried.

chongli2• 9 years ago

it isn't completely wrong

It may get some of the facts right, but the tone is completely wrong. Cynicism is just a step or two away from nihilism. It's far, far easier to destroy than it is to create. The world needs more creators, not destroyers.

foldr• 9 years ago

I think this is a little unfair on Rust. You can get a lot done using stable Rust.

pas• 9 years ago

There's nothing wrong with the ability to generalize abstractions, the problem is when all you know are category theory everything looks like a zygohistomorphic prepromorphism.

Case in point, TypeScript and mypy. Both are adding more abstractions, more powerful types, more aspects, because people find/have fitting use cases for those features.

That doesn't mean let blah = document.getElementById("blah") ; blah.innerHTML = "..." or import requests ; requests.post(...) will become deprecated, but it means it'll be easier to express more things (like conditions/assumptions on shape or state of data, control flow, component dependencies) without boilerplate (and copy-paste), and maybe helping other developers make sure they cross all the t-s and dot all the i-s.

Does this have a cognitive cost? Yes, especially in Rust/Haskell.

Are there escape hatches? Yes, of course, like unsafe and whatever Haskell has.

Should a developer who isn't familiar with those assumptions/conditions work on the code base anyway? No, not really.

(Is Haskell ugly? Yes. :( )

guipsp• 9 years ago

The haskell escape hatches are the unsafe family of functions, such as unsafePerformIO

steveklabnik3• 9 years ago

rarely producing production grade systems.

https://www.rust-lang.org/en-US/friends.html has been growing at a pretty hefty pace lately!

le0n• 9 years ago

Haskell/GHC will soon have an extension for linear types, which will bring the languages much closer: http://blog.tweag.io/posts/2017-03-13-linear-types.html

kccqzy2• 9 years ago

Yeah right. If only the standard library (the base package) could immediately be converted to use linear types and we can all benefit from that! (Hint: it won't. Even the fairly no-brainer AMP and BBP took an absurdly long time. This is extremely slow by Rust standards. The Haskell community might, but the stewards of the standard libraries don't have the move-fast-and-break-things attitude.)

Tarean8• 9 years ago

Did rust ever have a large scale breaking change? Anyway, the linear type proposal is designed to be completely backwards compatible so that shouldn't be as big of an issue.

tome7• 9 years ago

Even the fairly no-brainer AMP and BBP took an absurdly long time

This is because, believe it or not, Haskell is actually used in the real world and people care about their code not becoming broken.

nickpsecurity• 9 years ago

Rust uses affine types instead of linear types per some statements I've seen on the subject. I wonder why they wouldn't use affine types in this. Either way, it's good they're adding it.

sandGorgon• 9 years ago

I have heard the same thing about Kotlin now - https://hackernoon.com/kotlin-functors-applicatives-and-mona...

throwaway91111• 9 years ago

Err kotlin as a gateway drug to haskell? They might wanna fix type erasure first....

opmac• 9 years ago

Can't fix that w/o fixing the JVM.

corn_dog• 9 years ago

maybe kotlin as a gateway drug to scala as a gateway drug to haskell

decafbad• 9 years ago

Rust and Kotlin destroy any previous claims about practical usages of Haskell.

jmcomets• 9 years ago

Could you elaborate? I'm not sure practical usages of Haskell are replaced by Rust/Kotlin, the high-level of abstraction and pure functional paradigm are practical.

kryptiskt• 9 years ago

Kotlin isn't anywhere near being a substitute for Haskell, it's a nice set of syntactical tweaks for Java users but it doesn't even have ADTs or real pattern matching.

lmm4• 9 years ago

Languages without HKT are horribly impractical for large codebases.

pathsjs3• 9 years ago

Yet there are not many large codebases in languages with HKT, and even those which are there (mainly big Scala projects) do not use HKT

v0lta• 9 years ago

That's the most HN post title in a while

timwaagh• 9 years ago

i imagine they both provide a similar hipster code high. while being fairly hard to do something useful in or make money with.

allengeorge• 9 years ago

The article references using trait objects for dynamic dispatch. FWIW, I found them extremely limited: you can't use generics, can't return Self... I wonder how often people use them.

cbcoutinho• 9 years ago

What do you mean you can't return self? I'm just starting out with learning rust, but from what I've gathered you can use objects in a myriad of ways that will allow you do what you need.

Instead of returning self, you could just pass a reference - you need to mutate self then just pass a mutable reference. Did I miss something here?

steveklabnik3• 9 years ago

Returning Self in a trait object isn't possible; it's not object safe. In order to return Self, you'd need to know the concrete type of the thing, and when you have a trait object, that's erased.

Returning a trait object instead of plain Self would work though.

kbutler• 9 years ago

Isn't the most significant line: "For work-related reasons, I had to recently get up to speed on programming in Haskell"?

I was somewhat disappointed not to have a followup to what work-related reasons there might be. Note also that the About page says "work at Facebook".

dllthomas3• 9 years ago

If you're puzzling at the connection between Facebook and Haskell, https://github.com/facebook/Haxl is the most obvious one.

leshow• 9 years ago

I have found them to be very similar too. I started learning Haskell in earnest last September, following along with the exceptional "Haskell: First Principles" which I highly recommend. I had been toying with Rust around this time and I found a confluence of ideas between the two languages. Most things I learned in Haskell I was able to carry over to Rust.

The inverse was not quite as true. But I still love Rust. Any time I need something performant, or I just want to play around, it's my first choice.

Rust as a gateway drug to Haskell

Related Stories