Related but more high level, I think we should have language sets instead of single languages with simpler interop and shared infra: https://gist.github.com/xixixao/8e363dbd3663b6729cd5b6d74dbb...
Low-level operations like manual memory management are not like that. They are part of the runtime, and _do_ affect the business logic. It's a leaky abstraction. So if I import some other team's Rust code and I try to write RustScript on top, I might have to worry about some special edge cases where the argument I pass in isn't properly garbage collected or what not.
Verification may be interesting, for high-assurance (e.g. automotive/aerospace) applications. It's for this reason that a theorem prover[2] and an ml[3] have been implemented, and they interoperate freely with the rest of common lisp.
In other words: we are already where you want to be, and we are even less stratified than you propose we would need to be.
0. https://github.com/marcoheisig/Petalisp
1. https://github.com/froggey/mezzano/
Also maybe of interest, not quite the same but on vaguely parallel lines, minikanren and microkanren.
For example, Rust used to have a garbage collector. A language set boundary would be a good way to add this back in without requiring a runtime at the lower levels.
Rust already has “levels”, such as no-std or core.
Similarly C# has a scripting variant: https://visualstudiomagazine.com/articles/2021/06/14/csharp-...
And it also supports AoT compilation to a single EXE, but there were a lot of limitations. The latest attempt is a WIP: https://github.com/dotnet/runtime/issues/61231
I would argue that libraries especially need highly restricted language subsets. E.g.: an image parser library should be “pure” in the sense of never being permitted to access system APIs. Image binary in, decoded bitmap out. Like a pure function, but at the module level.
NGEN which was there since day one, but its main purpose was fast startup and only allows for dynamic linking.
Mono AOT one, used by Xamarin workloads for iOS and Android deployments.
The Sing# and System C# dialects used by Singularity and Midori respectively.
The MDIL used by Windows Phone 8 and 8.1, based on Singularity's Bartok compiler.
.NET Native introduced in Windows 10 for UWP workloads, replacing the MDIL based one, originally known as Project N.
The NativeAOT pointed by you, which started as a research project on how to bring .NET Native back into main .NET.
Finally some alternative ones like Unity's IL2CPP or CosmOS.
Python+mypy+cython
https://cython.readthedocs.io/en/latest/src/tutorial/memory_...