eBPF are vendor kernel modules on steroids: now instead of getting compile failures trying to build your out-of-tree module, your stuff just blows up at runtime.
eBPF has been invaluable in my field (low-latency linux applications) and it changed a lot.
If you had problems working with kernel modules before, you probably should expect struggling with writing correct code for eBPF too. It's not for everyone.
Most recently I used ebpf to track which other threads were stealing cpu time (and how much) from my latency sensitive cpu-pinned thread.
You can do almost anything, the level of introspection into the kernel internals is amazing.
For both traditional kernel modules and eBPF programs, you compile the code ahead of time. For kernel modules, if you have a bug, you load it into the kernel and the kernel hard crashes at runtime. For eBPF programs, the kernel will reject the program before you inject it.
In practice to deploy eBPF programs, you end up adding the kernel verification step into part of your CI/dev workflow so that by the time you ship your programs, you know that they will safely load and safely run in real environments.
Tioga editor in Xerox's Cedar already had a native structural active document capability back in 1987, but the most successful commercial Microsoft Office applications with billions of dollars budget still do not have this capability, your point exactly?
