[pavpanchekha]

I've used the Racket FFI for some important tasks, and it's very easy to use. However, it's not as fully baked as the Python one (I've found bugs due to GC interactions) and it's weirdly slow (a few too many levels of wrapping). That said, I still use Racket extensively and enjoy it.

[yomly]

This is the write up I was looking for as this is the use case I've had in mind for Racket of late after reading Felleisen's LOP paper.

Would love to know more about your experiences with doing Racket FFI. How hard were the bugs around GC to discover and workaround? What were you building in Racket?

[pavpanchekha]

See my responses to a sibling comment for Github bug reports. I had a great experience with them: very fast triage and fixes, plus a lot of help developing a workaround so we could target a range of Racket versions. (Distros still ship some old versions!)

These bugs were found while working on Herbie <http://herbie.uwplse.org/>. We use the FFI to bind to your machine's math libraries so we can properly evaluate how accurate a floating-point expression is on your machine.

[neilv]

You found bugs in the FFI mechanism itself, or in FFI bindings that someone had written for a particular library?

[pavpanchekha]

In the interaction between FFI, GC, and hash tables, so yes, in the FFI itself, not in particular bindings:

https://github.com/racket/racket/issues/2702

https://github.com/racket/racket/issues/2263

There were workarounds (in Racket you can instruct the GC not to move your FFI objects) and I believe the underlying issues have been fixed.

I must add that I got immediate and comprehensive support from the core developers, who not only fixed the bug but also suggested the workaround (so I could continue to support all our target versions of Racket).

[neilv]

Thank you for your great bug report on this, and I'm glad to see it was in good hands.