{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreid4iirjueos3ontlvpktg5qyfwmntkzolm3pwlsdwtznuzzf6nlw4",
"uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjila7ubekb2"
},
"path": "/t/ann-rivulet-window-manager/13921?page=2#post_28",
"publishedAt": "2026-04-14T23:08:25.000Z",
"site": "https://discourse.haskell.org",
"tags": [
"this thread",
"@dschrempf",
"the non-moving GC"
],
"textContent": "> Rust FFI in Haskell is sort of a dead end\n\nWhat makes you say this? It could be better, certainly, but there are people doing it and it’s an area that I’d hope and expect us to really collectively invest in, given the two languages’ similarities and complementary strengths. Lately I’ve been using Mozilla’s `cbindgen` to create header files from Rust code, and parsing those headers with `hs-bindgen`, which enables safe generation of much of the boilerplate.\n\nIncidentally, even if you’re only interested in binding to C rather than Rust, I wholeheartedly recommend `hs-bindgen`. It’s already been mentioned here, and given that you’ve mentioned `tiny-wlhs`, I assume you’ve seen this thread, and the final post from @dschrempf. Still, I’ve used the older alternatives, and I can’t imagine reaching for anything else these days. I’m now almost done porting one of my libraries to it from `c2hs`, and it’s made it better in so many ways, from avoiding all sorts of hacks to working nicely with HLS.\n\nAs for requiring one or two system libraries like River, I don’t think it’s a huge issue. If they’re widely and sensibly distributed, then all you really need these days is to have `pkgconfig-depends` in your Cabal file. Then any users building from source can work out where to find the right packages for their OS. And when your project takes off and you start actually packaging it for Nix/Pacman/RPM, you just specify them as dependencies.\n\nAlso, regarding Haskell performance, you might want to look at using the non-moving GC to avoid pauses.",
"title": "[ANN] Rivulet Window Manager"
}