You cannot do that because some languages implementations could have an [ABI][1] different and incompatible with the C one. On current systems, C is very common and most (but not all) language implementations have an ABI and [calling conventions][2] compatible with the one from C. Notice that it is a property of the implementation (your C compiler and your operating system), not of the programming language. Also, some languages have different and incompatible views on [control flow][3] (look into [call/cc][4] and [tail-calls][5] in [Scheme][6], Goroutines in [Go][7], or backtracking and [cut operator][8] in [Prolog][9], [CLIPS][10] rules, concurrent actor languages, ....). I'm not sure you'll be able to design something which easily fits all of them (and that could impact the FFI requirements of implementation of these languages). If using C++, beware of [name mangling][11] and of exception handling. (e.g. C `longjmp` is not friendly with C++ exceptions). [Dynamic loading][12] facilities like [`dlopen`][13] and [`dlsym`][14] are relevant to name mangling. So prefer an API using `extern "C"` functions. [libgccjit][15] could be inspirational (it is coded in C++ but has a C friendly API) and perhaps useful (you could consider runtime generation of glue code). Memory management (notably with [garbage collection][16]) is also an issue. Study for examples [foreign function][17] interface [of Ocaml][18] and [of SBCL][19] and [of Lua][20] and of [Guile][21]. Look into [libffi][22]. Some languages also want [serialization][23] or [persistence][24] facilities (even for foreign data). Read also about [dynamic software updating][25]. You could provide some reflection facilities (e.g an API to query your API, e.g. like [GTK introspection][26]). You might try to provide a generic closure mechanism like [in GObject][27]-s. You could use (or customize or adapt) code generators like [SWIG][28]. You might consider compiler plugins (e.g. [GCC MELT][29] extensions). If you have a wide and complex API (hundreds of public functions or data types) consider at least providing a machine readable form of it, e.g. some database or XML or JSON from which automatic glue code could be generated. ## There is [**no silver bullet**][30]. <sup>NB. Better make your stuff [free software][31]. You might get outside contributions and you'll need outside help to interface your thing with many programming languages, including some that you don't even know. [Open source][32] is a good way to counter [leaky abstractions][33] (since you and other contributors can dive into the implementation source code). Given the variety of programming languages, **you will need *outside* help** (as soon as your API is successful)</sup> ----- # why the question don't make any sense I asked several times the OP to give much more context and motivation, and to explain the domain for which the library is written, and the context in which that library would be developped. Sadly I've got no answers at all. **The applicative domain** (e.g. high speed frequency trading, software for dentists, selling machine, weather forecast, image processing, speech recognition, word processing, social network, static source code analysis ...) ***matters* practically *a lot***, because it defines what programming languages are likely to be considered and what [programming paradigm][34] is probably used. For instance, an image processing library is very unlikely to need to be interfaced to [Agda][35] or [Coq][36], but probably would be used from C or C++ applications. Business software is often written in Java (and older ones was in Cobol) so needs to be interfacable to [JNI][37] or JVM. Static source code analysis software is very likely to use some theorem prover (so Ocaml or Common Lisp or Haskell is important to them, and they need to be garbage-collection friendly). And so on. Sometimes, [inter-process communication][38] (including RPC, web services, RESTful applications) can be used, but at other times it is not efficient enough. **Details and context are *very* important** and we don't know them. The question mentions "desktop software", but that just means today something having a native (non-Web) [GUI][39] used with a mouse and a large enough color screen (the dentist software, the software for managing my bank accounts, your favorite game software, the word processor, a web browser are all desktop software, but their main commonality is just having a GUI). Using [Qt][40] (a very powerful GUI cross-platform toolkit for C++) facilitates the development of such things. And quite often a library used on desktop (think of XML or JSON libraries, machine learning libraries, numerical computation libraries, etc...) don't even care about GUI (but it could care about response time -having functions returning in less than 0.4 seconds- and thread friendliness), because the application (not a reusable library) would care about GUI itself. The question mentions [plugins][41], but these are simply compiled software components which get [dynamically loaded][12] at runtime (thus increasing the [virtual address space][42] of the [process][43] loading them), using e.g. `dlopen` on POSIX (and probably `LoadLibrary` on Windows, which I don't know at all). Notice that the JVM don't use (Java-coded) plugins but [dynamically loaded classes][44], and speaking of plugins don't make sense with JavaScript or with Common Lisp (or most languages having a `compile` or [`eval`][45] primitive). So the mention of plugins don't means much (both Firefox browser and GCC compiler accept plugins, for very different reasons). **Without a lot more additional details** (including applicative domain, context, motivation ...) **the current question don't make any sense**. I offer to delete my answer if that helps in closing the question in its current form. [1]: https://en.wikipedia.org/wiki/Application_binary_interface [2]: https://en.wikipedia.org/wiki/Calling_convention [3]: https://en.wikipedia.org/wiki/Control_flow [4]: https://en.wikipedia.org/wiki/Call-with-current-continuation [5]: https://en.wikipedia.org/wiki/Tail_call [6]: https://en.wikipedia.org/wiki/Scheme_(programming_language) [7]: https://en.wikipedia.org/wiki/Go_(programming_language) [8]: https://en.wikipedia.org/wiki/Cut_(logic_programming) [9]: https://en.wikipedia.org/wiki/Prolog [10]: https://en.wikipedia.org/wiki/CLIPS [11]: https://en.wikipedia.org/wiki/Name_mangling [12]: https://en.wikipedia.org/wiki/Dynamic_loading [13]: http://man7.org/linux/man-pages/man3/dlopen.3.html [14]: http://man7.org/linux/man-pages/man3/dlsym.3.html [15]: https://gcc.gnu.org/onlinedocs/jit/ [16]: https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) [17]: https://en.wikipedia.org/wiki/Foreign_function_interface [18]: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html [19]: http://sbcl.org/manual/index.html#Foreign-Function-Interface [20]: https://www.lua.org/manual/5.3/manual.html#4 [21]: https://www.gnu.org/software/guile/learn/ [22]: https://sourceware.org/libffi/ [23]: https://en.wikipedia.org/wiki/Serialization [24]: https://en.wikipedia.org/wiki/Persistence_(computer_science) [25]: https://en.wikipedia.org/wiki/Dynamic_software_updating [26]: https://wiki.gnome.org/Projects/GObjectIntrospection [27]: https://developer.gnome.org/gobject/stable/gobject-Closures.html [28]: http://swig.org/ [29]: http://gcc-melt.org/ [30]: https://en.wikipedia.org/wiki/No_Silver_Bullet [31]: https://en.wikipedia.org/wiki/Free_software [32]: http://opensource.org/ [33]: https://en.wikipedia.org/wiki/Leaky_abstraction [34]: https://en.wikipedia.org/wiki/Programming_paradigm [35]: https://en.wikipedia.org/wiki/Agda_(programming_language) [36]: https://en.wikipedia.org/wiki/Coq [37]: https://en.wikipedia.org/wiki/Java_Native_Interface [38]: https://en.wikipedia.org/wiki/Inter-process_communication [39]: https://en.wikipedia.org/wiki/Graphical_user_interface [40]: http://qt.io/ [41]: https://en.wikipedia.org/wiki/Plug-in_(computing) [42]: https://en.wikipedia.org/wiki/Virtual_address_space [43]: https://en.wikipedia.org/wiki/Process_(computing) [44]: https://en.wikipedia.org/wiki/Java_Classloader [45]: https://en.wikipedia.org/wiki/Eval