# Commercial Haskell should go after Python / Julia, not Rust

**URL:** <https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964>\
**Category:** Uncategorized\
**Created:** [July 12, 2023, 6:04am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964 "2023-07-12T06:04:27Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![simonmic](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonmic/32/1796_2.png) [@simonmic](https://discourse.haskell.org/u/simonmic)\
**Post date:** [July 13, 2023, 8:25am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/24 "2023-07-13T08:25:55Z")

</div>

> [@Liamzy](#):
>
> As far as scripting goes, I wouldn’t consider Haskell optimal because Haskell is typically compiled (interpreter without O2 tends to perform relatively badly, although generally it’ll outperform Python substantially),

I use stack scripts often, sometimes interpreted, sometimes compiled automatically as needed by `stack script --compile`. I could optimise with `stack script --optimize`, but I rarely bother. Even in interpreted mode, these normally feel plenty fast to me, other than a little (fraction of a second) startup delay when interpreted.

(Such scripts are great, but we shouldn’t expect them to cover all the same use cases as shell scripts. I don’t think Haskell will ever become as good as shell at gluing other programs together.)

---

<div class="post-metadata">

**Author:** ![hellwolf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hellwolf/32/3020_2.png) [@hellwolf](https://discourse.haskell.org/u/hellwolf)\
**Post date:** [July 13, 2023, 8:51am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/25 "2023-07-13T08:51:26Z")

</div>

> [@simonmic](#):
>
> I don’t think Haskell will ever become as good as shell at gluing other programs together.

I concur with what you said prio. But never say never 🙂

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [July 13, 2023, 10:33am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/26 "2023-07-13T10:33:11Z")

</div>

After long thoughts, I still cannot get rid of the impression that haskell is focused in research. Not only that dependent types and linear types give off the feel, but seeing that haskell is used in settings typically adjacent to the research (experimentation of novel ideas). It seems to me that lots of programming language research is being done with haskell, and this sparks the little usage in industry.

If so, wouldn’t it be better to focus on research efforts rather than trying to cling to the dwindling industry base? It does not help that there is a looming crisis in software/tech sector, which could decimate the industry.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 13, 2023, 10:54am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/27 "2023-07-13T10:54:09Z")

</div>

On the contrary, it’s industry use where Haskell is growing and we have vast potential for more growth. There’s not really any room for Haskell to grow in academia! Can you imagine Haskell use _doubling_ in academia? I can’t. Can you imagine Haskell use growing tenfold in industry? Yes, I can easily imagine that. In fact I think that would be a very unambitious goal.

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [July 13, 2023, 12:23pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/28 "2023-07-13T12:23:57Z")

</div>

Interesting, but I do think haskell use could double or more in academia. It’s not like entire academia is only using haskell. In particular, I do not see much haskell usage outside of programming languages research, so haskell could certainly expand there given appropriate opportunities.

Meanwhile, I disagree that haskell use could grow a lot in industry. We are already seeing some shrinkage, while degree upon which could be debatable. Most problematically, industry usage is mainly driven by profit motives, and I do not see haskell’s strength there in current environment. Companies (nowadays) do not care about safety and correctness, they prefer delivering new features quick with least cost as possible. This explains why JS and Python is booming in industry. Meanwhile, haskell is exactly opposite of that.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [July 13, 2023, 12:56pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/30 "2023-07-13T12:56:18Z")

</div>

TBH, the trick is more HLS these days, i.e, HLS’s type highlighting gives you, first, a predicted type of your code, and second, will squiggly your type errors as you code.

By just using HLS as an IDE, you can get both “if it compiles, it works” and “it’ll compile the first time” because the type errors will get caught at the development stage, not at the compilation stage.

@Abab9579 The problem with Haskell as a research language is that Haskell is 30 years old. Much of the best and most innovative research in Haskell happened near Haskell’s birth; we still see interesting research these days, like with the delimited continuations primitives, refinement types, linear types, but the pace is much more gradual.

Moreover, Idris has a more advanced type system than Haskell, and will have such for the foreseeable future given the lateness of dependent types. So if you want to do purely theoretical research on type systems, Idris is probably a better bet.

* * *

As far as Haskell shrinkage goes; yes, we are seeing shrinkage, but that’s only because we oriented ourselves around safety and correctness, and Rust provides a good-enough solution, paired to better performance, a relatively-easier learning curve, and a bigger developer pool.

However, the point of this thread is that we should see it as an opportunity.

You are right that for most applications, industry doesn’t care about correctness. But correctness isn’t the only strength Haskell has; Haskell can also be more expressive than Python, while being substantially faster.

Despite Hudak talking about Haskell’s prototyping advantages, this is not something we’ve been focusing on, because we’ve been seeking to compete via correctness. Now, with correctness no longer being a viable avenue of competition (we still win vs Rust, but all the other factors make us lose), how about working on ergonomics instead, where Haskell tends to blow Rust out of the water?

An alternative to Rust that is less performant, but substantially more ergonomic, is something that’s competitive (or else everyone would be programming in C). An alternative to Python that is more performant, ergonomic, and correct is also something that’s competitive.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 13, 2023, 1:04pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/31 "2023-07-13T13:04:52Z")

</div>

> [@Liamzy](#):
>
> As far as Haskell shrinkage goes; yes, we are seeing shrinkage

I’m really not convinced we’re seeing shrinkage. I’d like to see some concrete evidence either way. (Granted some notable industrial users have moved away from Haskell, but to show shrinkage you have to demonstrate that equal numbers are not taking up Haskell.)

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [July 13, 2023, 1:08pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/32 "2023-07-13T13:08:13Z")

</div>

> [@Liamzy](#):
>
> because we’ve been seeking to compete via correctness

I don’t think we actually have. People will be tired of me bringing this up again, but:

- lazy IO is all over base
- it took a couple of decades to fix the `type FilePath = String` debacle (and will take a couple more)
- our Numbers are rather awkward
- the posix compatibility layer for windows is scary… yes, we have a new windows IO manager using proper Win API, but how many decades did that take?
- directory package has questionable cross platform functions

I could go on… but that’s exactly my point: Haskellers seem to have an odd view of what “correctness” is, attributing it more to restrictive, fancy types, rather than robust and well designed primitives.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 13, 2023, 1:18pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/33 "2023-07-13T13:18:00Z")

</div>

Agreed, and I elaborate by saying that the important question is what we _can_ compete on, not what local optimum we’ve fallen into by accident. I would say Haskell’s value proposition lies in correct and ergonomic general purpose software development, but we’ve got a long way to go to actually deliver on that proposition.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [July 13, 2023, 1:24pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/35 "2023-07-13T13:24:08Z")

</div>

Sadly, the answer is, “This is true when the language server works.”, and it’s not that hard to break HLS. But we’re slowly getting better at this.

---

<div class="post-metadata">

**Author:** ![slack1256](https://avatars.discourse-cdn.com/v4/letter/s/bbce88/32.png) [@slack1256](https://discourse.haskell.org/u/slack1256)\
**Post date:** [July 13, 2023, 3:03pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/37 "2023-07-13T15:03:48Z")

</div>

@satoshi778  
I do wonder if multicore is our real strength. FP languages need a GC (unless completely linear as in linear lisp) and most GC’s I have seen do no scale linearly with the number of cores. Garbage is not produced uniformly at the same rate by HECs nor can be effectively work-stealed without cache performance impact. And I say this as someone who likes out generational moving stop-the-world garbage collector.

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [July 13, 2023, 3:22pm UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/38 "2023-07-13T15:22:20Z")

</div>

> [@Liamzy](#):
>
> As far as Haskell shrinkage goes; yes, we are seeing shrinkage, but that’s only because we oriented ourselves around safety and correctness, and Rust provides a good-enough solution, paired to better performance, a relatively-easier learning curve, and a bigger developer pool.
> 
> However, the point of this thread is that we should see it as an opportunity.
> 
> You are right that for most applications, industry doesn’t care about correctness. But correctness isn’t the only strength Haskell has; Haskell can also be more expressive than Python, while being substantially faster.

I think you are missing the point of using JS and Python. It is much easier for a person to learn python/JS and start working on some code. As a result, it takes little cost for a company to hire (fairly incompetent) python dev and train them with minimal effort. Also explains why Go is made as so, and is getting decent adoption. Such devs are dirt cheap in terms of labor and handling.

Can we expect the same for Haskell? Eh, I do not see it.

---

<div class="post-metadata">

**Author:** ![jameshaydon](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jameshaydon/32/3336_2.png) [@jameshaydon](https://discourse.haskell.org/u/jameshaydon)\
**Post date:** [July 14, 2023, 2:59am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/39 "2023-07-14T02:59:54Z")

</div>

This thread motivated me to take some time to interview some of the people I know as to why they would choose Python over Haskell. The result is here: [Why (some) Python programmers don't choose Haskell · GitHub](https://gist.github.com/jameshaydon/43a6521cb20e9135df09ea59524b7cd0)

The most interesting aspect of this sample is that these people are researchers who are not afraid of category theory / monads.

These opinions are not my own (I choose Haskell for everything 🙂), but I hope they can help the Haskell community understand why more people don’t choose Haskell.

Some of the general themes:

- Haskell just isn’t very well known.
- Python has so many libraries.
- Python has good, beginner friendly tooling.
- I am using Python and my collaborators are already using Python, would need a good reason to change.
- Students can pick up Python very quickly.
- With Python you (or a collaborator, or a student) can always “muddle through”. With Haskell you may just get stuck.
- Haskell seems “locked down” (types? purity is handcuffs? no imperative programming?)
- Unfamiliarity with functional programming.
- Haskell code in the wild looks very complicated compared to Python code in the wild.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [July 14, 2023, 6:30am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/40 "2023-07-14T06:30:30Z")

</div>

I can criticize your assertion in multiple ways; i.e, we can really streamline Haskell teaching processes (as shown by production Haskell shops, which are more attached to teaching efficiency than pure FP) to get fairly good efficiency.

Hasura, for instance, got off the ground by hiring Indian programmers without Haskell experience and training them. That seemed to have worked in their early stage, then they went to hire Well-Typed to clean up their code base, and eventually migrated to Rust.

There are Haskell firms that claim 2-week on-boarding times for non-Haskellers, and there are also Haskell firms that expect 4 weeks on-boarding, but that is equivalent to their experience with non-Haskell languages.

* * *

On the other hand, you are right insofar as I wouldn’t consider it desirable for Haskell to turn into a “codemonkey” language, not because of disdain for codemonkeys, but because there are already a lot of bad Haskell codebases out there, as evinced by reports from Eric Normand, hasufell, and others.

Bad Haskell codebases deliver bad Haskell experiences, and word of bad Haskell experiences leaks out. It’s bad for the brand.

* * *

On the other hand, if Hasura wants to hire skilled Indian developers and train them on Haskell, or a Chinese firm might want to exploit the local level of mathematics education, what’s the problem? Or, in LaurentRDC’s case, there are a lot of domain experts with relatively strong mathematics backgrounds who might be better off working with Haskell than Python.

I think the point to be emphasized is that if Haskell does decide to go after Python’s use cases, we should be going after their high-end use-cases, not the commodity coder market.

* * *

I think, at the end of the day, this thread just comes out to a plea for Haskell to:

-Have tooling that’s easier to use (we’re working on it, and great progress has been made)  
-Have better educational materials and on-boarding (not exactly there yet, but there’s been a lot of work on teaching Haskell in a practical way).  
-Have a better ecosystem that is both broader and friendlier to newbies (we’re weakest here, but there are still a lot of dedicated Haskellers working on newer libraries as well as keeping older libraries modern).

The urgency comes more in that prominent Haskell firms have already moved away from Haskell, because Rust is sufficient “worse is better” (and is strictly better in other respects), and keeping industrial Haskell use just stable may require new approaches.

@tomjaguarpaw

Meta is rumored to be nixing some Haskell systems, although exactly which isn’t known, and Meta is still a Haskell Foundation Monad-tier donor. Collegevine is obsoleting much of their Haskell infrastructure, choosing Ruby instead for faster prototyping, back when IHP wasn’t a big thing. Tsuru Capital ran off to Rust. Hasura rewrote in Rust.

Digital Asset seems to have downgraded from Monad-tier to Applicative-tier, and there could be a variety of reasons for thus.

On the gains side, I can think primarily of Juspay, which is comparably sized to Hasura, but working in financial services; Co-star seems a bit scammy (they’re an astrology provider, after all), but they’re a small shop to which Haskell seems central to their business model (sure, we’re astrology, but you’re okay with crypto, no?). There’s LaurentRDC’s proprietary trading firm conducting a Haskell experiment; what other companies have hopped aboard the Haskell bandwagon of late?

---

<div class="post-metadata">

**Author:** ![bradrn](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bradrn/32/264_2.png) [@bradrn](https://discourse.haskell.org/u/bradrn)\
**Post date:** [July 14, 2023, 6:56am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/41 "2023-07-14T06:56:51Z")

</div>

Thanks so much for this! To me, this feels like it boils down to, essentially, ‘I’m not using Haskell because no-one else is using Haskell’. And, sad to say, that’s not a bad argument… to overcome that problem, any language would have to be truly exceptional compared to the competition.

On the other hand, I think this may be biased by the fact that these people identify as researchers, not developers. In my experience as a research student in physics, researchers don’t really care too much about programming: they need it to get their job done, and beyond that they’re not really interested. Actual developers seem to be much more flexible than researchers in terms of switching between programming languages.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [July 14, 2023, 7:19am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/42 "2023-07-14T07:19:21Z")

</div>

> [@jameshaydon](#):
>
> - Haskell seems “locked down” (types? purity is handcuffs? no imperative programming?)

Perhaps it’s time to show how those up-front restrictions can be worthwhile: instead of just being [multi-threaded by default](https://github.com/ghc-proposals/ghc-proposals/pull/240), make Haskell **parallel by default:**

> [@](#):
>
> (pages 18-19 of 217)
> 
> This no-intervention-needed parallelism is usually called _implicit parallelism_ and it is very important for scalable machines: one cannot expect a programmer to pre-plan the execution of hundreds of thousands of independent processing tasks “by hand.” Consequently, functional programming - which proponents claim is superior anyway - holds the prospect for significant parallelism without any extra effort from programmers.
> 
> [Graph reduction without pointers](https://www.cs.unc.edu/techreports/89-045.pdf), William D. Partain (1989).

So what would be needed for this to happen in GHC?

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [July 14, 2023, 7:54am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/43 "2023-07-14T07:54:55Z")

</div>

> [@atravers](#):
>
> So what would be needed for this to happen in GHC?

I’ve always thought that it would not be impossible to tweak the garbage collector to spark some threads to speculatively evaluate thunks. You’d need rollback and timout mechanisms to avoid errors and infinite loops. And for it to be effective you’d also need a good heuristic on which thunks to evaluate this way.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [July 14, 2023, 8:02am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/44 "2023-07-14T08:02:59Z")

</div>

As I dimly recall, there was an experiment (and associated paper) which described something like that, albeit for a sequential implementation: it would reduce e.g. `fst (x, y)` to `x` during the collection, because it could ascertain that `fst`'s argument was already evaluated.

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [July 14, 2023, 8:03am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/45 "2023-07-14T08:03:48Z")

</div>

That’s not an experiment, it is a crucial part of the garbage collector we use today!

[https://homepages.inf.ed.ac.uk/wadler/topics/garbage-collection.html](https://homepages.inf.ed.ac.uk/wadler/topics/garbage-collection.html)

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [July 14, 2023, 8:06am UTC](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964/46 "2023-07-14T08:06:08Z")

</div>

Yes, that is the technique I was trying to recall - if it’s still being used in GHC, that could be a useful place to start `(`_after_ multi-threading by default is firmly established `;-)`…

* * *

> [@jaror](#):
>
> You’d need rollback and timout mechanisms to avoid errors and infinite loops.

I suggest starting with _conservative parallelism_ first:

- if there was going to be a problem, it would have eventually appeared during sequential evaluation anyway.

- a simple compile-time heuristic could be used, relying on the results of strictness analysis to nominate sub-expressions suitable for parallel evaluation.

[Previous page](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964.md?page=1)

[Next page](https://discourse.haskell.org/t/commercial-haskell-should-go-after-python-julia-not-rust/6964.md?page=3)