Hacker News Reader

Comment by stevemk14ebr | Hacker News Reader

Yes, you do misunderstand. The D language is terrible, it has no loops, no functions, it is not a usable language beyond basic scripts. The _good_ part of the windows implementation is the kernel interfaces, which is what my design uses. The entire point of this research was to discard the D language.

My implementation(s) allow you to use C++ 17, or Web Assembly instead. These are significantly more powerful languages. The Web Assembly scripts are a demonstration of using the same 'safe' architecture as DTrace. While the C++17 DLL system is a demonstration of an 'unsafe' but more powerful design.

If you think DTrace can't crash the system, you are mistaken.

View on HN

I appreciate that you feel you are solving a problem, but you are in fact solving a different problem than DTrace was designed to solve -- and what you perceive to be "terrible" aspects of D are in fact deliberate design decisions to abide by DTrace's safety constraint.[0]

[0] http://dtrace.org/blogs/bmc/2005/07/19/dtrace-safety/

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.

I think your response speaks for itself -- and agreed that you (and other systems) have made very different decisions with respect to safety.

We agree! I'm not calling dtrace bad for the record, it's awesome. My issue is just with the language users are forced to write in not being expressive enough (specifically on windows at that). If fixed length loops and user defined functions were added, it would be quite a lot easier to implement advanced scripts.

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.

to clarify for the uninitiated like myself: this "D" is not the Walter Bright "D", but a language specifically for DTrace.

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.

Reply on news.ycombinator.com