I published the May update for the #Haskell Core Libraries Committee (CLC) ✍️
🆕 4 new proposals
✅ 3 approved
🚫1 declined
🔥 1 hot discussion
💎 5 featured discussions with a common theme
Check it out 👇
https://discourse.haskell.org/t/clc-update-may-2023/6248
The longest and the most exhausting discussion for me personally is around the 'base' split and GHC internal modules.
It feels (to me personally) that the discussion is just circling around the same topics with no progress, and it's becoming too difficult to steer it 😞
The most controversial discussion is about adding types like Int8, Int16, Int32, Int64, Word8, etc. to Prelude.
Many people want it but many also are tired.
https://github.com/haskell/core-libraries-committee/issues/156
@jonn wait wait wait, there are people who are put off by the "pedantry" of having specific size types in Rust? Rust the language whose purpose is to have memory safety?
@hecate yeah, in practice we often just use i/u64, but also, big its are memory safe. I don't understand your surprise. Look at this implementation: https://github.com/tczajka/ibig-rs/blob/main/src/ubig.rs and buffer.rs there. I wouldn't hate to have this in #rust prelude.
@jonn @hecate As someone who spent some time trying to port cryptographic libraries from Rust to Haskell... I just gave up and decided to wrap the Rust libraries via the FFI. If Haskell wants to stay a higher-level language where you drop down to the FFI for performance, that's fine, though it does make me sad.
If Rust had a good capability-safe approach to managing side effects I might not come back to Haskell at all. As it is, the slow demise of Safe Haskell has me thinking that maybe there's not that much here for me anyway.
@nuttycom @hecate I like how @kirelagin does it. He doesn't let users worry about allocations and such, focuses on having pure external modules. Internals are catering to it with "inner mutability" pattern.
Check haskell-crypto. It's simple in terms of capabilities, yet well-written. My go-to library to do conventional cryptography with #haskell.
@jonn @hecate @kirelagin What I was trying to do was port the Halo2 zero-knowledge proving system, both to get a better understanding of it and because some of the APIs in circuit construction just scream for an applicative interface that is way too burdensome to do in Rust.
@jonn @hecate @kirelagin This particular problem is one where both Haskell and Rust have parts of the problem where they absolutely shine, and parts where they are severely lacking. And those parts of the problem are not readily extricable from one another in a way that makes sense to plumb across the FFI.
@jonn @hecate what are the most up-to-date resources on how to do good API design wrapping the FFI? This is something I still struggle with.