Commercial Haskell should go after Python / Julia, not Rust

24

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

3 Likes
25

I concur with what you said prio. But never say never :slight_smile:

1 Like
26

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.

27

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.

11 Likes
28

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.

3 Likes
30

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.

3 Likes
31

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

5 Likes
32

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.

12 Likes
33

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.

1 Like
35

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.

37

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

2 Likes
38

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.

3 Likes
39

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

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 :slight_smile:), 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.
14 Likes
40

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?

1 Like
41

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.

4 Likes
42

Perhaps it’s time to show how those up-front restrictions can be worthwhile: instead of just being multi-threaded by default, make Haskell parallel by default:

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

2 Likes
43

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.

44

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.

45

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

46

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 ;-)…

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.

1 Like