[mhitza]

That's probably as close to reality as I would guess. We'll have to see if anything gets delivered.

I don't get why Gabriela is so against this project, it might just be vaporware. But invoking the fact that this person is not already established in the community is detraction for detraction's sake (or gatekeeping).

Funny enough, I've also been very slowly chipping away at some base(/prelude) Haskell library replacement, because I find it beyond embarrassing that in 2023 with a default Haskell installation one cannot make a HTTPS GET request.

Haskell comes with half depleted batteries inside the box. And I cheer for anyone that tries to fix the base experience. If this one's vaporware, I'll just wait for the next person that gets too frustrated with the library experience.

[tome]

> I've also been very slowly chipping away at some base(/prelude) Haskell library replacement, because I find it beyond embarrassing that in 2023 with a default Haskell installation one cannot make a HTTPS GET request.

Sounds interesting! Do you have anything you can link us to?

[mhitza]

Not really. While my mention in the previous post was 2023, I actually started coding this in the summer of last year. As I work on it once in a blue moon, might be a year or two away before I publish anything.

If you're interested in terms of approach, it builds on what I consider saner exports/re-exports of all the other packages that are part of a default installation (base, containers, text, bytestring, etc), and avoids reinventing where industry standards exists (no tls/http client stack from scratch but curl C bindings). There are a few other abstractions I've written in there, but those feel rather flimsy and might remove them.

[agentultra]

... we also need a base library that has some standard data structures like maps, vectors, stacks, and queues! Best of luck with your project. :)