I switched to helix, but I still sometimes open zed. I tested gram today and it looks promising , so zed is going to the garbage bin.

Anyway, the idea is interesting. I’m using flight radar currently to track my flights.

Not trying to criticise, just sharing own opinion - it is better if ugly, but written by human, than polished by llms You write code, yes sometimes it is ugly, messy, but you learn this way

hey! I think it is a bit different layer - all of these are process orchestration/supervision tools working on os level, so managing state of todo tasks like “fix bug” is wrong usage for such tools. The VM, I’m working on is embeddable and sandboxed - manages states of a application, so potentially process supervision tool may be built using VM since it has persistent storage and state will be preserved even on process crash + “tasks” have own instructions that means it more flexible than static configs : instead of foreground { kill <process> } it can contain logic and conditions (get process by id -> get its state -> if state is idle -> kill ) foreground { push <process_id> get_state push_state <idle> eq if kill <process> then }.

No language guarantees high-speed code. Rust, like C and C++, is also perfectly suited for writing slow code

I’ve never tried Deno. The joke was about the guy’s obsession with those four letters and an extrapolation to what the next name or state of project might be.

Node-> Deno->Done?