It's always been the case, as far as I know. You may be thinking of the fact that you can't ptrace a process that's already being ptraced, which includes processes that are ptracing themselves.
Correct, which is why I'm mentioning it here. Stracing another instance of strace does not involve any of the processes ptracing themselves, though, and I don't think it ever has.
This isn't recursion. "strace strace foo" first runs the "strace" binary (PID X), which attaches one ptrace to "foo" (PID Y) and runs an I/O loop printing retrieved trace data. The outer "strace" call launches as PID Z, and attaches a ptrace to PID Y: the inner strace. The inner strace is not itself being ptraced until that happens, so there's no special case needed to allow "stracing strace".
However, you may be referring to a different scenario: multiple ptrace calls do hit the same process if you (for example) run "strace -p PID" for the same PID more than once simultaneously. In that case, strace invocations after the first one will fail with an error like 'strace: attach: ptrace(PTRACE_SEIZE, PID): Operation not permitted'.
The only constraint is that each process (or maybe each thread, I'm not sure off the top of my head) has at most one tracer. That constraint is not violated here.
In the case of strace -> strace -> date, the middle strace has one parent and one child. That's fine.
You can even have mutually recursive ptracing (occasionally used as an anti-debug strategy), since that doesn't violate the constraint either.
Any program that interacts with the OS - interacting with files, allocating memory, etc - will have to make system calls. Whether it's in C, Rust, Zig, Haskell, APL or Prolog.
I want to note that this is also true for “managed” languages like Java and Python.
However, because these languages have a far heavier runtime than the “systems” languages, it is usually possible to trace them at the runtime level rather than the syscall level, and doing that will typically give a better experience.
You troll, but I'll feed you. There is no universally better language for portable high-performance system programming for resource constrained platforms. Every single alternative have unacceptable trade-offs.
Not easily portable to most microcontroller targets: No SDK for our target SoCs and official SoC/µC support. Increased code size (which is also a performance issue in many SoCs). High cost of retraining engineers. High cost of reenginering existing code base and tooling. Lack of commercial support.
I'm optimistic about Rust, and it taken great strides to replace C, but there are still many hurdles that prevent it replacing C in microcontrollers and SoCs. Even if it wasn't for the lack of a platform SDK and porting existing code, the risk is too great with lack of official support for many commercial SoCs.
ARM cortex, riscv and espresif all seem like they have first class support. Unless you are talking about peripherals in which case, why would you expect the language to write/maintain low level drivers?
The hurdles to replace it in micros might be worth it depending on the team size and requirements. Personally, I wouldn't expect it to ever replace existing code bases, but could be a reasonable choice for greenfield designs.
In my case, wireless SoC chips (BT, BLE, DECT). Current generation are ARM M0 cores, but 16-bit RISC/CR16 architectures are widespread still. Not expecting language to provide platform support, but SoC providers don't either. They provide C frameworks only, if anything.
Enough with this constant insecurity that forces people to derail every damn unrelated thread with drive-by comments about how C programs should be rewritten in a different language.
