How to grow the (commercial) Haskell user base?

Learn
127

If there was a compelling reason then Haskell would already have made a dent in this space the way that Python, Ruby, Javascript, ASP, Elixir, Java, Kotlin, Clojure, and Golang already have. By definition. (Also, you’re a programmer: you’re supposed to be able frame logical arguments correctly. And the question is not why someone would select Haskell over PHP but why Haskell would beat out ALL those other, much more established options.)

Yes, there are reasons to use Haskell - but there are also reasons not to. And the market has shown that it finds the cons more compelling than the pros. That’s not going to change just because you think it should.

1 Like
128

The real world is not an early 90s cyberpunk novel. This is NOT something that any company or investor ever considers when choosing a programming language. (And if they did, then the winner would always be APL. Or maybe Forth. But probably APL.)

Also… You think that “products” carry source code???

I can’t respond to this in anyway that its both truthful and civil…

Also: Haskell isn’t that hard to learn. The accepted learning time for a reasonably talented programmer is about two months. I’m rusty but I got to the Markov Chain and binary tree stage in a few days of part time doodling, so two months seems to production code seems very reasonable to me. I suspect that an experienced Scheme or Clojure user would have an even easier time. So, no, if the Empire Of Evil did retrieve the source code for Skynet from a downed DJI drone, that it was in Haskell wouldn’t be much of a problem. (Except of course there would be no source code: This Is Not How Computers Work.)

129

Very interesting discussion! From what I’ve read, folks are split mainly into two strategies:

  1. Finding a niche
  2. Expanding User base → Commercial base

I think finding a niche is a bad strategy. Having a niche for footing is a great thing, only if you can hold on to it. Lacking the manpower to man the guns means you’re doomed to loosing it.

I personally adhere to the expanding the user base, to then have it organically expand the commercial base. Whenever I get the chance of speaking to someone with any decision making power, I always dig in the same direction, and one-hundred-percent-of-the-time-no-misses-every-single-one-of-them has always told me the same:

a. They all recognize the strengths of Haskell.
b. They’re all trying to incorporate them into their workflows (fp-ts, https://effectful.js.org/, etc).

So why not cut the crap and use Haskell instead? It’s too difficult finding talent. That’s it.

So the question would be: why isn’t there more Haskellers? For me it’s easy: high entry price (I also really liked one response calling intermediate Haskell a wasteland).

Let me tell you a very short story.

Back when I was in college, mind this were the times when college taught pascal and C, I took a course on learning systems, back when LLMs hadn’t infected everyone’s minds. One of the assignments was writing an inference engine for an expert system, but with a twist: we had to write it using Erlang.

Er-who? Functional what? Where my first reactions. But in no time I already had something running. I remember thinking how much I liked the language, to even propose using it at the job, because in third world countries we work while studying, but I digress. I was working at a networks company that specialized in juniper networks, but had a couple of contracts with local telecoms. I was building the backend for their SMS routing system, in C++. I’m only telling you this because it’d seem to be the perfect use case for Erlang. Their response? That’s all very nice, but we can’t find people to work on that.

Now fast forward 10 years. Haskell comes across my way, and you’ll probably think that with that much experience under my belt, it was a breeze to learn. Wrong. Man did this language frustrated me. I had to relearn it like 3 times, because every time I thought I finally understood it, I quickly realized I didn’t.

So the real question is: how is it that a kid with little experience could build something really fast using a functional language he didn’t know, while that same older kid, with much more experience, struggled so much with another functional language?

For me the answer is simple: that same flexibility of doing things the way we want, that Haskell encourages and we all love, is also deeply hurting it. Don’t get me wrong, I think it’s a non negotiable and I love being able to mix and match and not having a beaten path, now that I understand the damn thing. But that’s it, as a newcomer, not having a beaten path to follow, is highly detrimental for the experience:

  • Lazy or Strict?
  • Containers? Vectors? Arrays? Strings? ByteStrings? Text? Boxed? Storable?
  • Effects systems.
  • You heard optics are cool? Here are 5 different libraries, choose one.
  • Large etc we all know.

On the other hand, Erlang is very focused. Now that I think about it, Haskell feels a little like that genius kid, with ADHD robbing him his progress.

But well, what can we do about it? As much as the language lacks manpower, at the same time it has a lot of experts from whom I learn a lot every time I read what they post. I think it’ll be very beneficial if they could come together and build an “expert system” that would set up projects for newcomers by asking them simple questions. For instance: I’m building a web server → Do you prefer simplicity or type safety? → Are you using a database? → What engine? → Do you want an ORM, or just a query builder? → etc etc etc. After they’ve answered all that a project is set up with sensible defaults and no monad, effect, category theory shenanigans. Just a project that already runs using what the user asked for and with simple example functions they can build on.

Additional thoughts:

  1. On Small companies

I’ve read in some comments before mine people making the case that Haskell is not well suited for small companies. I think it’s the complete opposite. I think it’s where Haskell can shine and make a substantial difference.

Why? From experience, any language is god for any task, if you had infinite resources and time to polish it. Nothing works better than a well polished C program. But that’s it, small businesses have very limited resources. What’s better than a language that gives you a lot of certainties, that claims to work if compiles, that can check edge cases for you with property testing, when operating under resource constraints? That means less polishing time, less resource requirements.

  1. On the marketing issue:

I agree. If Haskell is marketed as advanced, meaning you must have years of experience on something else to begin with, then keep in mind folks with that much experience in that something else are probably proficient with it, and wouldn’t be inclined on sacrificing that muscle memory.

7 Likes
130

Decompilation of machine code into human comprehensible code is easier when you know the target language.

Humint and Elint attacks for source code in theory should never succeed, but having the code separated into code written in the eDSL as well as the machinery that actualizes the eDSL provides a level of protection; you have to get them both and they can be separate codebases.

Either case:

Anduril will probably be the largest Haskell using firm in 5 years, given that Meta seems to be rewriting it in Rust. maerwald claims that GHC is a black box and cannot be secured, but that’s not true if you have strong GHC contributors or have contracted the consultancy doing a ton of work on GHC. Tweag is now owned by Modus Creates, which is based in Reston, VA, neighboring American government contractors, and SimSpace in Boston sells cybersecurity (and possibly offensive tools) to the DoD.

Haskell as an Ada seems solid, but for many of us here, it’s at best a cloud with a silver lining.

The next strongest Haskell space seems to be Fintech, given Standard Chartered’s Mu and Mercury’s 3 billion or so valuation. This is actually where we can best leverage Anduril giving credibility to industrial Haskell; if the American MIC thinks Haskell is good enough for their high-security applications, why shouldn’t it be good enough for Fintech, where mistakes can result in the loss of hundreds of millions of dollars or more?

Here, we should try to encourage defense users to extend their protective wing to at least American Fintech companies, because it enhances Haskell’s industrial credibility and it enhances America’s cybersecurity.

The book I would encourage users to read is Clayton Christensen’s The Innovator’s Dilemma. It’s been a while since I’ve read it, but it explains how disruptive technologies start by finding a niche (defense users are that niche), then expanding beyond that niche as economies of scale develop the technology (I estimated the cost of Python’s FOSS ecosystem at around 100 million, but other sources state its value is estimated around 665 billion).

If you think Haskell exists as a whole, we’re winning in American defense, we’re doing okay in Fintech, but are completely niche in enterprise software and web development.

We should try to make it so that Haskell is a reasonable standard in Fintech, and is doing adequately in enterprise software and web development, but that requires spillover first from the defense establishment into Fintech, and then from Fintech into everything else.

1 Like
131

The discussion is for sure interesting and partecipated, thanks @malteneuss.

Everyone, please try to stay on topic and consider opening new threads for tangent discussions. Discourse isn’t well suited for threaded discussons (Reddit, HN, …) and the more focused you are, the easier for a reader is to follow the conversation.

1 Like
132

This topic is about changing that, isn’t it? In a topic about how to grow the democracy, you are saying: Let’s give up on democracy, because we already have a king.

No. That is a statistically illiterate way of thinking. Again, as useful concepts as they are, enterprise or web applications are huge fields with a wide variety of requirements. So yes, replacing just a portion of PHP usage there would be a huge success. This is not a winner takes all type of scenario.

2 Likes
133

Again: you may think that learning Haskell is hard. And it is hard for the average 110IQ web grunt. But if the Iranians or Russians get their hands on tech they want to reverse engineer, their people will be +140IQ elites. Haskell will not be a problem.

Haskell is not a hard realtime language: it isn’t an Ada replacement. (Also: the US defense industry barely uses Ada for new projects anymore - they prefer C/C++ because programmers are easier to find.)

IYes, success can come from taking niches - but Haskell isn’t right for the generic defense niche. Because it isn’t a realtime language, among many, many other reasons. And if Haskell was going to function as a “disruptive technology” that would have happened years ago.

Yes, Anduril have hired a very small number of Haskellers for very specialised roles. Extrapolating from this is, to say the least, problematic:

134

Yes, the thread is. The post I answered wasn’t. It was just meaningless wishful thinking with no proposed course of action.

Ok: let me try to make this simpler for you…

  • I employ PHP programmers
  • I decide I want to change languages
  • The point I made - which you apparently can’t understand - is that I have a vast number of options open. Not just Haskell.
  • And you’ve added a new error to that with “enterprise or web applications are huge fields with a wide variety of requirements”. Well, yes. And that has always been true. And Haskell has always taken about 0.01% of this market. Again, reality isn’t going to change just because you want it to. The future isn’t always like the past - but you shouldn’t expect change without an intelligent reason why that change will occur. Now, if a new Haskell framework appeared that did truly amazing things, THEN you could make an intelligent argument that Haskell might be more widely used in webdev. But at the moment you are literally arguing that enormous change should happen without an new factor to cause it. This is not how reality works.
135

@jazzlobster, thanks for looking at that article. Having looked around again, these may also be of interest to you:

136

Short answer: Anduril is talking a lot about embedded Haskell, this implies either forked and buffed (classified) Linear Haskell, or eDSL to C pipelines along the lines of NASA’s Copilot. They’re real-time, one way or another.

For defense uses, it seems that Palmer Luckey and Travis Whittaker are mostly satisfied with their defense Haskell from social media posting, but the actual details are beyond me (I’m just a hobbyist OSINTer) and probably you as well.

In the same vein, people outside clearance land can’t really make defense Haskell something we should focus on supporting and developing. But it’s reasonable for us to attempt to leverage defense Haskell for other fields, namely the finance and fintech fields, by trying to cajole defense Haskell to release (civilian-grade) libs for fintech and finance users, then using it to strongly market Haskell to fintech and finance users.

For people like me who are politically opposed to Anduril et al, the best way to fight them is to have a robust civilian ecosystem, and the most promising niche is fintech and finance. Success here will eventually lead to spillover into enterprise and webdev fields.

137

You are saying that there is an X field of programming, and you have to “beat out ALL other options” to enter it. Great, but it is only fair if I’m allowed to pick X too. So for X, I pick: the whole field of programming. Following your logic, we have to then ask a question: if Haskell beats everything in the whole field of programming. Obviously, it doesn’t, so we can pack up and go crank some PHP instead (which also doesn’t beat everything in the whole field of programming, but I guess it’s already there).

I guess my sin is picking different X (PHP applications) than you, which is not allowed.

Yes, you do, but I have a hunch that the majority of people in that situation don’t entertain even a fraction of those options. It is rather to address their current problems with their current language. It is meant to be an upgrade, not a revolution. And it is also a career choice, which is pretty big deal.

That is to say, it is hard to enter the mainstream because the system (the market) is working very hard to maintain the status quo. Off the top of my head, I can name four languages that without a shadow of a doubt entered the general purpose programming market in the last decade: Kotlin, Go, Rust, and TypeScript (for sure I’m missing something). TypeScript and Kotlin are easy, just upgrades. Rust addressed one of the major problems in low-level programming (Which is to say, an upgrade. Yes, it does have some nice and modern features, but without its memory safety, I don’t think it would make it.). Go might be an odd one here, depending on how you look at it, but that’s one language in a decade. Looking at it that way, it does paint a rather bleak future for mainstream Haskell.

That is to say, I don’t think Haskell is being beaten by PHP or Go. Rather, Haskell is just not even in this fight.

I’m saying this as somebody who, in the past, could use Haskell in production, easily and for the benefit of the project, but decided against it. That decision was motivated by my professional standards, I couldn’t leave the company with a tons of Haskell code, in a country where there are virtually no Haskell jobs. But with my experience of writing prototypes in Haskell and rewriting them in Java, you will have a hard time convincing me that Java beats Haskell (But again, it’s programming, in some scenarios it beats Haskell badly, I’m sure of that).

Nowhere in this topic have I been arguing that. The most out there statement I have made here is that Haskell could compete with the likes of Java or PHP. And that I don’t believe there is no “compelling advantage” to pick Haskell over PHP (which I admit - this is not my mother’s tongue - I take as a significant but not necessarily conclusive factor, while you seem to use it as a definitive factor).

Also, take a chill pill, I have just asked you a question. Your statement sparked my curiosity as to why you have said it. I don’t need to address global food insecurity problems to say something on an internet forum. With many things you said here, I agree. I love the idea of Haskell by example, I’d happily contribute a chapter or two to that, if something ever comes out of it.

2 Likes
138

Again, this makes no sense. If someone is casting their net wide enough to consider Haskell to replace PHP, then yes, they are generally going to consider several other alternatives.

Me > But at the moment you are literally arguing that enormous change should happen without an new factor to cause it. This is not how reality works.

You > Nowhere in this topic have I been arguing that.

I’m afraid that the argument that you have actually made is not the one that you intended to make. You have argued that Haskell can take over from PHP (?!?) without proposing any new libraries, language changes, etc. You have just kept insisting - even in your last post - that it can happen. So yes, that is the argument you have been making.

And that I don’t believe there is no “compelling advantage” to pick Haskell over PHP (which I admit - this is not my mother’s tongue - I take as a significant but not necessarily conclusive factor, while you seem to use it as a definitive factor).

Again, you seem to be unable to follow the basic argument. So again -

  • The battle is not PHP vs Haskell, but Haskell vs every more popular webdev language. This is the real world. You might not like it, but companies switching from PHP have a long list of languages to try that are much more widely used than Haskell. Even if they want to use fp, there are options that have more much traction - Clojure, Kotlin, Elixir. The idea that anyone is going to switch from PHP to Haskell without considering these is just a bizarre fantasy.
  • It doesn’t matter if you think that Haskell is the best webdev language - if that’s what you think. It doesn’t even matter if it really is. What matters is that 99.99% of the market long ago decided it isn’t even worth considering, and that they aren’t going to reevaluate that decision just because you have made a post on discourse. Now, if you had an intelligent plan to persuade them, that would be worth listening to. But obviously you don’t, or you would have revealed it.

Also, take a chill pill,

I hate to tell you this, but the fact that someone thinks your arguments are unconvincing is not a sign of lack of “chill”…

Honestly, this is pointless. You’re proposing nothing.

139

This topic can get heated because we’re passionate about giving Haskell the best shot at growing!

The passion is good, having strong opinions is good! That said, let’s maybe take a step back and let the topic simmer for a bit before we continue.

There’s no need to close the topic or anything dramatic like that, it’s still a useful thread and one we might want to come back to, let’s just take a breather for a bit.

15 Likes
140

…hmm:

…so then how will asking that question here actually be useful? Or are we expecting everyone who doesn’t use Haskell to register for this Discourse just to leave a comment?

If we truly want to know what to do to grow the Haskell populace, we need to find some way to ask those who don’t use Haskell, not “mostly the same 20 or so people” on this Discourse.

141

So what should we then do with all the comments that Haskell should have been strict by default? Here’s one option - have the authors of those comments read More points for lazy evaluation:

  • (But lazy lists were included in SWI Prolog as an option for streaming in 2019.)

There is no “free lunch” to be had from being strict by default - it has its own costs.

But if they’re still not convinced, here’s some more direct evidence to the contrary:

A search for "strict Haskell" does find this concise presentation by Alexis King:

Laziness in Haskell – Part 2: Why not Strict Haskell?

…but surely that and similar content alone cannot be the reason why no strict dialect of Haskell has ever seriously challenged Haskell since 1990 - if even one in one hundred people dissatisfied with Haskell’s non-strict semantics over the last thirty years wrote a line of code for such a dialect, it would now exist (possibly instead of Rust).

Then there’s Mu:

…whose front section is apparently now being replaced with GHC (no, I don’t know the specific details). For ease of interoperability, it seems SC has chosen to keep Mu’s syntax as close as possible to that of Haskell - also quoting from the reference in ReleaseCandidate’s post here:

So is this - finally - the sought-after evidence that Haskell being non-strict was…a mistake? And Haskell’s designers really should have made “the pragmatic decision” instead (strict/sequential semantics)?

Hmm - “pragmatism” ; I recall commenting on that in another “long and winding” topic…there it is:

…and back in 1987, there already was a functional language with not just strict, but sequential semantics (due to the “pragmatic” choice of using effects directly). So what would have been the point of introducing another functional language with similar (strict but pure) semantics? It’s in large part due to Haskell having non-strict semantics that the benefits of purity can now be proclaimed with such certainty for all to hear (and read).

But as I’ve also commented elsewhere:

Therefore all comments about Haskell’s non-strict semantics being the wrong choice in 1987 and since that time can be ignored.

142

There is not a single pure functional programming language after Haskell (which has a user base at least as big as that of - whatever - Idris), which is lazy.
Every new “Haskell dialect” is strict: Elm, Idris (2), PureScript, Unison.
Just ask the users of other (pure) functional languages, why they don’t use Haskell.

The biggest advantage of Haskell is still its (relatively :wink: large user-base and library ecosystem, compared to many other functional languages (which aren’t Scala or Elixir or F#).

It’s the other way 'round, Rust is one of the big reasons (another one being added “functional stuff” to almost all other languages) why functional languages (and 'specially Haskell, less so Scala) in total lost momentum during the last 10 to 15 years.

143

By “Haskell dialect”, I mean “substantial common syntax first, semantic similarities second”. That immediately excludes Scala (it has ML-based syntax, with semantic features of Haskell - type classes, etc). As for the other three:

  • Elm - it’s niche is the WWW; it isn’t general purpose;

  • Idris - if it was in widespread use, its most distinguishing features would not be needed in Haskell: people could just use Idris instead;

  • Unison:

  • F#: ML-based syntax;

  • Elixir: ML(ish?)-based syntax (looking at its case-end expressions).

Just ask the users of other (pure) functional languages, why they don’t use Haskell.

But despite that:

The biggest advantage of Haskell is still its (relatively `;-) large user-base and library ecosystem, compared to many other functional languages (which aren’t Scala or Elixir or F#).

So again, all comments about Haskell’s non-strict semantics being the wrong choice in 1987 (and since then) are irrelevant.

Rust is one of the big reasons (another one being added “functional stuff” to almost all other languages) why functional languages […] in total lost momentum during the last 10 to 15 years.

If it isn’t just Haskell in decline as a result of those changes, then Haskell would be affected no matter what its evaluation semantics. Moreover if it was strict in 1987:

  • Haskell would have then had to be immediately competitive with the more mature Standard ML implementations of that time;

  • and people would question even more the sensibility of starting a second functional language that differed primarily in syntax (“don’t bother with such duplication, just use SML already” ).

144

Python’s Map type for FP is lazy, Rust’s iterators are essentially lazy.

Laziness, at least according to more popular languages, is good for FP.

If anyone ever asks you if laziness ever did anything for you, just say “map on Haskell lists is O(1) if you’re only using a single element of the list”. Blew a Julian / OCamler’s mind, then they ran off to Agda :wink:

IMO, while there are good arguments to be made for strictness in terms of runtime simplicity, asking for Haskell to be strict has a slight tinge of asking for Haskell to be written entirely in IO (I.e, FP likes laziness, imperative programming is fundamentally strict)..

2 Likes
145

Yes. Well - almost: you need to concentrate on the subset of programmers who are convertible. Not, ahem, realtime people or PHP coders. The sweet spot would probably be people who already know or are thinking of using Clojure, Kotlin, or Elixir.

Also: I already know the answers to that question, because until recently I was one of those people. And not just a random one, but one of the people most likely to learn a new language - and Haskell was at the bottom of my list. I only played with it after C++, CLOS, Scheme, Groovy, Scala, Python, Ruby, elisp, Perl, Smalltalk, Golang. I’ve even read the tutorials for Prolog, Forth, APL, Rust, Clojure, Lua, and Julia first - and I’d used XMonad. I only tried Haskell this time because I was looking for a fun language and Rust and Julia are boring, a Clojure REPL triggered my Java stacktrace PTSD, Kotlin seemed too much like Scala and not enough of a challenge, Ocaml syntax is ugly, and choosing an APL dialect was confusing enough so that I downloaded GHCI while thinking it over.

…Reasonably, I was in the 5% of programmers you could most easily attract. And if I’d tried a more stable Clojure REPL, you wouldn’t even have got me. THAT is how bad your marketing is.

And I’ve talked to other people since then and their reasons for avoiding Haskell are the same as mine:

  • Again - You have no decent quick introductory tour that SELLS the language. A friend of mine was interested enough based on what I told him about Haskell to look for introductions and he found nothing a wall of verbose and tedious dull. EVERY rival did this job better than you do.
  • You need tours/tutorials for key libraries too. Not the ones that YOU think are important, like Lenses, but that the ones potential users will care about. Webdev, parsers, OS integration, etc.
  • You generate FUD rather than closing it down. Eg lots of bizarre rants about monads, no debunking of memes like

..Which would be easily handled by that language tour.

It’s also worth taking a look at

As a community, you are the kings of bad marketing. Emperors. Gods. I’m an easier sell on the language than 99% of programmers and you only got me by chance. You won’t take the simple, obvious, easy actions that your rivals took years ago.

Anyway - I’m done now. I wouldn’t even have posted this unless you had asked such a smart, sane question.

5 Likes
146

I have wondered whether in the medium term, a good way to go would be to improve the interoperability and compatibility with Rust.

There’s not a great deal of formal synergy between the two languages, but I think that there is some social synergy: the Rustiest of systems programmers might be drawn to Haskell if they wished to dip into very high-level programming, and, conversely, the functional programmers who use Haskell are likely to want to use Rust if they need to dip into systems programming.

4 Likes