[Call for Ideas] Forming a Technical Agenda

Haskell Foundation
11

Yeah I see people piling on in this thread with their favorite issues. I think it’s very important that HF not just go laxer-focussed on any one issue or other, but instead look at the overall functioning of “the machine” with all it’s disparate volunteers, techniques, etc.

For example:

  • A lot of people want various things with base / the standard library, including more stability. I think a lot of these goals are irreconcilable in a single library, and this and not social/political issues is why we’ve seen endless discussion of this stuff that goes nowhere. I want to seebase` broken and up and lots of it decoupled from GHC so we can actually see ecosystem-level experimentation, and yet also more stability. The fine-grained base avoids collateral damage from fast-evolving or competing core infra also making life miserable for things that just use the uncontroversial bits.

    The “alternative preludes” I don’t think do the topic justice because a) they are so big as to be geared towards end applications rather than the fine-grained libraries that are our ecosystem’s bread and butter, b) since they must use base they are forced to paper over issues rather than extricate them properly.

  • Upgrading being hard I think directly relates to base being too big. base's every increasing major version creates are ripple of busywork throughout the Cabal-verse. A finer-grained base would “free” the highlighly stable portions from the ever churning bits.

    (Fun fact, @snoyberg himself written that (I paraphrase) Rust doesn’t really need a Stack. He ascribed that to a culture of less breakage—I point to Rust’s std never having a breaking change in particular. I think that’s an over-correction that will cause std to accumulate mistakes and gotchas faster than base has, but perhaps is the lesser evil. Breaking up base is analogous to Rust’s core vs std, and I think wit versioning should allow for I think the goldilocks sweet-spot in between Rust’s “never break” and Haskell today’s “always break”.)

  • Many projects have extremely slow CI that sucks up valuable time. For me the gold standard is correct-by-construction caching for bug-free incramentality, and only Nix provides that at the moment. I don’t think there is appetite for yet another GHC build system, but I hope to knock out all the weirdness that makes a bespoke build system required in the first place. cabal build ghc and stack build ghc are perfectly possible we move the goalposts and accept building the compiler alone, and build rts, base etc. as separate steps.

    Getting core libraries off extremely slow Travis is also important.

So yeah, few of these things are directly solving problems raised, especially in that they are focused on expert/core volunteer pain points. But I really do believe that if we first increase the productivity at which we can fix everyone else’s issues, the diversion will pay for itself really quickly. The challenge is thus building the trust to pursue these intermediate milestones.

I also want to get ahead of any sentiments that “Haskell is not popular and other languages are because they do these things better”. I’ve been involved with the Rust community for many years (though less recently), and I’ve dealt with the build systems / workflows of many languages as a Nix maintainer. A lot of tooling and build system is bad or worse across the board. So I don’t think we should feel shame or envy working on this stuff, because it’s not because we’re playing catch up. It’s rather because there is an opportunity to crush the competition :slight_smile: .

lowest hanging fruit != areas where we are most behind!

2 Likes