@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 I'm not saying big ints are unsafe, but I find it hard to view "sized integers in the prelude is pedantry" as a legitimate opinion for a language whose value proposition is to be in touch with the memory of the computer. Even in Haskell it makes sense to have sized integers, for precise domain modelling.

@hecate sure, but I said "it's cool to have them side by side".

@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 wrapping libs is the way! haskell-crypto is a libsodium wrapper for instance.

That said, I love how #lean ffi and typeclasses allow us to go gradually from verified code to 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.

@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 @nuttycom @hecate
> inner mutabiliy pattern
Sounds like something Java programmers would invent, lol

@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.

@nuttycom @jonn https://merveilles.town/@hecate/110310085560581563

@hecate @nuttycom let's goooooo, what a selection.

@jonn @nuttycom For the discerning FFI binder only ;)

@nuttycom @jonn @hecate
Implementing the meat in Rust and then making high-quality bindings for other languages (high quality = exposing UX traditional for this language) is definitely the correct way.

I can’t imagine why anyone would want to _port_ anything to a different language, especially to Haskell, ESPECIALLY cryptography.

@chshersh I only really care about dependent types in Haskell, the rest: I keep my opinions to myself to not create useless (and looping) discussions.

@jonn Actually, one of the linked discussion is about dependent Haskell.

The implementation of one of the GHC proposals related to DH is currently blocked on the base split and GHC internal modules.

So if have suggestions on how to proceed and move forward efficiently, feel free to share your thoughts!

https://github.com/haskell/core-libraries-committee/issues/162