4 ms·

Because runtime is hard to understand, leave alone sell. Notably LuaJit, Golang (and before Plan9 and Inferno), Erlang, Haskell, Swift, libc++, etc are writing

Because runtime is hard to understand, leave alone sell. Notably LuaJit, Golang (and before Plan9 and Inferno), Erlang, Haskell, Swift, libc++, etc are writing runtimes. The problem is that it becomes a mess very quickly, unless you are Mike Pall. Also, the idea of a VM isolated from an OS is a marketing meme (how could a mere OS process be isolated from an OS?) So, smallest, thin-layer-over-an-OS runtime - approach pioneered by Inferno, is a much saner and efficient one. Compilation to machine code + thin layer runtime + native ABI based FFI is still the hardest and still the best way to make a runtime since times of Common Lisp. I am not writing runtimes because I am not Mike Pall, not a Google employee and no one pays me to do so.)) BTW, marrying, say, Arc (or femtolisp, or a sane subset of scheme) to LuaJIT runtime could be a nice project, to have a really powerful scripting language.

bogomipz 10y ago
Could you elaborate on this sentence, specifically - the native ABI based FFI part? When I think of the ABI I think of the runtime linker of the OS, wouldn't this always be native? What would the non-native ABI be? "Compilation to machine code + thin layer runtime + native ABI based FFI is still the hardest and still the best way to make a runtime since times of Common Lisp." Also what is the thin layer, in this context? I don't know much about Lisp runtimes, I'm sure its fascinating as its both compiled and interpreted. Thanks.
- dschiptsov 10y ago
  To make FFI lightweight, one follows underlying OS ABI, so there is no need to do any conversions. Compare Golang or LuaJIT FFI with what Java does. Java uses libffi, but it does unnecessary copying and type and encoding conversions. Golang and LuaJIT has zero-copy FFI due to reusing of OS types (for UNIX-like systems it is C) - just dlload-and-call. Thin layer (of abstraction) is how Golang's runtime is organized - delegating to an OS instead of reimplementing inside a VM.
  - bogomipz 10y ago
    Thanks. Makes sense.

bogomipz 10y ago

Could you elaborate on this sentence, specifically - the native ABI based FFI part? When I think of the ABI I think of the runtime linker of the OS, wouldn't this always be native? What would the non-native ABI be? "Compilation to machine code + thin layer runtime + native ABI based FFI is still the hardest and still the best way to make a runtime since times of Common Lisp." Also what is the thin layer, in this context? I don't know much about Lisp runtimes, I'm sure its fascinating as its both compiled and interpreted. Thanks.

dschiptsov 10y ago
To make FFI lightweight, one follows underlying OS ABI, so there is no need to do any conversions. Compare Golang or LuaJIT FFI with what Java does. Java uses libffi, but it does unnecessary copying and type and encoding conversions. Golang and LuaJIT has zero-copy FFI due to reusing of OS types (for UNIX-like systems it is C) - just dlload-and-call. Thin layer (of abstraction) is how Golang's runtime is organized - delegating to an OS instead of reimplementing inside a VM.
- bogomipz 10y ago
  Thanks. Makes sense.