Cliffhanger FFI draft

Yesterday I published the first draft of Foreign Function Interface for cliffhanger and it's a bit of a crazy one :)

You can read it in detail here: github.com/chedim/cliffhanger/blob/main/FFI..

TLDR -- all communication between cliffhanger application components will be done over network sockets, even if all components are running locally on the same machine.

In a sense, cliffhanger FFI interface is an RPC protocol.

You may rightly wonder why I chose this particular interpretation -- network calls are orders of magnitude more expensive than procedural calls, which means that cliffhanger applications will be very, very slow compared to applications built using classic languages like Java, Go, Rust, C++ or even python.

Well, so what if it is going to be slow? Cliffhanger is not a systems programming language. It is a data manipulation language, designed to glue microservices into a single application. This makes it more important for cliffhanger to be a useful programming language rather a fast one.

Using a network protocol to interact between application modules would allow independent deployments of CH application components. Clifhanger libraries are not just libraries in a classic sense -- they are services that can be hosted by their developers (or, if a developer allows that -- downloaded an run locally). It would also allow a single application to securely span across all the network barriers of the Internet. In a sense, cliffhanger is not a programming language, but a devops tool.

That's why I think that making CH a natively network-aware language is more beneficial to it than making it fast.

What do you think of my decision? Please leave your thoughts in a comment below or tweet them @chedim :)