[Feature Discussion] C FFI

[kirawi]

In the far future, it may be desired for a plugin to have native-level performance. One method of enabling that would be exposing an FFI for plugins to use, and then load those plugins as dynamic libraries. The purpose of this issue is to gauge interest and evaluate the pros and cons of such an approach, rather than to discuss how such a feature could be implemented. This is not an alternative to #122, and should be considered a long-term goal at any rate if we decide to go with it.

Something of this scale might require an RFC.

[kirawi]

I'm unfamiliar with C and the hurdles associated with it, but I believe that supporting an FFI could introduce considerable technical challenges to the codebase. What happens when a plugin incorrectly uses memory, or crashes? It's also unclear to me whether an FFI would see extensive, justified usage, or if most people would stick to #122.

[matu3ba]

Any FFI requires 1. process separation as to not kill the editor on plugin failure, 2. API stabilization and deprecation process (users can use old versions of the editor or plugins and this must be handled and maintained somehow). Usually one also wants to have 3. plugin-separated shared memory handling by the editor to minimize communication delay.

Point 2. means significant churn when stuff changes alot, so it does make more sense to support JSON and integrate stabilized parts into the editor as optional features. If it is performance-critical then why should it be a separate plugin?

[archseer]

A C FFI is a non-goal for me. As other editors have proved, the majority of editing performance comes from strong primitives implemented in a low-level language (i.e. atom implementing superstring in C, then building the rest in Typescript), which is what we hope to provide with core/view. The plugins should be reasonably fast: not as fast as native code in the editor, but fast enough.