How to grow the (commercial) Haskell user base?

[dschrempf]

I think this is an excellent point, @jaror!

This talk may also be interesting to some of you

Gabriella Gonzalez – How to market Haskell to a mainstream programmer

[hasufell]

That’s just cute advertising.

What counts in the end are the interactions. When I started fresh in Haskell, I was mostly roaming the #haskell IRC channel and while there wasn’t a “the world is a happy place” vibe, it was an extremely resourceful and supportive place back then and I believe is still today.

I do not think I would have stuck around for that long if it wasn’t for the people in that channel.

On the other hand: contributing to hackage libraries and other major projects left me with a bag of mixed feelings. I’ve come across quite a few maintainers who are not willing to collaborate (and they are not obliged to!), but here I wish we could incentivize collaborative attitude somehow.

My best bet would be something like Maintainership standards · Issue #7 · haskellfoundation/stability · GitHub

[dhouthoo]

Just my 2 cents as a software professional: make it easy and prescriptive like elm did.

Or like the role that spring and quarkus take in the java ecosystem: they tell you exactly how to write a common bread-and-butter REST to db application.

Intermediate Haskell is a wasteland. It needs more todo list and petstore applications

[jeukshi]

@TeofilC

I think performance worries are something that get overemphasized in these discussions.

I totally agree. I don’t think Haskell stands a chance against Rust with what Rust does best (it is better to go the Python way and interface with those fast languages). But why even bother with that competition? Easily half of the internet is written in PHP, Python and Java. I just don’t see how Haskell could not compete with those.

I agree with @dhouthoo. PHP has Laravel, Java has Spring, Python has Django. It’s not like there are not millions of libraries there that do the same thing, it’s just that there are well-packaged plug-and-play frameworks with decisions already made that are solid enough to cover your typical use case. I thought Yesod was meant to be like that, but nobody talks about it, and I don’t know it much.

On the bright side, I think writing web apps in Haskell, today, is somewhat solvable. I’m preparing a little demo, but since this topic popped up, I promise I’ll stop procrastinating on it and finish it soonish. Since I brought this up, a little teaser won’t hurt.

[emlautarom1]

I think this is being addressed from the wrong perspective. Multiple languages are as niche as Haskell and most of the ones mentioned in this thread (ex. Elm, Gleam) are even more niche, so I would not use them as reference on what to do to “break out”.

If we think about this “issue” from the other side, what would be a good reason to pick Haskell for a commercial project?

• For smaller companies, betting on JS/TS is the smartest choice since you can leverage “full stack” developers that work both on the backend and fronted. No other language has this advantage due to the JS monopoly in the browser (no, WASM is not a reasonable alternative in a startup environment).
• For mid to large companies, using PHP is one of the most reasonable options due to the maturity of the ecosystem (ex. Laravel and Symfony), again assuming that the main product is a web application.
• For larger companies, languages with enterprise support, large communities and very mature ecosystems you have Java and C#. Any other option is most likely a risk from a business perspective.
• For mobile development, the only reasonable choices are each platform’s native stack: Switft and Kotlin. You might find some JS (ex. React Native, Nativescript) or Dart (Flutter) out, but they’re pretty much irrelevant in the grand scheme of things.
• For AI the de facto ecosystem is Python.

So, why would I pick Haskell instead of any of these languages mentioned above? If you want to increase the adoption of Haskell you need to find a good use case where it becomes the “most reasonable” option. Personally, I think that it’s a great fit for internal network apps, surpassing Go which is the current popular choice.

For this use case, Haskell provides great - if not the best - tools:

• Amazing concurrency primitives and higher level constructs: IORefs, MVars, STM, Channels, Green Threads, async exceptions, etc.
• Wide range of parsing libraries, great for processing custom binary formats being transmitted over the network.
• Multiple streaming libraries with support for varied sources and sinks.
• Single binary distribution with low startup time and memory footprint (if well written).

Now, I don’t think it’s “bad” to focus in tooling, general documentation or introductory material, but it seems to me that the main use case of Haskell is very specialized types of apps which are just not massive, so these measures just don’t have the impact that you would wish for.

I think the “right” path forward is focusing on the strengths of the language and its ecosystem rather than trying to widen the range of use cases.

[hellwolf]

@emlautarom1

main use case of Haskell is very specialized types of apps which are just not massive, so these measures just don’t have the impact that you would wish for.

I concur. We should not trying to be others. There are a lot of things Haskell is for, where other languages are not even close. Trying to bridge the gaps with the mainstream use cases isa good exercise but probably not a goal to win mainstream adoptions.

[ReleaseCandidate]

@jaror

The first thing it mentions is that Gleam is friendly. Compare that with haskell.org which begins by stating that Haskell is advanced.

And both statements are accurate. Haskell is (together with C++ and Common Lisp and maybe some others) just about the most unfriendly language there is.
Important to note is that this has nothing to do with the friendliness of the community at all (as an outsider I perceive Elm as “friendly”, but not its community), but the language and at least its build tools, most importantly the compiler. What does being a “friendly language” mean? Look at Elm, which aims to be a “friendly Haskell” (if you allow ;). While I haven’t used any of them, Elm, Gleam and Roc (not be be confused with the “language” formally known as Coq) strive to be “friendly languages”, here is Roc’s (quite detailed) explanation what it means by being a “friendly language”: Friendly | Roc

Besides having a friendly community, Roc also prioritizes being a user-friendly language. This impacts the syntax, semantics, and tools Roc ships with.

[hasufell]

@emlautarom1

I think the “right” path forward is focusing on the strengths of the language and its ecosystem rather than trying to widen the range of use cases.

This is what I have a problem with.

We as a community don’t have a way to explicitly “focus” on a use case direction. Volunteers work on whatever they want.

Companies may use it for anything and pioneer a use case everyone thought of as niche.

Haskell is a general purpose language. I don’t really think about Julia or Kotlin when I start a new Haskell project.

Both extending solid pre-existing use cases and pioneering new use cases may grow the community and the industrial adoption.

What we can agree on as a (disorganized) community however are more the boundary conditions, so to speak.

Whatever you use Haskell for, you will be exposed to:

• the surface language
• GHC and the rest of the tooling
• the infrastructure (hackage, stackage and so on)
• documentation
• the community and its various spaces

Now, when it’s about the case where Haskell is lacking in a particular use case (say, cryptography, which is a real problem), then we need ways to empower people who do want to bring about change.

That’s as much about funding as it is about community processes. And I think we’re not doing too bad.

[jaror]

@ReleaseCandidate

Haskell is [..] just about the most unfriendly language there is.

Let’s change that then. I’ve been spending a lot of effort in trying to improve error messages, which seems to be a big part of what makes a language friendly. We have collected problematic messages and discussed possible improvements. There is also the error message index which has seen a lot of contributions from many people. Please do join this effort!

P.S. I forgot to mention @tomjaguarpaw’s GitHub - tomjaguarpaw/tilapia: Improving all Haskell's programmer interfaces, which is also a great effort to make Haskell friendlier.

[eldritch-cookie]

i don’t think that is possible or desirable, haskell has a ton of inherent complexity/difficulty for instance would you give up purity and do notation for the simpler/easier imperative sequencing?

the fact is in haskell you cannot claim to understand hello world without some level of understanding of monads.
we know why we accept this tradeoff but all such choices impose a friendliness penalty.
in my opinion the right way to go about expanding the user base would be to see why you already like haskell and see in which ways you can reduce friction so that a prospective haskell user also can use haskell the same way.
bonus point: you would be way more likely to be willing to contribute that.

[tomjaguarpaw]

@eldritch-cookie

in haskell you cannot claim to understand hello world without some level of understanding of monads

I’ve heard this claim from outside the Haskell community, and now from inside. I don’t understand it. What part of understanding this requires an understanding of monads?

main = putStrLn "Hello world"

@eldritch-cookie

the right way to go about expanding the user base would be to see why you already like haskell and see in which ways you can reduce friction so that a prospective haskell user also can use haskell the same way.
bonus point: you would be way more likely to be willing to contribute that.

I agree with this. That’s why I started Tilapia, that @jaror already linked.

[eldritch-cookie]

ok, you are right, if no sequencing or bind happens then you don’t need to understand monads. but this doesn’t invalidate the point, any simple program will directly or indirectly use (>>=) or reinplement or use the equivalent fmap + join. The thing is doing haskell without monads would be incredibly painful, so they increase the inherent difficulty of haskell.

[jaror]

My initial thought about friendliness of a programming language was that it was mainly driven by error messages. I’ve also been convinced that good documentation and tooling are important parts of friendliness. Language design can also have impact on friendliness, but I don’t think it is the most important factor. So, I think we can get pretty far without compromising on the language (or introducing breaking changes).

[tomjaguarpaw]

Well, here’s a program that implicitly uses (>>=):

main = do
  putStrLn "What is your name?"
  line <- getLine
  putStrLn ("Hello " ++ line)

And here’s the equivalent in Python.

def main():
    print("What is your name?")
    line = raw_input()
    print("Hello " + line)

They’re almost identical. Since no understanding of monads was required to understand the Python version, I don’t see how understanding of monads can be required to understand the Haskell version.

One might say “but to understand do notation you have to understand monads”. I don’t think so! Just look at the do notation. It’s works exactly the same way that the Python equivalent works, as far as a new user is concerned.

[This is a bit tangential, so if we keep discussing this particular issue maybe we should fork off a new thread.]

I’m doing a Twitter straw poll: https://x.com/tomjaguarpaw/status/1917230178431906276

[tomjaguarpaw]

@maxigit

But then my question is , even if you don’t need to understand what a monad to do Haskell, why would be the point of teaching Haskell to someone who does NOT want to understand a monad ?

No one has yet mentioned teaching in this thread. Are you opening a new line of discussion, or are you making a point related to @eldrich-cookie’s original claim in some way? If the latter, please explain in more detail what.

[hellwolf]

I think that “<-” is going unnoticed for Haskellers. The fact there is a difference between “let a =” and “<-” will very quickly become relevant. And it won’t be easy to explain without the fundamental concepts.

Personally, I don’t always get the urge of always wanting to dumb things down. But perhaps Haskell is a bit too “high” comparing to most of the languages. So , maybe.

[tomjaguarpaw]

Ah, well, fair enough. But I was really just interested, in this case, of investigating the narrow claim that you must “understand monads” to understand “hello world” (or simple Haskell programs). It doesn’t seem true to me, for the definition of “understand” that I use, at least.

To answer your explicit question, I have five or six hardware design/electronics engineering type folks using a Haskell EDSL for writing programs for our Groq LPU. I doubt they would say they “understand monads”. In fact I doubt they even know they’re “using monads”. (They barely even know they’re using Haskell.) For them, the point of learning Haskell (or for me, teaching them some amount of Haskell) without understanding monads is so that they can write programs for the LPU. It seems to work well!

[ReleaseCandidate]

First I should repstate that I haven’t used any of the “friendly” languages, and my interpretation of friendly is mainly this quote from Roc:

Roc’s syntax isn’t trivial, but there also isn’t much of it to learn. It’s designed to be uncluttered and unambiguous. A goal is that you can normally look at a piece of code and quickly get an accurate mental model of what it means, without having to think through several layers of indirection.

Friendly | Roc

@maxigit

I use Elm (it’s the best thing I found so far to do front end) but it stops looking friendly the minute you are actually using it.
For example, Elm “solves” the Monad problem by not having monads (and type classes). But it actually doesn’t do anything to stop the need of Monads. You still have the same problems without the nice tool solve it.

I cannot say anything substantial, just that in my experience not having “monads and type classes” at all is a fine solution too, at least it was in F# (which does have some kind of do notation equivalent) and that Elm looks fine to me. What is worse is something in the middle, like Rust does. So type classes without actually working higher kinded types. This is really frustrating, being so close to being good.

@jaror

Let’s change that then. I’ve been spending a lot of effort in trying to improve error messages, which seems to be a big part of what makes a language friendly.

Good error messages make an language friendlier, but not friendly. Rust is an unfriendly language (less than C++ and Haskell, but I guess it will catch up to them) with “friendly” tooling and error messages. So Rust is somewhere in the middle, between “friendly” and “unfriendly”, I’d say. So at most Haskell can get “neutral”, like Rust

@jaror

Language design can also have impact on friendliness, but I don’t think it is the most important factor.

I’d say it is the most important factor. The existence of compiler extensions is already enough make Haskell “unfriendly”. And the (over-) use of infix symbols. And the general abstraction level. And the existence of Template Haskell. And …
Of course there are many people who would argue that Elm’s “Haskell-like” or Roc’s syntax are unfriendly too, because they’re not “C-like”.

[hellwolf]

@tomjaguarpaw

n, I have five or six hardware design/electronics engineering type folks using a Haskell EDSL for writing programs for our Groq LPU. I

Shouldn’t we double down where we excel? What can the world gain from having another Web application framework in a rather non-mainstream language? If I may answer the original question for you, “I grew the number by SIX!”

[tomjaguarpaw]

@maxigit

In a way they don’t need understand because they are just doing a subset of Haskell in the narrow context of the EDSL and they basically just modify (or get inspired by) existing thing (I 'm not downing them, I am sure their expertise is in electronic not in programming).

Sure, but why limit programming in Haskell to people who do more than modifying an existing thing? I suspect that’s how programming works in many languages for many developers.

@maxigit

If tomorrow one of them go on holiday and decide to spend a week writing some Haskell from scratch (without your guidance) could he do anything without having to understand monad.

Probably yes, about the same they could do in Python, which they’re not familiar with either.

@maxigit

In other word, do you count them as Haskell user ?

Well, this seems like begging the question “Haskell users have to understand monads, because if they don’t they’re not really Haskell users”.

@hellwolf

Shouldn’t we double down where we excel? What can the world gain from having another Web application framework in a rather non-mainstream language?

I don’t follow. I wasn’t talking about a web application framework. I’m not sure if you thought I was.

@hellwolf

If I may answer the original question for you, “I grew the number by SIX!”

I don’t really follow this either. Do you mean by “original question”, “How to grow the (commercial) Haskell user base?”. Groq is certainly successfully using Haskell commercially.