@ramin_hal9001@emacs.ch
> That said, I see no reason why all of these different runtimes couldn't be implemented in a version of Lisp that used Rust-like memory management,
The concept of run-time is wider than a Rust-like "minimum common denominator".
A DBMS with its index types and its query plans is a "run-time". It offers various operations with specific cost-models.
The BEAM with its fine-grained concurrency is a run-time minimizing latency, but with rather limited bandwidth (they are working on a JIT). If you try to call C libraries into BEAM code, you increase bandwidth but you can ruin totally the latency aspects, and you can block services. So, you had to implement the BEAM in Rust, instead of C, but it will be a BEAM run-time, not a Rust run-time.
Linux kernel BPF code is an ad-hoc high-level managed language that can be compiled to efficient code, taking in account also all other submitted BPF fragments submitted by various applications. If you give to this language all the power of Rust, the kernel cannot check and optimize it.
GPU has its specific run-time, and the code must follow a certain paradigm.
The run-time can be affected by the characteristics of the hardware and/or of the problem domain. For the programmer, it is usually a simplified model from which you can derive the approximate cost of operations; the error that are signaled; etc...
We live in a multi-paradigm and multi-runtime world. We cannot escape this.
