The author mentions dtrace in passing. If you're into "load bearing rants", check out bcantrill's recent rant on bpftrace silently losing events and why dtrace won't do that.
I haven't actually used bpftrace myself, only BCC. I can totally imagine it being more janky than DTrace, BCC is pretty janky even if I also think it's cool. In my eBPF tracing framework I had to add special handling counters to alert you if it ever lost any events, plausible bpftrace didn't do that.
I think if you're working mostly with tracing/sampling specific applications you'll be more of a BCC person, while if you're hired to diagnose problems in a wide variety of applications then you might learn to like bpftrace more.
That's an absurd comment: eBPF and DTrace exist on orthogonal systems, and most using eBPF have never even used DTrace, let alone "moved on" from it. The systems are really quite different, and have different design centers; for the use case of instrumenting the system for purposes of understanding it, there are many regards in which eBPF remains behind DTrace -- one of which I elaborated on in the rant to which the parent is referring.[0]
That was true 15 years ago. eBPF and DTrace exist on some of the same systems now, Linux and Windows.
>and most using eBPF have never even used DTrace, let alone "moved on" from it
The performance and tracing groups at Microsoft certainty have. Same with Oracle, Netflix, among others.
>The systems are really quite different, and have different design centers; for the use case of instrumenting the system for purposes of understanding it
True, but unfortunately for DTrace, it is too late. Oracle should have done this years ago. Now Linux has a more powerful tracer builtin, eBPF, and it would be a backwards step to switch the kernel code to DTrace. [0]
