How to grow the (commercial) Haskell user base?

Learn
106

It’s interesting that at Bellroy, we lean on very few of these things, but are big fans of Haskell. Single binary distribution is probably the only one, but because of AWS Lambda we had to use musl libc, which (eventually) pulled us into the Nix universe. That would be a big ask for a new potential Haskell user, and we didn’t go zero-to-Haskell in one jump.

The thing that sold us on strongly-typed ML-family functional programming was a really successful experiment with Elm, and then asking “how can we get more of this?”. But these days, Elm is not as exciting as it was (perception of stagnant core language, etc) and I don’t think we can rely on it as an on-ramp for Haskell as much as before. Purescript also seems pretty quiet, too, and Haskell frontend is halfway through the transition from GHCjs to native JS support. Once that finishes, I think offering relief from the usual JS-based frontend world will be a great pitch.

If I were to ask my colleagues what they thought were the most valuable things we get from Haskell, I think most of the answers would fall under a few broad themes:

  1. Enforced consistency: Just newtype-ing the zillion different record ID types in a business eliminates so many bugs. Other fundamental Haskell features like exhaustiveness checking in case expressions also have extremely good power-to-weight ratio. But unlike the “simple Haskell” advocates, we’re quite happy to take on something like the servant library family. Getting enforced consistency between the API definition, the generated OpenAPI documentation, the implementation of the endpoints and the API clients is worth learning the typelevel features that it requires.
  2. Local reasoning: It’s much easier (compared to other languages) to know what a piece of code needs and does just by looking at it, without having to keep global state in our heads. The classic split between pure and IO-using code is a big part of this, but also the fact that the type signatures track what data is in a “reader”.
  3. High average library quality: If there’s a library on Hackage, and the library is nontrivial, there’s a good chance that it is solid. This is partially because library authors also benefit from №1 and №2 above, but because the use of advanced features tend not to leak across library boundaries.

Some comments on language complexity and “advanced” libraries:

  • We are very careful to set the upper bound of the Haskell features in common use in our codebase. (Roughly: GADTs are OK where genuinely required, you might see the odd Rank-2 function type, but the majority of the code is fairly simple. servant is probably the only library doing serious type-level stuff.)
  • On lens: We make heavy use of “basic” lens (nested record access and update, injecting errors into prisms, extracting and summarising data from complex structures). This did mean helping all of Tech Team through Optics By Example, but has paid off handsomely. Occasionally we need to do more advanced things, but they’re rare and heavily commented. (One example: using Control.Lens.Plated to walk and rewrite a complex syntax tree.) Contra @BurningWitness, we almost never use lenses to wrangle “state blobs”, but still find them incredibly handy.
  • On effect systems: dynamic dispatch is extremely attractive to us, primarily because of the dream of effortlessly swapping in test versions of effects where the real version would force us to interact with remote services. At the moment, we use “handles” of the form data FooHandle m = FooHandle { action1 :: Arg -> Arg -> Arg -> m Results, action2 :: ... }, but may eventually refactor towards an effect system library.
13 Likes
107

Why? I don’t see the connection between musl libc and nix.

108

How do you suggest we measure success? What are the metrics?

Because without a clear goal, it’s just a feel-good discussion. If we’re talking about growing commercial Haskell, then metrics like:

  • Number of companies using Haskell in production
  • Number of job listings requiring or preferring Haskell
  • Number of libraries downloaded or actively maintained
  • Growth of new contributors to core libraries or tooling

…would make sense.

Are we targeting direct competitors like OCaml?
If so, we should measure how many people choose Haskell over OCaml for greenfield projects, or how many OCaml companies migrate.

Or are we trying to evangelize FP in general?
In that case, metrics like how often Haskell is mentioned in FP onboarding materials, tutorials, or courseware (compared to F#, Scala, or Elixir) might be more appropriate.

Just my 2 cents.

1 Like
109

I personally want to grow the commercial user base to get more contributions to the ecosystem. A central measure of that is the number of industrial sponsors of the Haskell foundation (multiplied by their contributions). That misses direct contributions and contributions via consultancy companies, but those are hard to measure anyway.

6 Likes
110

Once we started using Hackage libraries that needed to FFI to libraries not in the standard Lambda runtime environment, we decided static linking would be the easiest way to ensure the libraries are available. Completely static linking requires musl libc, and my previous experience (which may be outdated) is that the easiest way to get a cross-toolchain set up and working is to use Nix.

I should also mention for completeness that AWS Lambda can now use OCI images as its packaging format, which sidesteps the main reason we went down this path.

111

You neither need nix nor a cross compiler to build fully static binaries (for x86_64/ARM64 Linux at least). You can just use Alpine.

3 Likes
112

Hello,

I’m someone who has been following Haskell for some time now, although I haven’t built anything serious with it yet.

I feel that Haskell has moved beyond its original niche of language research but hasn’t quite found a new one.

Some examples of other languages and their niches:

  • PHP, JavaScript for web development
  • C for embedded systems
  • C++ and Rust for performance-critical systems
  • R, Python, and Julia for data analysis
  • Java and C# for enterprise applications
  • Go for cloud and microservices

Haskell can also be used in many of these areas, but it’s harder for me to say where it fits best.

Many other languages have adopted ideas and concepts from Haskell, so I believe it’s important for the language to continue innovating and developing new programming paradigms, especially as the programming world keeps evolving.

I also believe Haskell could excel in data analysis, thanks to its strong type system and concise syntax. This area has been gaining momentum recently, and since data analysis involves a lot of math, Haskell seems like a strong candidate.

I agree with others who think Haskell is missing some guides and tutorials for newcomers. More beginner-friendly content online would help increase its visibility and adoption.

There are a few areas that could be improved, such as the Stack vs. Cabal situation, which can be confusing for newcomers. Also, the tooling might feel heavier compared to other languages.

Other than that, I think Haskell is doing great. The language is elegant, has a solid runtime with good performance, and the ecosystem around it seems strong. There are quite a lot of libraries available for a community of Haskell’s size.

Thank you to the Haskell team for the great work so far!

8 Likes
113

Julia, R, Mathematica and Python are already fighting for that niche. And the Julia people have raised around $40M in funding. (Read their wikipedia article - their investor and ally list starts with General Capital and then goes crazy - they have the Zuckerbergs, Boeing, and Williams Formula One.) I really don’t see any hope for substantial gains there. And “We have a better type system!” isn’t a pitch that will make headway with typical data scientists.

Every well defined niche is taken and Haskell doesn’t have a compelling advantage in any of them. What it could be sold as is the language for tricky projects that don’t fit well defined niches - again, start-up juice. It’s fast to develop in and the type system means that your prototype stands a much better chance of evolving into production code. It’s not a big market, but it’s possible and it’s better than nothing.

Also, in terms of actual things that can be done -

  • Competing with Julia for data science could only be done if people put a lot of effort into libraries. A lot. Remember that the Julia people have literally tens of millions to spend and that they already have momentum. Haskell would need thousands of hours of effort by people skilled in data analytics to compete. Can you reasonably make this happen? If not, you’re just hoping - and hope, as they say, isn’t a strategy.

  • “Startup juice” just requires making senior programmers more aware of the language. A fast language tour, a few articles - a few tens of hours of effort, doable.

3 Likes
114

I think the business pitch is more, if you’re willing to rely on a remote workforce, there are a lot of highly-skilled Haskellers willing to work for you.

That said, Haskell is essentially an advanced FP Java; it’s an applications language first and foremost providing advantages in development speed, safety and security, and maintenance.

But of course that brings to mind:

“Hire the best programmers and make them program in Simple Haskell”

115

Just no. No with a capital “Hell.” Asking companies to accept a shift to offsite coding and a super exotic language won’t work. And the companies that already tolerate offsite coding typically do so to keep their costs low and favour languages that Indians fresh from university will know and are seen as safe.

…I’m obviously favourably inclined towards Haskell. But I’d never take a risk like that - not unless there were exceptional circumstances. Eg you need X in a hurry, it’s a standalone component, and you have access to one of the world’s greatest experts and he wants to do the job in Haskell and has before.

Otherwise you are multiplying risk in the development process. And that’s something you never do.

1 Like
116

Surprise surprise, Haskell is being taught in Indian universities (for the same reasons it’s taught in European universities) and there’s a burgeoning Indian Haskell community.

1 Like
117

I don’t see how that could be true. There is no compelling reason to write your next boring backend in Haskell instead of PHP? How come?

Also those “niches” like web development or enterprise applications are humongous. Even 1% of it is a lot.

1 Like
118

TBH Haskell already is competitive in two niches, both based on Haskell’s ability to provide high levels of safety.

  • Fintech. While IOG and other cryptocurrency-related firms aren’t doing that well, Standard Chartered is still using their custom Haskell dialect, and Mercury’s backend is mostly Haskell. And Juspay’s essentially leading the Indian Haskell space.

  • Defense. It’s not only Anduril that’s a known user, but the USAF was listed as having Haskell jobs for a while, and SimSpace provides cybersecurity solutions to the American Department of Defense.

The cyberwarfare space, as far as I understand it, is changing because while the US (and certain American allies) used to have an unchallenged dominance in network warfare, the Chinese at least are well-funded and have no difficulty getting their best and brightest to work on government projects. A PLA colonel a while back stated that cyberwarfare was essentially mutually-assured destruction due to the difficulty in securing systems (and they themselves get hacked for useful technologies and information by the Indians and Americans).

The Biden White House’s push toward trying to get memory-safe code via Rust should be seen in this light; what Americans would call adversary capabilities are now advanced enough that backdoors and negligence are now a strategic problem.

Haskell plays into this because of its strong type safety and its culture of rigor, it is ergonomic enough that it is a good competitor to Java (or even Python) and a reasonable default for medium-performance enterprise systems given its decent performance characteristics (just don’t overdose on free monads or fail to read the fine print on deep stacked monad transformers).

3 Likes
119

True. The business risks associated with picking a language that’s not in the top 20, is hard to learn, hard to master and where a fair amount of libraries are the product of PhD thesis… is often understated.

And, tbh, it only hurts adoption.

2 Likes
121

I think if some state actor is motivated enough they’ll put in the resources to learn Haskell. There’s all manner of malicious code for esoteric hardware that the average programmer will never see. Someone could make a compelling business case for type safety and ease of refactoring, knowing when your code can access IO or secure information flow (lio: Labeled IO Information Flow Control Library). So when it’s someone you know and that’s in your web of trust and you’re collaborating on not making mistakes, and trying not to make Heartbleed sorts of errors it’s great. If you use contractors and you want to make sure they didn’t put some sneaky IO it’s easy to mechanically check if the code is pure, or uses unsafe/FFI/IO/etc

But if bad guys have your code it’s all over but the crying.

Where Haskell is lacking is rigorous testing of the cryptographic libraries and testing of outside threats trying to break the code. GHC also doesn’t bootstrap, so you have a dependency on some binary that came from somewhere or you need to go back to an ancient version and successively build newer versions, which is less than ideal from a secure build standpoint. Neither, I’d assume, are trivial and I think both would need to be tackled to be really serious about the secure computing angle. The report was also circumspect about GCed languages.

The space ecosystem is not immune to memory safety vulnerabilities, however there are several constraints in space systems with regards to language use. First, the language must allow the code to be close to the kernel so that it can tightly interact with both software and hardware; second, the language must support determinism so the timing of the outputs are consistent; and third, the language must not have – or be able to override – the “garbage collector,” a function that automatically reclaims memory allocated by the computer program that is no longer in use. These requirements help ensure the reliable and predictable outcomes necessary for space systems.

I wonder if this requirement could be satisfied by linear types?

1 Like
122

This is actually something defense users can contribute back to the Haskell community at large. Given the nature of their work, their codebases likely see periodic audits by credible and highly competent cybersecurity professionals. A full audit of Haskell cryptographic libraries is likely unreasonable, but for Fintech users, it’d be quite reassuring to know that so-and-so defense company (or security agency) certifies that foo-bar-baz crypto or TLS library is safe for commercial use. This would help encourage Haskell use by Fintech users.

Asking for Haskell libs to be CMVP-certified is probably too much, but how about FIPS-140? Or is there a technical reason this isn’t a valid suggestion (i.e, FIPS-140 applies to the .dll, not to the library source code)?

Also, regarding state actors, there’s been rumors circling around Intel Management Engine for a long time, including the fact that the NSA, on older versions of IME, made provisions to disable certain features of the IME. As the Chinese switch to RISC-V, they’re making public denouncements of Intel based on purported backdoors. Take that for what you will, but I think generally Western users shouldn’t expect to be proof against their own intelligence agencies (and there’s a good argument they shouldn’t care).

As for source code, there’s a difference between the entire codebase being leaked or someone leaking part of the codebase. If the leaked part is based on an eDSL, it could very well be useless because the part of the codebase that explains what the leaked part actually does is still unknown.

Overall, Haskell is incredibly suited for security-conscious uses, and I worry about Haskell undergoing a process of Ada-fication, wherein the defense users end up eating the rest of the community. Anduril, for instance, had a speculative valuation around 28 billion, which is almost higher than Standard Chartered’s 34 billion market capitalization at current exchange rates and prices. Moreover, Anduril is best-positioned to thrive in present economic turbulence among Haskell firms, given that it sells to the US government in an industry characterized by gross inefficiency, and has strong links to the present American administration (which has been a topic of ire among some Haskellers).

It’d really be a good form of Corporate Social Responsibility if any of the defense firms were to burnish their community image by paying for or providing the civilian-level vetting of crucial security libraries.

123

That’s a very bold claim with little evidence I’m afraid.

GHC is a black box and not a verified compiler. All the cool security projects (like Everest, although somewhat dated already) use other things. We have little to no knowledge how to write side channel resistant code, because again… GHC is a black box.

The only interesting things are information flow control (IFC) and mandatory access control (MAC) libraries…one was linked above.. but these things are possible in Java too (see Jif).

1 Like
124

And guess which 28 billion dollar company is funding Well-Typed?

At least for American defense sector uses, Haskell seems golden. For people who oppose Ada-ification, the question is how to move from the strong defense niche to the fintech niche, and from the fintech niche to wider enterprise uses.

To me at least, Haskell is a promise of a world where we’re not all sitting on cyberwarfare time bombs, where security professionals no longer discuss cybersecurity as based on “mutually assured destruction” due to gaping holes in software and hardware ecosystems.

Realizing that promise is one step at a time.

125

I am not sure what the original post from LIamzee meant to say.

But I want to chime in that while the GHC’s runtime might be a black box and hardly something “certifiable” security-wise, its type system is robust, and you can find use cases in DSLs where safety and, hence, security are important.

4 Likes