Why Not FFI

FFI – foreign function interface – is a common way for new languages to integrate with existing systems. But FFI is problematic in many ways. FFI represents ambient authority (the ability to ‘import’ authority to ad-hoc resources without a specific grant) which makes it difficult to integrate untrusted code. FFI requires more information about the platform (i.e. that it provides the foreign language), which hinders portability and cross-compilation. FFIs integrate awkwardly with GC, runtime plugins, concurrency, debuggers, rich types, etc..

Instead of FFI, we should define programs against well-defined interfaces, which may vary based on the kind of the application.

For example, for end-user apps, we define assume a DOM-like API, and the application would have no authority not granted by that API. This isn’t a new idea. JavaScript, Lua, and other scripting languages have been doing similar for decades. Potentially, we might even have freedom to decide a compilation target, e.g. JavaScript and HTML vs. C++ and Wx.

The integration code is shifted outside the language. The program has well-defined authorities and contextual requirements, making it secure-able and portable.

On a per app-type basis, the integration burden is lower because we’re dealing with a specific API and context rather than a generic one-size-fits-all FFI. We don’t need to deal with generic type adapters, generic GC integration, etc.. There is some opportunity for specialized optimizations. The overall integration cost (across many kinds) will be higher, but not too much: while there are many ‘kinds’ of applications (end-user apps, web servers, pubsub apps (ROS, DDS), console apps, dock apps, etc.), there are a great many apps of each kind, and the overhead of supporting a new kind is readily amortized. And the backend itself might be extensible or pluggable, at least for common capabilities like network and storage.

One reason I’m thinking about this regards use of import expressions – avoidance of them.

Gilad Bracha argues against imports in his article Ban on Imports. His argument is based on abstraction and extension issues: imports tie modules to concrete implementations of potentially abstract dependencies. While those are valid issues, I’m more concerned about entanglement: imports create a web of names, and it is difficult to extract a module for reuse in another project without dragging along enormous sections of that web; and name or version conflicts easily result in DLL hell.

FFI without import seems not very practical. Also, FFI can be understood as a form of import. To be rid of imports, we must be rid of FFI. And that’s just one more motivation to avoid FFI.

Advertisements
This entry was posted in Language Design, Modularity, Open Systems Programming, Security. Bookmark the permalink.

3 Responses to Why Not FFI

  1. I believe Gilad once mention how he planned to develop a cleaner FFI than JNI. It is in another blog post of his. His killer example is that all the VM components that need system functions, like the garbage collector, are fully pluggable and mockable for testing.

    Basically, his idea was initially introduced at Oopsla 05 in his DSL talk. In Newspeak, the idea is manifested by the everything is a message send edict, and there are no message passing primitives. Instead there is a VM Mirror. Want to do FFI? You implement an Alien layer.

    As a brief aside, recently on the luajit mailing list Mike Pall stepped on his soap box to answer the question: what is the ideal hardware and programming language abstraction for optimal performance? The discussion forked over to Hacker News, but something he did not mention but has probably thought about is what to do with Ffi.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s