Wow thank you I was so confused about the “lack of loops” thing and thought I must have utterly misunderstood the paradigm of Walter Bright’s D.

I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my system is not meant to be deployed on end point user systems. A recreation obeying the same constraints of dtrace could be constructed, it would simply involve swapping the scripting system for another.

If your argument is that loops are unsafe, please go look at ebpf, which has loops. If you think user defined functions are unsafe, go look at ebpf again - it's nearly C. If your argument is shipping code from user to kernel is unsafe, go look at ebpf byte code, I could easily implement signing to validate only trusted plugins can load.

Your argument is close minded. These are trade-offs, and can be easily changed to obey different constraints. My system open sources previously undocumented kernel interfaces. If you dislike the constraints I chose, fork it and go rebuild dtrace exactly, it's not that I'm not solving a real problem - I'm just solving one you fail to understand.

Example from the doc. Probes not being allowed to call other system routines to avoid reentrancy. Dtrace avoids this architecturally, as your link says. I disliked this, so I chose the alternative, which so happens to be mentioned in the same document. My system detects reentrancy and avoided calling probes when it's determined the caller was itself a probe.

I simply chose different constraints. It 'not being secure' is a facade. It's not meant to be, I could make it so though, if I wanted to. I bothered with the entire rust + wasm implementation specifically to show that this argument of not being secure' because I didn't use the D language was untrue. Browsers themselves execute untrusted code via wasm. If the concern is the halting problem, then just use wasm with bounded loops.